Recent experience has taught us just how devastating software security breaches can be. The losses of the worst software security breaches can be measured in billions of dollars. And it’s not just a company’s reputation that suffers.
One of the most prominent examples has been the two 2013 Yahoo hacks, which impacted all 3 billion user accounts. We can’t accurately measure the personal impact of the theft of data or the damage to Yahoo’s reputation. However, we can estimate the financial and reputational impact on Yahoo. Yahoo recorded a 6.5% decline in its share price after the second breach was publicized. Verizon, which had been negotiating to acquire Yahoo for US$4.8 billion, ended up closing the deal for US$4.5 billion because of the breach.
The root cause
Most organizations, Yahoo included, have typically used conventional well-oiled processes to create, release and maintain functional software that tend to generate many security flaws. These defects can expose serious architectural inadequacies. Fixing the defects may require the entire recoding of the existing deployed software as well as a complete rework of the system architecture.
Impact of fixing defects in conventional process
In the past, it has been a common practice to perform security-related activities only as part of the testing process. This after-the-fact technique usually resulted in a high number of issues discovered too late or not discovered at all. Any code fixes to address security vulnerability may require a change in the original design of the application, which can result in significant cost. Many studies have shown that the relative cost of fixing code issues increases later and in the process, the issues are found. (See Figure 1.)
Figure 1: The later in the process the code fix is made, the higher the cost.
Some software development life cycle (SDLC) processes lack security requirements. Unfortunately, some software development organizations think securing an application is a separate process from creating documentation for the information assurance department. Worse still, some organizations think securing an application involves nothing more than scanning the code before it goes into production.
How do we get there?
The increasing vocal concerns about the business risks associated with insecure software have brought increased attention to the need to integrate security into the development process. Implementing a proper secure SDLC is more important than ever before because the stakes are so high. If we integrate security-related activities across the SDLC, there is a higher likelihood of discovering and addressing vulnerabilities early thus effectively building security into the development process. A secure SDLC process ensures security assurance activities are an integral part of the development effort.
Figure 2: Secured Development Lifecycle
The road ahead for Secure SDLC
Due to development methodologies like Agile, Iterative and Incremental being adopted by more and more organizations, 2018 will not only be about creating a secure SDLC. These methodologies are characterized by more frequent releases with shorter development cycles—sometimes with overlapping cycles—which makes secure SDLC a challenge. These issues can be easily overcome by integrating the secured-SDLC into the DevOps environment where different security tools and practices can be automated instead of running them manually.