Over the past several years, there have been many changes to software development and software security, including new and enhanced application security (AppSec) scans and architectural shifts like serverless functions and microservices. But despite these advancements, our recent State of Software Security (SOSS) report found that 76 percent of applications have security flaws. Yet CISOs and application security program owners still find themselves having to justify and defend application security initiatives.
Members of the Veracode Customer Advisory Board (CAB), a group of AppSec professionals in several industries, faced this challenge as well. In response, a working group subset of the CAB collaborated to establish a set of metrics that security professionals can use to establish, drive adoption, and operationalize their application security program. These data points should help inform decisions at different stages of program maturity while answering the basic question: is the application security program effective or not?
How to determine and justify the required resources for an application security program
AppSec managers need a justifiable AppSec approach and dataset that set parameters around the program, give a starting point, and set up how the program will grow over time. That approach starts with providing evidence that an application security program is necessary and that it will reduce risk.
To show that an AppSec program is necessary, call attention to data points around flaw prevalence in applications (76 percent) or the average cost of a data breach ($3.86 million).
To show that AppSec programs reduce risk, consider stats like the one from our SOSS report that found that organizations scanning for security the most (more than 300 times per year) fix flaws 11.5x faster than organizations scanning the least.
How to determine and prove that development teams are adopting software security practices
AppSec success hinges on development buy-in and engagement. Therefore, proving that your AppSec program is effective requires evidence of developer adoption.
Consider highlighting the rate at which development teams are taking advantage of APIs to integrate security into their processes Then prove that developers are taking the time to fix the identified flaws by showing your developer’s fix rate (the # of findings closed / the # of findings open).
By examining the fix rate, you can see if developers are actively adopting AppSec practices by fixing – not just finding – vulnerabilities. The fix rate also shows you where additional training or resourcing investment is needed.
How to determine if the application security program is operating efficiently
AppSec programs are meant to be ongoing – not a one-off project with an end date. An effective AppSec program is ultimately a component of the software development process, just like QA, and the measures of success need to reflect that.
A key metric here is the correlation between security activities early in the development process and the number of security flaws found in a release candidate or in production. For example, the figure below shows the relationship between security testing early in the development process, in the individual IDE of a software developer, and the number of flaws found in the release candidate.
In addition, use metrics to show that you’re fixing more flaws than you’re finding.
Or show that your applications are passing your security policy.
By using the metrics established in the CAB report, and adding further context and background to the metrics, you can tell the story of your AppSec program to drive further adoption.
For more tips on proving the success of your AppSec program, including additional metrics, check out our full report, Communicating Application Security Success to Your Executive Leadership.