The percentage of open source code in the enterprise has been estimated to be in the 40 percent to 70 percent range. This doesn't make the headlines anymore, but even if your company falls in the average of this range, there is no dearth of work to do to clean up, comply with AppSec policies, and ship the product. Phew!
So where do you start when it comes to resolving all the vulnerabilities uncovered in your open source libraries? By prioritizing the findings from your scans and addressing the most critical and relevant vulnerabilities first.
How do you prioritize? CVSS severities are an obvious choice, but considering the percentage of open source code you are dealing with, and depending on the language under the scanner, this alone might not bring the vulnerabilities to be addressed to a manageable number within your resource and time constraints.
We will look at some common prioritization approaches before looking at Veracode’s recommendation based on our deep expertise gathered from advising hundreds of customers about this aspect of their AppSec program.
Common prioritization approaches
You can resolve your findings to comply with your AppSec policy by prioritizing alongside one of a few dimensions. Here is the list of most common prioritization approaches:
- Threat-focused approach: This zeroes in on the flaws that are actively targeted in the wild through malware, exploit kits, ransomware, or threat actors.
- Vulnerability-focused approach: This prioritizes flaws and vulnerabilities according to how critical they are. For example, how easy they are to exploit, what their exploitation impact looks like, or if there is a public exploit available.
- Asset-focused approach: This gives the highest priorities to vulnerabilities that are associated with critical assets, and then orders the rest by how dangerous they are.
Some organizations measure the exploitability of different flaws and vulnerabilities, taking a threat-focused approach as outlined above. This can also factor in the maturity of known flaws which sometimes impacts how easy it is to remediate, or how exploitable it is out in the wild.
While these approaches are a good starting point and cover the broad base of risk, there is an additional piece of information that can make it easy for security stakeholders and developers to prioritize their Software Composition Analysis (SCA) scan findings when operating under tight resource and time constraints.
Vulnerable methods: a powerful arrow in your AppSec quiver
If the goal of AppSec is to ship clean code fast, then Veracode’s vulnerable methods feature is a powerful arrow in your quiver to hit that target.
Veracode’s vulnerable methods feature goes beyond severities and exploitability to answer the key question for prioritization: How is this finding from the SCA scan relevant to my code? It answers that question by pointing to the precise function/method that makes a library vulnerable. This allows you to quickly assess whether it is worth the effort to remediate an SCA finding.
Once a library is known to be vulnerable, our security research team researches and documents the exact function/method that makes it vulnerable. This team (say hello to them if you visit Singapore) of security experts, data scientists, and programmers continue to add new languages to our repository of languages for which we provide vulnerable methods coverage.
When you’re ready to tackle your security backlog, examine how particular applications use vulnerable methods and prioritize them in a way that reduces the immediate threat quickly.
Getting ahead of possible exploits while reducing debt
Security debt and unresolved vulnerabilities can feel daunting to developers and security professionals, especially as open source code only continues to increase its footprint in enterprise applications. But with a powerful tool like Veracode’s vulnerable methods, you can go beyond severity or exploitability and focus on what really matters to your organization.
Learn more about Veracode’s Software Composition Analysis solution by reading the latest State of Software Security: Open Source Edition, watching our demo video, and reading further about open source risk.