When it comes to vulnerabilities, there is a range of severity and exploitability, which often dictates how quickly a flaw is fixed upon discovery. Most companies prioritize high severity and critical vulnerabilities, but ignore lower severity vulnerabilities. The highest severity flaws are less complicated to attack, offer more opportunity for full application compromise, and are more likely to be remotely exploitable — overall they tend to open up a wider attack blast radius.
In the State of Software Security Volume 9, we analyzed flaw persistence based on where vulnerabilities fall on our five-point severity scale, and we found that organizations hit the three quarters-closed mark about 57% sooner for high and very high severity vulnerabilities than for their less severe counterparts. In fact, our scan data indicates that low severity flaws were attended to at a significantly slower rate than the average speed of closure. It took organizations an average of 604 days to close three quarters of these weaknesses.
Here’s the catch: there could be a low severity vulnerability that is affecting your code and it could be used to exploit your application.
Is the Vulnerability in the Execution Path?
There’s another dimension that often isn’t taken into account when prioritizing fixes, and that’s whether the vulnerability is actually impacting the code. When it comes to open source risk, for example, we know that it is multi-faceted and complex. Simply having a library with vulnerabilities in it does not mean that your app is at risk – you have to first understand if a vulnerable method is being called. When leveraging an open source library, it’s very common for a developer to only use a small subset of that library for a very particular function or capability. This means that it’s highly likely your application never calls on a vulnerability in the library and, in essence, is not exploitable.
Rather than prioritizing fixing a high-severity vulnerability in a function that is not called by your application, it would be more advantageous to prioritize a medium-severity vulnerability that lies in the execution path and puts your customers at risk. When developers have this information, they are empowered to prioritize and immediately fix vulnerabilities that pose the highest likelihood of exploitation. Additionally, their remediation time is reduced by up to 90 percent. The time saved for your developers, and the decreased time the attack window is open, is crucial to protecting your data.
That being said, just because a vulnerability isn’t in the execution path doesn’t necessarily mean your application isn’t exploitable – it may simply mean we were unable to identify an execution path for the vulnerability. It’s still important to fix all of the vulnerabilities in your application, especially the high and very high ones. Vulnerable method information allows your team to know, out of all of the vulnerabilities detected, which ones have the highest likelihood of exploit.
How Veracode’s Software Composition Analysis Can Help
With many tools out there, developers will receive an extremely large list of vulnerabilities for all open source libraries packaged in your application, and they will have to make a judgment call on what to fix first – and how much is worth fixing before pushing to production. Download the Addressing Your Open Source Risk eBook to learn more about how Veracode’s combination of machine learning and natural language can help you efficiently and effectively manage open source risk.
