How to reduce risk while saving on the cost of resolving security defects
Can you really reduce the cost per defect by implementing application security best practices? Let’s explore the “so what?” that proves their real worth.
The original version of this post was published on SecurityWeek.
1. Shift Left.
2. Test earlier in the development cycle.
3. Catch flaws in design before they become vulnerabilities.
These are all maxims you hear frequently in the discussion surrounding software security. If this is not your first visit to one of my columns it is certainly not the first time you have heard it.
These maxims certainly make sense and seem logically sound, but where is the proof? Show me the “so what?” that proves their real worth to organizations. Unfortunately, there exists a paucity of empirical research on the true value of implementing these maxims. Until now.
Exploring the economics of software security
A recent article was posted by Jim Routh, CSO of Aetna, Meg McCarthy, COO and President of Aetna, and Dr. Gary McGraw, VP of Security Technology for Synopsys. The article, titled “The Economics of Software Security: What Car Makers Can Teach Enterprises,” analyzes the total cost of ownership of software and the effect of utilizing security controls early in the development process.
If anyone can speak to this subject with total credibility, it is Jim Routh. Routh has been on the cutting edge of software security for many years. He is one of the most visible and successful practitioners of securing software. Routh actively drives application security adoption in crucial organizations such as FS-ISAC and NH-ISAC. He was an early adopter of the Building Security In Maturity Model (BSIMM) and openly discusses the BSIMM scores of Aetna with customers and partners to demonstrate the organization’s commitment to securing their software.
I will let you read through the study on your own as Routh, et al. lay out a compelling case. What I will reference is the findings on cost per defect grouped by the software development phase where the defect was discovered. This essentially measures the costs to remediate the defect post-discovery.
Examining the cost per defect
To set the context, let’s discuss the cost per defect for the traditional process of running a dynamic application security test (DAST) on an application for the category referred to as “Test” in the study. This has been the go-to method for testing applications for a very long time. The cost per defect for this method is $7,136 and provides us a baseline for some telling comparisons.
A subtle note to the study is that it speaks to defects. I would therefore point out that if you select products that test for both security and quality, the numbers will track the same way. As I established in an earlier column called “Security vs. Quality: What’s the Difference?”, a defect is a defect, whether it fall into the category of quality or security.
Let’s begin with the far left of the development lifecycle: requirements and design. Dr. McGraw, co-author of the study, has long been educating the market that half of all vulnerabilities start as flaws in requirement, architecture, and design. It is a shame that most organizations ignore this sage wisdom, as fixing defects in this stage is a true bargain. The study puts the cost per defect for requirements and design at $139 and $455, respectively. I would caution you to consider that effect runs much deeper, as changing architecture and design becomes very expensive as a project moves forward. Very expensive, indeed.
Enabling developers to build security in
But wait, you say. We are an agile shop and don’t have time for old-fashioned notions of architecture and design. I consulted with Jim DelGrosso on the subject. He is a Senior Principal Consultant and a colleague at Synopsys. He also serves as the Executive Director of the IEEE Center for Secure Design. Jim helped author a great paper for the IEEE called “Avoiding the Top 10 Software Security Design Flaws” and is one of the best at secure architecture and design. Jim’s suggestion is sensible and smart: dedicate a sprint to architecture and design so you can find your problems early in the development cycle for orders of magnitude less than finding them later. It turns out that building security in is not only smart, it also saves the organization money.
Next in the study is finding defects in the process of coding. I discuss the topic in detail in a previous column called “Moving Beyond “Moving Left”: The Case for Developer Enablement.” In short, this method uses a product that detects vulnerabilities in real time, educates the developer as to the nature of the defect, and coaches the developer how to fix the code on the spot. The cost per defect of implementing such a product is $977, or roughly 14% of the traditional method.
Finding defects during development also increases developer productivity as the developer fixes defects in real time without having to interrupt their workflow. Those who use such products generally report about a 15% increase in developer productivity.
Manage risk, costs, and compliance by building better software.
