Fewer Applications Carry OWASP Top 10 Flaws
Cybersecurity mavens for years pleaded with software executives to prioritize secure development. Every code bug smooshed during development or swept away during quality assurance prevents yet more exploitable vulnerabilities.
See Also: OnDemand | Navigate the threat of AI-powered cyberattacks
Secure development proponents may finally have momentum, based on an accelerating count of applications that don’t sport an Open Web Application Security Project top 10 security flaw. That’s according to research presented by Chris Wysopal and Jason Healey.
In 2010, 77% of all software applications contained an OWASP top 10 flaw, a figure that persisted at the high number of 68% by 2020, said Wysopal, co-founder and chief security evangelist at Veracode, during a RSAC Conference session in San Francisco on April 28.
At that “ridiculously slow pace, I was like, we’re not going to get to 50% until I’m in an old age home,” Wysopal told Information Security Media Group. “It’s going to take us 20 more years, it was a little depressing, you look at these metrics and not many are passing and the improvement rate is so slow, we’re just barely doing it.”
But something must have clicked over the past five years, with OWASP pass rates surging from 32% to 52%. At that rate, “it’s possible we get to 72% of apps passing in five years, and then we’re really talking – like, wow, the vast majority of apps are actually secure,” Wysopal said.
Healey, a senior research scholar at Columbia University’s School of International and Public Affairs, also expressed optimism, saying the gains are tied to multiple improvements. Among them, a better mindset by CISOs, from “how are you doing?” to “how are we doing?” In addition, code-improvement practices have had a big effect because they’re not bashing one vulnerability, aka CVE, or another, but rather “big categories of vulnerabilities.”
All of this “buying down risk” across different categories of flaws means organizations have fewer vulnerabilities to patch, while forcing adversaries to up their game, because there are fewer easy-to-exploit flaws such as buffer overflow vulnerabilities, he told ISMG.
The measured improvements come even as some might feel the battle is being lost against cybercriminals and nation-state attackers. “We’re getting our asses kicked all the time because we’re having all of these incidents, and it doesn’t feel like we’re making progress,” Healey said.
Research based on asking the right questions and looking at data over different periods of time shows otherwise. “When you start looking at that, you can really find these areas for optimism,” Healey said. “It’s still going to require hard work and discipline – and the right kind of hard work, but I’d say: Stay optimistic.”
Wysopal said other measures also reflect a continuing overall improvement in the state of secure code, including the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. Aside from 2021, when there was a spike – it’s not clear why – he said that in every other year from 2020 onwards in the KEV, “we saw about 130 vulnerabilities per year getting exploited,” even as “the number of CVEs keeps going up.”
Bug bounty programs could help explain why the number of new CVEs keeps going up – as vulnerability hunters find more “low and medium-hanging fruit,” he said. Also, the overall Exploit Prediction Scoring System average, which gauges the risk that a vulnerability will be exploited, has continued to decline by about 30% over the past five years, he said.
Paying Down Security Debt
Another big payoff comes from paying down security debt. Wysopal said organizations with the most mature secure development practices fix 10% of their vulnerabilities on an annual basis and avoid having any security debt that is more than a year old. By contrast, “the lagging companies fix less than 1% of open bugs per month,” he said.
This strategy isn’t always feasible. Notably, “we found that 70% of critical debt was in third-party code,” and teams that built software with third-party – or sometimes fourth or fifth party – dependencies sometimes must wait months for fixes to become available, Wysopal said. “Some software packages that are widely used by other software packages are harder to fix, so you have a lot what we call transitive dependencies.”
There’s no easy solution for this challenge. “When you’re using open source, you’re really dependent on the fixing speed of another team that is not getting paid, and they’re just doing it because they love to do that project,” he said. “It’s something that teams should really, really be concerned about.”
AI-Generated Code
Another wrinkle is that more code is built by artificial intelligence tools – Google and Microsoft each say roughly a third of their code is AI-generated. Developers report being more productive, shipping on average 50% more code when they use AI tools.
Wysopal said such AI tools appear to produce code with vulnerabilities at the same rate as classical development tools. More code shipped risks a greater number of vulnerabilities.
To address this, “for me, the only solution is to use more AI,” he said, while acknowledging the irony. “AI is causing a problem, let’s use AI to fix it” (see: Unpacking the Effect of AI on Secure Code Development).
Language models trained on secure code examples have the potential to be extremely good at the task of not only writing secure code, but fixing it, and knowing specifically what bad code looks like, he said.
Reasons to Be Optimistic
Against this backdrop, Wysopal and Healey acknowledged that based on their study, 48% of applications didn’t pass the OWASP top 10 test. But the trend line is headed to the right direction, at finally at a laudable pace and delivering big upsides.
An application that passes the OWASP top 10 test isn’t bulletproof, but it is – relatively speaking – tougher to exploit.
“By draining the OWASP top 10,” Wysopal said, “that makes life harder for attackers.”
“There will always be vulnerabilities. But the goal remains trying to drive them down to zero,” Healey said. For software, tackling “the simple, fixable stuff first” takes just “a bit of discipline” in software development lifecycle practices.
“Anytime you’re forcing your adversaries to be heroic, then they’re the ones that have to do heroism, not us and that’s a win,” Healey said. “That’s why I love this: If we can take away the easy vulnerabilities, we’re forcing them to spend, we’re forcing it so that it’s less just ‘point and attack.'”