Veracode’s State of Software Security Report Sheds Light on “Security Debt”

Development teams are challenged to keep up with flaw remediation, which, if flaws exceed capacity, can result in a growing pool of unresolved issues.

Research for Veracode’s Tenth Annual State of Software Security report revealed that although awareness of the importance of application security has increased over the past decade, development teams still struggle to keep up with flaw remediation.

One indicator is the meantime to remediation (MTTR), the average time it takes to remediate application flaws. In the first year of the survey, the MTTR was 59 days. In 2019, however, the MTTR has risen to 171 days. Veracode dug deeper into this statistic and found the median (or the middle value in the series of values) for remediation time remained at 59 days taking the most recent data into account. Veracode explains that this indicates that times to fix typical issues haven’t changed, but there is a growing log of “security debt” or unresolved findings.

Veracode found that certain types of flaws are more likely to become security debt than others. The largest amount of security debt is comprised of cross-site scripting (XSS), with significant percentages attributed to injection, authentication, and misconfiguration flaws.

What Development Teams Are Doing to Decrease Security Debt

The Veracode report points out that, just as with financial debt, security debt requires “changing habits to pay down balances.” DevSecOps, integrating security into the development process, is a step in the right direction.

Additionally, Veracode has observed that how often security testing occurs can make a significant difference in security debt. Teams that scanned applications 12 or fewer times per year logged a median TTR of 68 days. But teams that scanned 260 or more scans per year — daily or more often — the median TTR was only 19 days, a 72 percent reduction.

How a flaw is prioritized also has an impact on how quickly it is remediated. Veracode reports that there is a 22 percent chance that a flaw will be fixed in the same month it’s discovered, but only a 10 percent chance in the second month and a 3 to 5 percent chance after eight months. These findings suggest a “recency bias.” Although Veracode found that severe flaws received priority, developers often follow a last in, first out (LIFO) method rather than a first in, first out (FIFO) approach to fixing flaws.

Does a Security Debt-to-Income Ratio Apply?

Veracode drew another parallel between financial debt and security debt and investigated whether there is a security debt-to-income ratio. For this comparison, “income” is a development team’s working capacity that can be devoted to remediating flaws.

The 2019 survey found that, on average, 27 percent of teams fix more flaws than they found, but 49 percent found more flaws than they fixed. The majority of teams fall within a +/- 2x capacity, but Veracode points out that some teams fix up to 100 times the number of flaws they discover, or vice versa.

Security Debt and Language

Veracode’s report found that differences in the amount of security debt with respect to the programming languages used among the 85,000 applications considered in this year’s research are significant. PHP apps have the largest amount of security debt, and C++ applications have security debt that’s three to five times greater than .NET applications. Although it’s usually impractical to switch programming languages, it is worth recognizing that security debt may be related to language, and it’s wise to take proactive steps to minimize it.

Advice for Your Security Debt Reduction Plan

Veracode’s report concludes that ignoring security debt, like financial debt, is a risky course of action. A smarter strategy is to “fix new findings and burn down the old in sprints.” Periodic “security sprints” can target security debt, but bear in mind that until those flaws are remediated, you are running the risk that they may be exploited.

Download the full report for more findings and insights from Veracode’s State of Software Security, Volume 10