Why Do We Need Real-World Context to Prioritize CVEs?

Question: The CVSS severity rating seems to lack real-world context. How can a company prioritize fixes in such a situation?

Shachar Menashe, Senior Director, JFrog Security Research: Security teams and developers are wasting their precious remediation resources by relying on an incomplete method to determine whether a vulnerability is exploitable.

One of the most popular resources organizations use today is the Common Vulnerability Scoring System (CVSS), a standard framework for assessing the severity of vulnerabilities. It assigns each CVE a vulnerability severity score, ranging from 0 (no severity) to 10 (most critical), which reflects how hard the vulnerability is to exploit and how much damage it can cause if exploited. Most developers and security teams use the CVSS score as a guide for their vulnerability remediation programs.

The problem is that the CVSS severity ratings of most CVEs today are overinflated, so continuing to rely solely on this rating scale is misguided.

That’s because the current CVSS scoring system is based on a complex set of factors that don’t adequately incorporate the real-world impact of each vulnerability. Earlier this year, JFrog undertook an analysis of the 10 most prevalent open source software vulnerabilities from 2022 and found that, when looking at real-world impact, most flaws were harder to exploit than reported, and their high severity rating was deceiving. Specifically, 64% of the top 50 CVEs received a lower JFrog Security Research severity rating compared with the CVSS.

In that study, many of the more critical CVEs required complex configuration scenarios or very specific conditions for an attack to be successful, which was not reflected in the CVSS score. Without the proper context, organizations waste valuable resources mitigating software flaws that are unlikely to have any impact on their systems.

The Real Metric: Exploitability

Analyzing the context of a CVE requires considering real-world factors, such as:

• Whether the vulnerability is exploitable in a service’s default configuration or only under very contrived configurations.
• Whether a reachable path to the vulnerable code exists.
• Whether the software library vulnerability has a code precondition (meaning someone must use the library in a vulnerable manner).
• The likelihood that a vulnerable API will parse untrusted data.
• How potentially vulnerable software is deployed.
• The network environment and overall security mechanisms applied to the vulnerable software.

While CVSS scoring provides some context through its impact metrics (confidentiality, integrity and availability), these metrics are rated according to a theoretical “face value” without considering the actual impact the attack has on real-world systems. For example:

• A denial-of-service (DoS) attack that crashes a forked client process is much less severe than a DoS that crashes an important daemon, but they will both receive a high availability impact CVSS rating.
• A buffer overflow that doesn’t overwrite any meaningful variable has no security impact, but it will still receive a high integrity impact CVSS rating.

A good example of the latter is the OpenSSL CVE-2022-3602, identified in November 2022. The vulnerability was widely feared at first, but technical details revealed the vulnerability had no real-world impact. Nevertheless, CVE-2022-3602 is still rated with a high impact rating.

CVSS 4.0 Doesn’t Solve This

While CVSS 4.0 will include an “attack requirement” metric to reflect the conditions needed for an attack to succeed, it is still not detailed enough. (It can only be set to “none” or “present,” which does not account for the rarity of the attack requirements.) For example, a remote code execution (RCE) vulnerability that is exploitable only under extremely rare configurations or conditions and might not even be fully exploitable in any real-world scenario would have “attack requirements” marked as “present” — which would change the score slightly from 9.3 to 9.2. Organizations will still continue to receive 9.2 (critical) scores for theoretical RCE remote vulnerabilities that are exceedingly unlikely to happen. This needs to change.

Advice: Add Context

While the CVSS system is improving, using other resources in tandem can help provide a more accurate assessment of CVE criticality. When looking at nvd.nist.gov, pay special attention to the CVSS rating of the CNA, not just NVD’s CVSS rating. Distro-specific severity scores, such as the Ubuntu and Red Hat Linux distributions, and project-specific severity scores, such as Apache Web Server, Curl, and OpenSSL, will usually have a more accurate severity rating.

Also consider ways to integrate context into your remediation process. Research indicates few vulnerabilities are exploitable without highly specific preconditions. Combine real-world exploitability, CVE applicability, and contextual analysis to guide your prioritization and remediation efforts. Instead of asking developers to “fix everything,” arm them with the information they need to address the vulnerabilities that matter most.