Beyond CVSS: A Risk-Based Approach to Vulnerability Prioritization

Your vulnerability scanner flags a high-severity issue: CVE-XXXX-XXXX with a CVSS score of 9.8, labeled as critical. It's tempting to prioritize this fix immediately, but the question arises—critical based on what standards? CVSS severity and organizational risk are not identical concepts, and comprehending this disparity can significantly alter how a vulnerability management team approaches remediation.

First, let's explore what CVSS actually conveys. CVSS stands for Common Vulnerability Scoring System and offers a standardized method to describe the technical severity of vulnerabilities. It aids in answering questions like: How severe is the vulnerability? What level of technical impact could exploitation cause? What attributes contribute to its severity?

However, CVSS alone doesn't address all questions needed for a remediation decision. For instance, it doesn't account for factors such as the system's internet accessibility, the actual running status of the vulnerable service, whether the vulnerability is actively being exploited, the importance of the affected asset, the presence of compensating controls, or the potential business impact of compromise.

CVSS v4.0 introduced multiple metric groups: Base (intrinsic characteristics of the vulnerability), Threat (threat landscape characteristics), Environmental (organization-specific characteristics), and Supplemental (additional characteristics). Thus, stating "CVSS is just a single number" is inaccurate. A more precise statement is: A CVSS Base Score alone is not a comprehensive organizational risk assessment.

The reason a CVSS score of 9.8 seems urgent is due to its very high technical severity. However, converting this score to "Fix before everything else" doesn't necessarily follow. Let's compare two systems for clarity:

Example A (CVSS: 9.8) - An internal development server that isn't externally accessible, not known to be exploitable, has low business criticality, and strong network segmentation.

Example B (CVSS: 7.5) - An internet-facing production server that is publicly reachable, known to be exploitable, critical to business operations, and lacks compensating controls.

While the first vulnerability has a higher CVSS score, it might not represent the most immediate organizational concern due to its context. The key takeaway is that severity indicates some aspects of risk but doesn't encompass the entire picture. A simplified way to think about vulnerability risk is: Severity + Exploitability + Exposure + Asset Criticality + Business Impact = Risk.

Recognizing that risk is context-dependent is crucial. Two vulnerabilities with the same CVSS score can lead to varying levels of organizational exposure.

To illustrate this with two vulnerabilities both scoring 9.8, consider:

CVE-A: Internet-facing, not exploited, low business criticality, low asset value, and proper controls in place.

CVE-B: Internet-facing, actively exploited, critical business service, high asset value, and insufficient compensating controls.

Despite identical CVSS scores, their organizational impact differs significantly. This highlights the necessity for vulnerability management programs that consider contextual factors rather than merely ranking findings from highest to lowest CVSS score.

Environmental factors also play a vital role. For example:

Scenario A: Internet → Firewall → WAF → Application → Vulnerable Server

Scenario B: Internet → Vulnerable Service → Vulnerable Server

The underlying vulnerability remains the same, but the environment changes. In Scenario A, multiple controls might reduce practical exposure. Conversely, Scenario B exposes the vulnerable service directly, making it more at risk. This is why CVSS v4.0 includes Environmental metrics, enabling organizations to account for their specific environment rather than just the generic vulnerability attributes.

Exploitation adds another layer to the equation. For instance, consider:

Vulnerability A: CVSS: 9.8, no known exploitation

Vulnerability B: CVSS: 8.1, known exploitation

Sorting only by CVSS would place Vulnerability A first. However, the active exploitation of Vulnerability B introduces a significant additional risk signal. Here, threat intelligence and exploitation data become crucial. The question shifts from "How severe is this vulnerability?" to "How likely is this vulnerability to be exploited in our environment, and what are the consequences if it is?"

Exploit Prediction Scoring System (EPSS) can aid in this assessment. EPSS estimates the likelihood of a publicly disclosed vulnerability being exploited in the wild within the next 30 days. This probability is expressed as a score between 0 and 1 and is updated daily. While EPSS offers valuable insight into exploitation likelihood, it does not replace CVSS as a comprehensive risk score.

A high exploitation probability does not automatically equate to high organizational risk if the affected asset is low-value or isolated. Conversely, a vulnerability with a lower exploitation probability can still pose significant risks if it impacts a critical, high-value asset.

The Certified Indicator for Shared Threats (CISA) Known Exploited Vulnerabilities (KEV) Catalog provides another useful signal. KEV focuses on vulnerabilities that have evidence of exploitation in the wild. This makes KEV particularly valuable for prioritizing remediation based on active threats.

In summary, a practical approach to vulnerability prioritization might look like this:

CVSS Technical Severity → EPSS Exploitation Likelihood → CISA KEV Status

This framework integrates CVSS for severity, EPSS for exploitation likelihood, and KEV for known exploitation evidence. This comprehensive method ensures a more accurate understanding of the true risk a vulnerability poses to your organization, preventing the oversight of critical contextual factors.