State of Software Security v10: 5 Key Takeaways for Developers
In case you missed it, this year we launched our 10th annual State of Software Security (SOSS X) report! Armed with a decade of data, the Veracode team analyzed 85,000 applications to study trends in fix rates, mounting security debt, shifts in vulnerability by language, and more.
What did we uncover? At the core of our research, we found there’s still a need for better remediation processes and more frequent security scans. But we also uncovered some best practices that are leading to significant application security improvements. Read on for a snapshot of key takeaways that can help set you and your organization up for AppSec success in 2020.
Most apps still don’t pass crucial compliance tests
OWASP Top 10 vulnerabilities and SANS 25 software errors represent consensus listings of the most critical flaws in the industry, and while we’ve seen some changes in compliance rates across past editions of our SOSS report, the 10-year trend shows us that things haven’t shifted much as of late. Today, 68 percent of apps fail to pass OWASP on initial scan (down from 77 percent in volume one of SOSS), and 67 percent of apps fail to pass SANS on initial scan —the same figure in volume one as volume ten.
The fact that these common and serious vulnerabilities are still prevalent in code underscores the fact that we are not creating environments where developers can code securely. The absence of proper secure coding training, as well as the lack of access to the right tools, is clearly creating risk.
Android, PHP, iOS, and C++ have a high frequency of flaws
This year’s data analysis found that over 90 percent of Android, PHP, and iOS applications contain security flaws on initial scan. Ranking over 80 percent were C++, .NET, and Java, while Python and JavaScript came in with the lowest flaw rates.
Why do we see a higher rate of flaws in mobile languages? Perhaps the reason Android and iOS are two of the top offenders is that many mobile applications aren’t properly scanned before they’re uploaded to the Apple App Store and the Google Play Store. Ben Greenwald, Director of Software Engineering at Veracode, explains further:
“One reason Android and iOS applications may tend to have more security flaws on first scan is because mobile developers believe they are already covered. Developers might assume that Apple and Google thoroughly test apps before they’re released, or they rely on Apple and Google for testing under the assumption that a security infrastructure is already in place.”
This issue only further highlights the need for thorough internal and third-party testing processes to ensure that your applications are secure.
Language also adds yet another layer to the issue of unfixed flaws piling up on developer plates; the average security debt for PHP and C++ is massive compared to that of .NET, Android, Java, and JavaScript.
As two of the top languages for flaw rates, it makes sense that unchecked issues in PHP and C++ can spin out of control for development teams. So, what’s their deal? PHP’s start in the mid 90s came with a basic design that works well for smaller applications and beginners learning to code, but it has since been so widely adopted and stretched beyond its means that it is left highly vulnerable to flaws.
C++ is an incredibly robust language that powers many of the operating systems, browsers, and productivity apps that we use in our daily life. But with that great power comes the great responsibility to manage memory, guard against use-after-free, and keep stacks from exceeding the fill line. These flaws tend to accumulate over time and are easier to introduce than in many of the today’s more commonly used higher-level languages.
While some applications are prone to debt buildup because they use multiple languages or a basic flaw-heavy language like PHP, it’s important to consider the steps your team can take to counterbalance the prevalence of flaws—like reprioritization.
Remediation priorities are misaligned for top vulnerabilities
Out of the 85,000 applications tested (including 1.4 million individual scans), our data shows that 83 percent of apps have at least one flaw when they’re initially scanned. That’s an 11 percent increase from volume one to volume ten of the SOSS report - but the good news is we also saw an overall 14 percent decrease in applications with high-severity flaws.
The bad news? Focus is, it seems, not always placed on fixing the right flaws. For example, we found that A10-Logging is ranked the lowest in flaw prevalence but is at the top of the list for fix rate, the bottom of the list for incidents, and doesn’t rank for exploit risk. A5-Access Control is another mystifying trend. It ranks low in prevalence but towards the top of exploit and incident rankings, falling right in the middle of the list for fix rate.
Some flaws and fixes are consistent, though. Both A1-Injection and A2-Authentication sit toward the top of the list across the board, while A8-Deserialization is reliably stable in the bottom half of each category. This discrepancy sheds some light on which flaws are neglected, deferred, targeted, and prioritized, and how DevOps teams can more efficiently rank issues.
Flaws that can be remediated quickly on a small scope are naturally resolved ahead of flaws that are slightly more complicated, but often those severe issues are less difficult to fix, underscoring the need for a more comprehensive plan of attack.
Developers favor recency, adding to security debt
SOSS X shows us that developers typically follow a LIFO (Last In, First Out) method instead of a FIFO (First In, First Out) approach. With LIFO, developers run the risk of contributing to security debt when older flaws are stacked underneath newer issues. As time goes by, the probability of remediation drops significantly, and any unmitigated remnants slide into the land of security debt.
This trend highlights an ongoing battle with security debt across the industry and draws attention to how it muddies the waters of remediation. Fortunately, we have revealing data on scanning cadence that can help reduce an organization’s debt over time.
Bursty scans contribute to security debt—but it’s reversible
We mention security debt throughout the SOSS X report (and this post) because it can leave organizations vulnerable to attacks in the backlog of flaws, and slower to mitigate issues that arise out of the blue.
The good news is, this year we also uncovered evidence of practices that are chipping away at security debt. It’s all about scanning frequency. We know that “bursty” scanning cadences result in a higher prevalence of flaws over time, as opposed to steady and early scan processes with fewer flaws open at once. Sometimes bursty scanning simply fits your waterfall development cycle or pairs with testing schedules that are event-driven, but this can leave security holes where flaws are missed month to month.
Based on our data, we know that development teams can improve their median time to remediation (MedianTTR) by about 70 percent with established procedures and consistent testing schedules. Automating your processes to increase scanning tempo and improve prioritization reduces the security debt that your organization carries.
Read the report
Want to see all this data in one complete package? Read the full SOSS report to learn more about the state of DevSecOps, discover additional data highlights by industry, and more.
Related Posts
