The Economics of Software Security: What Car Makers Can Teach Enterprises

Meg McCarthy and Gary McGraw, Ph.D. also contributed to this article.

For enterprise executives, perhaps the best way to think of software development is as a specific kind of manufacturing process, like building cars. If a car assembly line process produced dents in the passenger side door in 10 out of every 100 cars, the defect rate would be flagged by the quality control manager. Manufacturers could address the problem by hiring staff to bang-out the dents, paint and buff the doors, and then ship the cars to the dealers as planned. This post facto correction would all cost money, but the assembly line could keep rolling uninterrupted and the only impact would be a higher unit cost to fix the dented cars.

An alternative approach would be to research the root cause of the dents in the car doors and adjust the process driving the robotics that assemble the doors to avoid making the dents. This approach would likely involve stopping the assembly line to correct the problems but the unit cost of this change may well be lower than the unit cost of the “banging out the dents” approach.  Put in terms of economics—the total cost of manufacturing in the corrected assembly method will be lower than with the “banging out the dents” method, despite temporary stoppage.

Now back to software security. When it comes to embedding software security controls in the software development lifecycle, we may have to stop the car assembly line and incur some up-front cost in terms of changing the way we build software, but over time this cost will be properly amortized into the total cost of development. 

Consider that there are two types of security controls available: controls that prevent defects before release and controls that detect defects after release. A good example of a preventive control is secure code review with an automated tool that helps to identify bugs in the source code well before software ships or is put into production. Detective controls identify defects as well, but only after release.

From an economic standpoint, preventing a defect eliminates the need to “fix” the defect reactively after the software has been shipped.  For example, if we put in a control aimed to find security defects in an input/output validation routine during coding, there is no need for an engineer to spend time fixing a defect after release since that kind of defect will never exist. As it turns out, not all defects can be prevented in advance of release.  In general, data show that the earlier in the lifecycle security controls are added, the better things look economically.  Controls that identify the defects in the development process are, in fact, essential to a software security initiative in addition to detective controls. And the factor of time in this case equates to money measured by the cost of the developer that has to fix detected defects.

Bang out the Dents = Penetration Testing
When it comes to securing web and mobile applications today, the most common detective security control is known as application penetration testing. A penetration test is run after the application is developed—meaning the design is done, the code is implemented, standard QA testing is finished, and the application is ready for use.  Fixing defects at this stage of the game is expensive. 

In economic terms, penetration testing looks an awful lot like banging out the manufacturing dents in a car door. For example, performing secure code review with a static analysis tool allows developers to identify defects as they are writing code, which we have established is far cheaper than finding a bug during penetration testing.

We have measured developer time savings relative to software security at a large health insurer.  We compare a software development process with no controls (or with penetration testing only) to a software development process with the preventative controls applied early in the process. 

In our case study, a large health insurer had a limited set of detective controls in place for a subset of web applications in 2013. The organization then implemented preventative controls applied early in the development lifecycle. Using the 2013 case as the baseline, we subsequently measured the required developer time to fix defects assuming all high- and medium-risk defects discovered eventually need to be fixed for all applications.

We measure software defects using a relatively simple measure of software defect density: the number of medium and high risk software defects for every 10,000 lines of code written. In the first case, we track the number of high- and medium- risk defects prevented with security controls embedded in the software development lifecycle. Defects prevented are measured against the baseline. The cost of fixing the prevented defects represents a clear productivity savings since no developer fix time is necessary if no defect exists. This measurement uses a static analysis tool to identify the defects by risk during development.

In the second case, we identify all defects detected early in the lifecycle using preventive controls for developers and compare the actual time to fix medium- and high-risk defects with the baseline case. The difference according to this analysis also represents a clear productivity gain. We use defect density counts from both development and the quality assurance/testing phase to determine productivity gain. The second measure uses a dynamic scanning tool typically used by software quality testers that automatically scans run-time versions of applications, and applies a risk criteria to separate defects into high- and medium-risk classifications.

Embedded Security Controls Boost Developer Productivity
The data demonstrate a significant gain in productivity with the security controls embedded in the development process over the baseline. In our case study under analysis one, the productivity delta is just under $21M annual gain in productivity (developer time reinvested in additive functionality) on a base of approximately $1.5 billion spent on development.Enterprise software security initiatives can easily develop a business case of higher productivity to justify investment in software security controls just as we have done. 

Image Source: Jim Routh

Finally, we want to state for the record that we believe our economic model applies for software-based commercial products as well as enterprise software.  Businesses focused on commercial products can and should encourage the same type of preventive controls we applied in our enterprise development situation.  The underlying economics are no different, and, perhaps surprisingly, the tech stacks are exactly the same.

Ultimately, this approach provides benefit to both the manufacturer and the customer. Building a car with hundreds of millions of lines of code?  Integrate software security.  Creating the next great Internet thing?  Integrate software security. The economic best interest of every firm developing software is to follow this lead.

Find out more about which activities, practices, and controls work for software security by visiting http://bsimm.com.

Check out the all-star panels at the 'Understanding Cyber Attackers & Cyber Threats' event June 21 and get an in-depth look at your cyber adversaries. Click here to register. 

Related Content: