State of Software Security v11: Key Takeaways for Developers
We recently released volume 11 of our annual State of Software Security (SOSS) report, which analyzes the security activity and history of applications Veracode scanned during a one-year period. Giving us a view of the full lifecycle of applications, that data tells us which languages and vulnerabilities to keep an eye on, and how factors like scanning frequency can impact your remediation time.
This year’s report also explores the idea of nature vs. nurture when remediating flaws and improving security. In other words, which security factors do developers like you have control over, and which are completely out of your hands? You likely have no control over the size of your organization and even the size of your application (“nature”), but you can “nurture” factors like frequency and scanning via API to improve security efforts.
Read on for key takeaways from SOSS v11 and for more information on what you can do to give your application security (AppSec) a boost.
Using SAST through API improves remediation time
It should be no surprise that the right combination of tools and integrations with frequent scanning means more effective flaw remediation. Data from SOSS v11 backs that up; when running static analysis (SAST) scans through API, organizations can remediate flaws 17.5 days faster on average.
Efforts like more frequent scanning, pairing dynamic analysis (DAST) with SAST, implementing a steady cadence, and using Software Composition Analysis (SCA) with SAST can help you remediate more vulnerabilities faster and keep your security in check. On the flip side, higher flaw density or a larger application greatly slows the remediation process by more than 50 days – especially for larger legacy, applications.
Information Leakage is the most common flaw…
…with CRLF injection, cryptographic issues, and code quality close behind. These four most common flaws didn’t change between last year’s report and this year’s report, which means they’re likely not going anywhere anytime soon and important to keep an eye on.
For developers, knowing the most common flaws is critical to understanding how they’re introduced, how to prevent them, and how to fix them quickly to “nurture” your situation. That’s especially important for the most high-risk vulnerabilities, such as Injection flaws like CRLF and SQL that reign supreme on the list of OWASP Top 10 Web Application Security Risks.
Open source creates an expanding attack surface
You work hard and you work fast. Projects don’t slow down or wait for you to write code from scratch, which is why so many developers like you rely on open source libraries and third-party code to speed up production. But there’s a problem: open source code, though used virtually everywhere, creates a wider attack surface for threat actors. And even trickier, some languages more heavily utilize open source libraries, which means applications written in those languages inherently carry more risk.
The chart above, where each dot represents 1 percent of applications in each language, highlights how many applications have code composed of open source libraries. You’ll notice that Java applications are a big offender as they cluster to the right, indicating that they’re almost entirely written in third-party code (which is accurate: we know that most Java applications are 97 percent third-party code).
Some languages like JavaScript and Python are curious, though, forming a barbell with clusters at both ends. This indicates that applications tend to be either mostly written in-house, or mostly composed of third-party libraries. Far-left clusters for C++ and PHP indicate that those codebases are mostly written in-house, with .NET showing the most even spread to indicate that these developers are more flexible with open source libraries.
C++ and PHP have a high number of severe flaws
In a standalone report, we broke down flaw frequency by language and found that C++ and PHP are offenders for high (and very high) severity flaws. C++ came out on top, with 59 percent of C++ applications having high and very high severity flaws, while an equally worrisome 53 percent of PHP applications also have severity flaws.
On a positive note, we found that just 9 percent of JavaScript applications have high or very high severity flaws with Python close behind at 10 percent. For a detailed breakdown of flaw frequency by language, read the standalone report here.
Fewer scans mean drawn out remediation time
On the surface it may seem like scanning a few times a year or even once per month is enough, but the numbers say otherwise. We know from our own customer data that more frequent scans can drastically reduce the amount of time it takes to close your found flaws and secure your applications.
As shown above, scanning just 1 to 12 times per year results in a remediation time of 217 days – which means more flaws can pile up, adding to security debt and diminishing AppSec efforts. On the other hand, if you scan weekly or even daily, your time to remediate drops around or below 70 days. Though there are a variety of things that can impact the “nature” of your application, scanning frequency and cadence are both in your control to “nurture” as a developer.
For more information from our SOSS v11 findings, download the full report.
Related Posts
