/feb 20, 2020

What Our Data Reveals About Security Debt

By Meaghan Mcbee

It’s a habitual practice we learn from an early age; keeping track of loans and credit card bills reduces overall debt and makes it easier to bring debt down quickly, avoiding those pesky spikes in interest. That very same practice applies to software security testing. Software is tested, vulnerabilities are revealed, and unaddressed vulnerabilities build up over time as interest in the form of extra work, which compounds into security debt that’s increasingly difficult to reduce the longer you wait.

Often, the solution is reprioritizing flaws and improving fix rates to reduce liability over time. In our 10th annual State of Software Security (SOSS X) report, we discuss how some of our findings from over 85,000 application scans correlate with mounting security debt—and why you should pay attention.

Debt dwindles with frequent scanning

Just as making consistent payments on your credit card reduces debt over time, a frequent scanning cadence can lower the amount of debt your organization carries. When surveying the findings in our SOSS X report, we saw that frequent scanners (300+) have 5x less debt than infrequent scanners and they see a 3x reduction in median time to remediation (MedianTTR), or the amount of time it takes to fix flaws.

Scanning Cadence

Misaligned remediation priorities add to interest

In SOSS X, we talk about how some developers operate on LIFO (Last In, First Out) or FIFO (First In, First Out) methods for fixing flaws. Standard remediation procedures are not one size fits all—what works for your organization may not work for another. But the data we studied shows the likelihood of a flaw being fixed in the first month is only about 22 percent. That number drops down to 10 percent for the second month and 3 to 5 percent as time goes on.

Remediation Time

It’s clear from this data that developers are prioritizing the most recently found flaws above all else. The problem with this process is that it doesn’t take into account what is actually increasing risk. Ultimately, an older Cross-Site Scripting vulnerability is just as dangerous as a more recently discovered one. However, this chart sheds light on the relationship between scanning cadence and security debt; if we’re paying more attention to recently discovered flaws, frequent scanning means additional newer flaws to address. Boosting your scanning cadence and sitting down as a team to figure out your approach to prioritizing flaws can help set you on the right path. 

Some industries are more prone to debt than others

Security debt doesn’t discriminate. It shows up in every industry, though some are more likely to accrue debt than others depending on how they prioritize fixes over time, as previously discussed. Data from SOSS X shows us that the Manufacturing and Government/Education industries carry more debt on average than other prominent industries.

Security Debt by Industry

What’s most important to note, though, are the trends over time. For example, we can see that around month four, organizations in Government and Education have an uptick in average fix rates. While Retail doesn’t carry much debt overall, companies tend to remediate the bulk of their flaws by month six or seven and contribute to debt reduction.  

Security needs vary (capturing quick payment information versus storing robust patient histories and treatment plans, for example), but data from your specific industry will help you keep a pulse on average fix rates for security debt. You and your team can then review this data on a consistent basis when creating long-term plans for eliminating flaws.

PHP and C++ build up debt the fastest

Your plans for fixing flaws and reducing debt should factor in the languages you’re using. Why? The average security debt for PHP and C++ is huge and tends to grow over time, especially when compared to .NET, Android, Java, Android, and JavaScript.

Language Flaw Debt

Issues with these two languages are the results of simplicity and age: PHP is suited for beginners and is thus susceptible to insecure coding, while C++ is a powerful language that requires some hands-on management of memory and stack control – vulnerabilities that are easier to introduce in C++ than in more common languages.

It’s difficult for most teams to change the language they’re using at work, but it’s important to keep in mind which languages easily add to security debt. Carrying this awareness and understanding changes in language trends will help you prepare efficient security processes throughout your career.

Cross-Site Scripting carries the heaviest liability for debt

When we look at the layers of flaw percentage by application age, it’s apparent that Cross-Site Scripting (A7-XSS) carries the largest amount of debt across applications. There’s also a slight rise in percentage as we inch closer to the 7-month mark, which tells us that XSS (among others) is a notable contributor to security debt.

Cross-site Scripting

XSS attacks occur when a malicious script is injected into a webpage and it alters the way that page behaves, opening the site up to damaging security holes open to unwanted activity, like bypassing authentication or stealing sensitive information. This prominent flaw is not picky when it comes to language, either, with notable findings in .NET, iOS, Java, JavaScript, PHP, and Python. Spanning languages with prevalence and risk, XSS is one to keep an eye on as you work towards reducing your security debt.

Read the full SOSS X report

Want more info? Check out our SOSS X page for the full report and additional data to absorb as we head into 2020. You can also listen to our podcast series with IDG, in which three of the episodes dig into security debt to drill down on different industries, why security debt grows deeper, and what's behind the buildup of unfixed flaws. 

 

Related Posts

By Meaghan Mcbee

Meaghan McBee is a Senior Content Marketing Manager at Veracode, responsible for creating content around best practices in application security and the current state of DevSecOps.