We just published our State of Software Security 2017 (SoSS) report, and, as always, it is chock-full of valuable data and insights about the security of applications. Based on 400,000 application scans across our customer base over a recent 12-month period, this year’s report is a gold-mine of intelligence about how organizations are approaching AppSec, what’s working, and what isn’t. This analysis is valuable for teams across organizations – from developers to CEOs – but here we highlight the findings most relevant and illuminating for those in the CISO role.
This year’s data shows that, as in years past, application security testing is without question a worthwhile endeavor. Our 2017 SoSS data revealed that OWASP pass rates improved by 13 percent from first scan to last scan. And not only is testing effective; it’s necessary. This year we also found that 77 percent of apps had at least one vulnerability on initial scan.
The crux of the issue here is that a lack of developer training in security makes testing and remediation of software a necessity, rather than a nice-to-have. Developers aren’t willfully ignoring security issues; rather, they simply don’t have the skills or resources needed to create secure code. Take SQL injection (SQLi) — a well-known and highly exploitable vulnerability. SQLi pops up at the start of scanning at a pretty consistent rate among our customer base over the past several years, showing how developers continue to introduce common flaws into their code. The percentage of apps with SQLi has been hovering around the 30 percent mark since 2011. In 2017, we were at 27.6 percent.
Bottom line: Application security testing is both effective, and critical.
Testing makes a difference, but a long-standing, comprehensive AppSec program is a game-changer. This year’s SoSS report found that programs that have been around for 10 years had a 35 percent better OWASP pass rate than programs in place for a year or less.
This data points to the fact that application security success is incremental; you won’t see dramatic progress right out of the gate, but those who stick with it over time will eventually see significant results. What do these long-standing, mature programs look like? They’re comprehensive initiatives that feature multiple testing techniques – that address code security from inception to production – and third-party software and components. These programs also include developer training, and processes that measure the results of the program.
In addition, although many predicted that the shift to DevOps would create a roadblock to security testing, our data reveals that DevOps actually accelerates AppSec’s incremental gains. This year, DevOps organizations that tested frequently with sandbox scanning had a 48 percent better fix rate than those doing policy-only scanning.
The use of open source components in code continues to create significant risk. Most open source components remain unpatched once they’re built into software. In fact, this year, we found that 88 percent of Java applications had at least one flaw in a component.
This isn’t just theoretical risk either. Flaw-riddled components took center stage this past year as news broke of a number of high profile breaches caused by widespread vulnerabilities in open source or commercial components. In March 2017, a number of high-profile targets got zapped by what we dubbed the “Struts-Shock” flaw. This critical vulnerability in the Apache Struts 2 library enables remote code execution (RCE) attacks using command injection, for which as many as 35 million sites were vulnerable. All it takes is a well-crafted web request to trigger the vulnerable code.
Getting a handle on open source component use starts with visibility. When a big vulnerability in an open source component is announced, you’ll never patch in time if you have no idea where you are using the vulnerable component. Software composition analysis technologies help you create an inventory of which components and which versions you are using where – making keeping up with the bad guys much easier.
Developers need the tools to both find security-related defects in their code, and to fix them. And it’s the fixing part that can get tricky – especially considering that a recent survey we sponsored found that less than one in four developers or other IT pros were required to take a single college course on security. Meanwhile, once developers get on the job, employers aren’t advancing their security training options, either. Approximately 68 percent of developers and IT pros say their organizations don’t provide them adequate training in application security.
The good news is that this is a problem with a solution. Our 2017 SoSS data shows that developer training leads to significant results. In fact, teams with developer eLearning in place improved developer fix rates by 19 percent. Even more impressive, remediation coaching (consulting services that offer analysis and advice to developers alongside the scan results) improved fix rates by 88 percent.
CISOs are increasingly looking toward identity-centric security as a way to protect users and stop breaches.
But access controls are ineffective if the underlying application is vulnerable: This year, 42 percent of scanned applications were found with credentials management vulnerabilities on initial scan. Ultimately, applications must be secured as well as users.
Do these points reflect your experience with application security? Find out more about how your peers are tackling AppSec, and how your industry as a whole is faring in this space – check out the full 2017 State of Software Security report.