How to Prioritize Application Security Flaws

Why Fixing Old Code Must Be Part of Your Secure Development Strategy

how to prioritize application security flaws

Volume 10 of the Veracode “State of Software Security” report makes one fact abundantly clear: there’s no shortage of security flaws to be fixed in the applications we use every day. So many, in fact, that it’s virtually impossible to address them all, which raises the question: how do you prioritize which flaws to fix?

The numbers are mind-boggling. For the 10th edition of its report, Veracode looked at scans of 85,000 applications from its cloud-based software security testing platform (up from fewer than 1,600 in Volume 1 of the report). It found more than 4 out of 5 (83%) of applications had at least one flaw, up from 72% 10 years ago.

What’s more, two out of three applications failed to pass initial policy compliance tests based on the OWASP Top 10 security risks and the CWE/SANS Top 25 Most Dangerous Software Errors. That means two-thirds of all applications Veracode scanned had flaws considered to be critical by industry standards.

Remedying this high-risk situation requires at least a two-pronged approach: fixing errors that already exist and educating developers on how to prevent them in the future, says Chris Kirsch, Director of Product Marketing at Veracode.

Prioritizing the critical

In terms of fixing errors, focus first on those that contain highly critical flaws that are easy to fix, he says. Then move on to those flaws that are critical but a bit more time-consuming to fix and so on.

The CWE and OWASP lists are good places to start in terms of determining how critical a flaw is. And tools like Veracode’s will show whether a certain vulnerability is cropping up more often from a specific development team vs. others. In that case, you can train developers on that team to recognize the vulnerability and prevent it in their own code – ideally as part of the DevSecOps process – as well as correct it in other, older code.

Also high on the priority list are critical flaws that are easy to exploit. Examples include applications that contain hard-coded security credentials such as passwords, often used to simplify the process of setting up new systems and for privileged user access. These vulnerabilities are simple for intruders to find and exploit with password-guessing tools, so should be remedied. The same goes for SQL injection flaws, which can give an intruder unfettered access to resources, and cross-site scripting, which puts website users at risk, Kirsch notes.

Overcoming recency bias

One enemy when it comes to fixing flaws is recency bias. The State of Software Security report shows if a flaw isn’t fixed within the first month of its discovery, the chance it will ever be addressed falls dramatically – to 10% in the second month and down from there. The issue is developers have trouble accepting responsibility for code that may be years old, and which they had nothing to do with writing. That’s especially true when they’re compensated and measured based on how quickly they get code out the door, Kirsch says.

“Minimizing vulnerabilities in existing code needs to be in their job descriptions,” he says. Getting executives behind that idea may require making a business case showing how software is integral to corporate profit, and that application security is thus critical to success. Then perhaps execs will get behind the idea of making how well developers fix older code part of the evaluation process, complete with bonus incentives.

Such an approach will help companies tackle an insidious problem they all face: the security-to-debt ratio. That refers to the team’s capacity to remediate flaws relative to the number of flaws that must be addressed, including both older, existing flaws and those being introduced in new software.

Some teams work in spurts to address a backlog of old flaws, but Kirsch says Veracode’s analysis shows companies that reduce flaws at a steady pace over time do better in overall flaw reduction. And in terms of preventing new flaws, he says two approaches work well: security training for developers and providing them feedback directly in the integrated development environment where they work, so they can address issues as they crop up.


Copyright © 2020 IDG Communications, Inc.