State of Software Security Volume 9: Top 5 Takeaways for CISOs
We’ve just released the 9th volume of our State of Software Security report and, as always, it’s a treasure trove of valuable security insights. This year’s report analyzes our scans of more than 2 trillion lines of code, all performed over a 12-month period between April 1, 2017 and April 30, 2018. The data reveals a clear picture of both the security of code organizations are producing today, plus how organizations are working to lower their risk from software vulnerabilities. There are many significant and actionable takeaways, but we’ve pulled out what we consider the top 5 for security professionals.
1. Most code is still rife with vulnerabilities
More than 85 percent of all applications have at least one vulnerability in them; more than 13 percent of applications have at least one very high severity flaw. Clearly, we’ve got work to do. Most organizations are leaving themselves open to attack, and we need to focus on and keep at the application security problem.
2. The usual suspects continue to plague code security
We continue to see the same vulnerabilities pop up in code year after year. The majority of applications this year suffered from information leakage, cryptographic problems, poor code quality, and CRLF Injection. Other heavy-hitters also showed up in statistically significant populations of software. For example, we discovered highly exploitable Cross-Site Scripting flaws in nearly 49 percent of applications, and SQL injection appeared nearly as much as ever, showing up in almost 28 percent of tested software.
Why do these same vulnerabilities continue to emerge year in and year out? Most likely several factors are coming into play, but developer education clearly plays a big role. Veracode recently sponsored the
3. It’s taking organizations a long time to address most of their flaws
Finding flaws is one thing; fixing them is another. The true measure of AppSec success is the percentage of found flaws you are remediating or mitigating. This year, we took a detailed look at our data surrounding fix rates, and unearthed some troubling, and some promising, findings.
One week after first discovery, organizations close out only about 15 percent of vulnerabilities. In the first month, that closure reaches just under 30 percent. By the three-month mark, organizations haven't even made it halfway, closing only a little more than 45 percent of all flaws. Overall, one in four vulnerabilities remain open well over a year after first discovery.
Why does that slow fix rate matter? Because cyberattackers move fast. If you’ve discovered a flaw, chances are, the bad guys have too. And the time it takes for attackers to come up with exploits for newly discovered vulnerabilities is measured in hours or days. A big window between find and fix leaves a big security risk.
4. The volume of vulnerabilities means prioritization is king
Clearly, most code contains a significant number of security-related defects. And also clearly, fixing those defects is not a simple or quick task. Therefore, prioritization rules in application security today. And this year’s data shows that, although organizations are prioritizing their flaws, they aren’t always considering all the important variables. Most are prioritizing by severity of flaw, but not considering criticality or exploitability.
This is a big deal when you consider that a low severity information leakage flaw could provide just the right amount of system knowledge an attacker needs to leverage a vulnerability that might otherwise be difficult to exploit. Or a low severity credentials management flaw, which might not be considered very dangerous, could hand the attackers the keys to an account that could be used to attack more serious flaws elsewhere in the software.
The bottom line is that organizations need to start thinking more critically about the factors that impact what they fix first.
5. DevSecOps practices are moving the needle on AppSec
In the good news department, this year’s data shows that customers taking advantage of DevSecOps’ continuous software delivery are closing their vulnerabilities more quickly than the typical organization.
What’s the connection? It stems from the focus on incrementalism in DevOps, which focuses heavily on deploying small, frequent software builds. Doing it this way makes it easier to deliver gradual improvements to all aspects of the application. When organizations embrace DevSecOps, they embed security checks into those ongoing builds, folding in continuous improvement of the application's security posture alongside feature improvement.
Over the past three years, we've examined scanning frequency as a bellwether for the prevalence of DevSecOps adoption in our customer base. Our hypothesis is that the more frequently organizations are scanning their software, the more likely it is that they’re engaging in DevSecOps practices. And this year’s data shows that there is a very strong correlation between how many times in a year an organization scans and how quickly they address their vulnerabilities.
When apps are tested fewer than three times a year, flaws persist more than 3.5x longer than when organization can bump that up to seven to 12 scans annually. Organizations really start to take a bite out of risk when they increase frequency beyond that. Each step up in scan rate results in shorter and shorter flaw persistence intervals. Once organizations are scanning more than 300 times per year, they're able to shorten flaw persistence 11.5x across the intervals compared to applications that are only scanned one to three times per year.
Read the full SoSS report to get all the software security insights and best practices from our scan data. This year’s report contains details on the above points, plus data and insights on specific vulnerability types, the security implications of programming language choice, which industries are more secure than others, and more.
Related Posts
