There were a lot of application security-related news headlines in 2017 – from the Equifax breach, to WannaCry, to WordPress and Oracle – insecure software was everywhere. But from our perspective, there wasn’t much “new” in this “news” – it was the same security-related coding defects we’ve been seeing for more than 10 years, still prominent in just about all code today, still leaving organizations vulnerable, still causing breaches.
In fact,at the applications we scanned this year found that, on initial scan, 70 percent of them failed security testing when measured against the OWASP top 10 list of security vulnerabilities. And that number has remained fairly consistent over the past three years. In addition, we found that the same 10 most prevalent vulnerability categories from 2016 were again the same 10 most prevalent in 2017, with very little movement in the prevalence ranking.
These numbers paint a pretty grim picture of the state of software security, and indicate some significant trends in the AppSec space. On the other hand, these trends also reveal a light at the end of the tunnel. For instance, organizations are seeing positive AppSec results with developer training and the move to DevSecOps, while awareness around the threat of open source components is finally increasing. Brand name breaches due to open source component vulnerabilities have a way of doing that.
Developers do care about security, but don’t have security training
Why do we keep seeing the same security-related defects in code year in and year out? It’s not because developers don’t care about security. Case in point: We recently examined the numbers surrounding mitigation rates among our customer base. We found that, for the most part, developers aren’t trying to game the system by rejecting findings primarily as false positives, or as mitigated by design. In the past year, developers documented mitigation for just 14.4 percent of all the flaws found by our platform.
Although developers care about security, there is an education piece missing. Developers simply don’t have the training needed to identify or fix security-related defects. A recent CA Veracode/devops.com survey found that 68 percent of developers and IT pros say their organizations don’t provide them adequate training in application security.
But we also have clear evidence that closing this developer knowledge gap has a big security pay-off. When we looked at our customers that provide their development teams with eLearning on secure coding, their developer fix rates improved by 19%. Those who use remediation coaching to guide their developers in managing flaws found improve fix rates by a whopping 88 percent.
The good news is that awareness of this training gap is increasing. The recommendation to educate developers is even included in the just-released 2017 OWASP Top 10 list, which includes “application security education” as one of its recommendations for developers.
Indiscriminate open source component use continues to increase risk
Open source components continue to make developers lives easier, and code bases riskier. Our analysis of CA Veracode’s 2017 Platform data found that 88 percent of Java applications had at least one security flaw in a component.
And this is no longer just a theoretical threat either – this year, a ransomware attack against the San Francisco Municipal Transportation Agency (SF Muni) likely targeted a deserialization flaw in an open source component, Apache Commons Collections. Our figures show that approximately 53.3 percent of Java applications rely on Commons Collections versions (3.0 through 3.2.1 and 4.0) vulnerable to the deserialization flaw that left the SF Muni open to attack.
In turn, insecure deserialization was a new addition to the 2017 OWASP Top 10 list. We see this as a positive sign that the risk of open source components is moving into the spotlight, and hopefully movement into to-do lists will follow.
DevSecOps is happening
DevSecOps is moving beyond the buzzword stage; we’re seeing real evidence that this model is taking shape in the real world, and that it is improving application security results.
Again, looking at our scan data, it offers quantitative proof that the shift to devops and DevSecOps is accelerating. We’ve seen significant growth in the past two years in applications that are scanned monthly, or more often. Specifically, 28 percent of applications were scanned 12 or more times per year in 2017, up from 24 percent of applications in 2016.
And this shift is paying off as well. Devops organizations that tested frequently with sandbox scanning (developer-initiated scans early in the dev process) had a 48 percent better fix rate than those doing policy-only scanning (security-initiated scans late in the dev process).
Feel free to contact E-SPIN for Application Security infrastructure and application security, infrastructure availability and performance monitoring solution.