What Are The Key Considerations for Vulnerability Prioritization?
Table of Contents
When it comes to open source vulnerabilities, we seem to be in permanent growth mode. Indeed, data from Mend’s Open Source Risk Report showed 33 percent growth in the number of open source software vulnerabilities that Mend added to its vulnerability database in the first nine months of 2022 compared with the same time period in 2021. However, while some vulnerabilities pose a severe business risk — hello, log4j — others can be safely ignored. The question is, how do you effectively prioritize vulnerabilities? When prioritizing vulnerabilities, start by evaluating a vulnerability in terms of the following six factors:
1. Severity
This is arguably the most obvious consideration. Every vulnerability is classified in the Common Vulnerabilities and Exposures (CVE) list and is given a Common Vulnerability Score (CVSS) that expresses its severity. Generally, the higher the severity, the higher the priority to fix the vulnerability. However, that is not always the case. For instance, a CVSS score may take some time to be assigned to a new vulnerability, so zero-day vulnerabilities may slip below the radar, so to speak. Also, a vulnerability only poses risks if it’s associated with a component or dependency that you use in your code. If not, then it doesn’t threaten your code base.
Example CVSS Scores:
2. Exploitability
Some vulnerabilities are easily used, or exploited in attacks, making them likely to be used by threat actors. A vulnerability with a potentially severe impact can have low exploitability, while a less severe vulnerability might be easily and frequently exploitable. In this case, the less severe vulnerability may pose a higher risk of breach, and it would be prudent to prioritize it.
3. Reachability
Vulnerabilities are only exploitable if they’re reachable. In other words, when attackers can find a clear path from the code to the vulnerability. If you’re calling the vulnerable code, then the vulnerability is potentially exploitable. When there’s no path, there are no direct calls from the code to the vulnerability. Some vulnerabilities are found in code that’s not executed by your software or application, so they’re not reachable from your code. It would be a waste of time and resources to target these. Better to prioritize those that are reachable and therefore more easily exploitable.
4. Business risk
Another important question to ask is, What business risk does your software or application hold?” This consideration primarily revolves around data, particularly financial and personally identifiable data for customers. Information of this kind is valuable to malicious actors and will be a target for their attacks. So, vulnerabilities in software and applications that handle such data are prime candidates for prioritization.
5. Application usage
Similarly, you should consider how the software or application you’ve developed will be used. Is it a marginal or critical application? Will it be used frequently and by a large number and variety of people? Is it connected to the network, which is generally an attractive access point for attackers, and is it used in production? Is it for internal use only, or is it also used live by third parties, such as customers and partners? It stands to reason that heavily used critical applications, open to other users and organizations, and used in production, are likely to be more vulnerable and will expose you to more risk, so you may wish to prioritize them.
6. Fix availability
A further prioritization parameter is whether a fix is available. This may sound rudimentary, but there’s little point in prioritizing a vulnerability — bringing it to the front of the queue, so to speak — if there’s no fix available. At that moment in time, there’s nothing you can do to remediate the situation until a fix has been released.
It’s all about the context
All of these considerations should be considered contextually when prioritizing vulnerabilities. Implementing context-based prioritization works because what might be a serious vulnerability in one use case can have less or no impact in different use cases. For instance, you may encounter a severe CVE that makes any Windows machine running a particular application exploitable to some remote code execution, and attackers can take over the application. However, you’re on Linux, so although the vulnerability is potentially hugely impactful for millions of Windows users, it has no detrimental effect on you because you’re not using that operating system. Its threat goes from high to zero instantly, depending on this different context.
On the other hand, a medium severity vulnerability that enables people to attack you on Linux machines should take higher priority because damage can be done to you, even though its severity is lower.
Applying a prioritization funnel
Your application security solution should have the capability to funnel and evaluate vulnerabilities through each of these considerations.
With a prioritization funnel, thousands of undifferentiated and unfiltered vulnerabilities enter the top of the funnel. As they move, through the numerous layers of consideration criteria, many are filtered out, such as those that are:
- Mild in severity
- Unexploitable or low in exploitability
- Unreachable
- Lightly or never used in your code base
- Present low or no risk to sensitive data
- Present only in internal applications,, bearing no threat to third parties
- Ineffective in your operating environment
- Already fixable
Now, all of these may indeed be vulnerabilities, but the salient point is that their threat to your particular code, software, and applications is negligible. From your perspective, they are false positives and they can be disregarded at best, or at least deprioritized in favor of those vulnerabilities that made it through to the bottom of the funnel. These are your true positives, those vulnerabilities that still pose a real, immediate, and serious threat. These are the vulnerabilities you should prioritize. Importantly, by applying this process, you end up with a clear sense of top priority vulnerabilities that should be immediately addressed.
The ideal prioritization tool
Your ideal prioritization tool will automatically perform this funneling process to your usage specifications. Most importantly, it will not rely solely on severity metrics, and it will apply a broader context to vulnerabilities in order to streamline and accelerate your security and remediation processes.
For example, Mend Prioritize applies priority scoring based on the range of considerations that you specify. The priority score enables you to make informed decisions and implement automated risk-based policies so that the biggest overall threats to your business are remediated first.
It operates with Effective Usage Analysis technology that scans open source components with known vulnerabilities to assess whether your proprietary code is making calls to the vulnerable component. And Mend Prioritize has a market-leading reachability engine that identifies not just when vulnerabilities are exploitable but can specify whether they’re reachable.
Mend goes beyond simply warning “No” with a red shield, like other tools. We highlight usable components and dependencies with a green shield in our UI. We tell you which are not reachable and which are therefore safe to use. Our research shows that only 15 percent to 30 percent of vulnerabilities are indeed effective, so you can drastically reduce the number of vulnerabilities you need to prioritize and target those that matter most.
Build a proactive AppSec program
About the author
