What Are The Key Considerations for Vulnerability Prioritization?

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 — while 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.

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.

Keep reading ?? go.mend.io/3GciYi7