Beyond CVSS: A more practical approach to vulnerability prioritization

Stop reacting to every CVE—prioritize vulnerabilities based on context, exploitability, and actual risk.

Patrick Mathieu, a Product Security Manager at DoorDash, recently launched a compelling blog series on SecurityAutopsy.com, zeroing in on a long-standing issue in vulnerability management: CVSS scores alone are not enough.

His central thesis is both clear and urgent: CVSS scores are just noise unless they’re enriched with exploitability, reachability, and contextual risk. These attributes are often missing from traditional scoring systems. It’s a call to arms for the security community to adopt more dynamic and context-aware models.

This topic is foundational to how modern security teams will triage the growing flood of vulnerabilities, especially in software supply chains.

The problem with CVSS alone

The Common Vulnerability Scoring System (CVSS) has been the industry standard for years. It offers a consistent way to rate the severity of vulnerabilities, with scores from 0 (informational) to 10 (critical). But CVSS doesn’t answer the most critical question:

“Does this matter in my environment?“

A high CVSS score might signal danger, but without additional context, it’s difficult to know whether a vulnerability:

• Is it reachable from the internet?
• Does it impact a critical system?
• Is it actually exploitable in the wild?

That’s where models like EPSS and VEX come into play.

Context is king (EPSS, VEX, SSVC, and reachability analysis)

EPSS (Exploit Prediction Scoring System)

EPSS estimates the likelihood that a vulnerability will be exploited in the wild, based on real-world data. It produces a probability score from 0 to 1. Unlike CVSS, which focuses on theoretical severity, EPSS is grounded in threat intelligence.

Example: A CVE might have a CVSS score of 9.8, but an EPSS score of 0.001 – suggesting it’s very unlikely to be exploited.

VEX (Vulnerability Exploitability eXchange)

VEX provides machine-readable context from software vendors about whether a vulnerability is exploitable in a particular product. It allows consumers to avoid wasting time on issues that, while present, pose no real threat in their specific deployment.

Together, EPSS and VEX help teams distinguish between theoretical risk and actionable threats.

SSVC (Stakeholder-Specific Vulnerability Categorization)

SSVC is a decision-making framework that helps organizations prioritize vulnerability response based on real-world impact. Instead of treating all high-severity vulnerabilities the same, SSVC considers factors like exploitation status, mission criticality, safety implications, and how widespread the affected product is. Originally developed by Carnegie Mellon’s SEI and CISA, it offers tailored decision trees for different sectors, including government and critical infrastructure.

Example: Two vulnerabilities may have the same CVSS score, but SSVC helps decide which one to fix first based on how vital the system is and whether active exploitation is observed.

Reachability analysis:

Reachability analysis determines whether a vulnerability can actually be exploited in a given environment. By analyzing an application’s code paths (like call graphs), it identifies whether vulnerable code is even accessible to an attacker. This cuts through noise by focusing on vulnerabilities that are both severe and reachable.

Example: A critical vulnerability may exist in a library, but if it’s never called or exposed, reachability analysis may flag it as non-exploitable in your specific deployment – helping reduce the remediation burden by up to 80%.

Enforcing policy with real-world awareness

Ideally, you’d be able to factor in a wide range of inputs when deciding where to focus vulnerability remediation efforts.  And you’d want to automate this decision criteria, so it works at scale (think thousands of developers, thousands of dependencies, thousands of vulnerabilities). A solution for this is policy-as-code, or the idea that you can write vulnerability-related policies of arbitrary complexity using a fully expressive language, as opposed to a simplistic “quarantine? yes/no” type of policy. 

Open Policy Agent (OPA) reflects this philosophy, and the Rego programming language lets cybersecurity professionals write these kinds of policies that work at the artifact management layer. You can write rules that combine CVSS and EPSS, with custom logic to assess package vulnerabilities with much more nuance.

Here’s a real-world example of an OPA Rego policy in action:

package cloudsmith
import rego.v1

default match := false

max_epss := 0.0001
target_repository := "acme-corporation"
ignored_cves := {"CVE-2023-45853"}

match if {
    input.v0["repository"]["name"] == target_repository
    some vulnerability in input.v0["vulnerabilities"]
    vulnerability["patched_versions"]
    vulnerability["severity"] == "HIGH"
    not ignored_cve(vulnerability)
    exceeded_max_epss(vulnerability)
}

exceeded_max_epss(vulnerability) if {
    some _, val in vulnerability
    val["score"] > max_epss
}

ignored_cve(vulnerability) if {
    vulnerability["VulnerabilityID"] in ignored_cves
}

This policy flags high-severity vulnerabilities with EPSS scores above a defined threshold, unless explicitly ignored. In practice, this enables us to filter out irrelevant noise and focus on truly actionable risk.

Why it matters now

On April 15, 2025, MITRE, the non-profit steward of the CVE (Common Vulnerability & Exposure) system since 1999, announced that its funding from the U.S. Department of Homeland Security was at risk of lapsing. This could have temporarily shut down the issuance of new CVE IDs, which was a stark reminder of our over-reliance on centralised, underfunded systems like CVE and CVSS.

Although disaster was averted, the incident highlighted an urgent need: We must diversify our risk signals and enrich our vulnerability intelligence with dynamic, community-driven data sources.

Toward a smarter vulnerability lifecycle

Modern vulnerability management isn’t just about knowing what’s broken. It’s about knowing whether what’s broken actually matters.

The new gold standard is this:

• Is this a critical vulnerability?
• Is the asset part of a critical system?
• Is the affected asset internet-facing or exposed?
• Is the vulnerability actually reachable or exploitable?

If the answer is yes, you fix it.

If the answer is no, you move on.

This triage model reflects the realities of limited time, team resources, and the explosion of third-party software risk. Vendors such as Sysdig (demonstrated in the below screenshot) advise users to focus primarily on CVEs associated with in-use packages that have a known fix available. If there’s no fix available, we cannot take proactive steps to patch the known vulnerable packages.

Likewise, if the software package is not in-use or does not have access to the public internet, oftentimes the exploitability is near zero. In this workflow, an organization that has roughly 117,000 CVEs in their software supply chain equates to only 144 in-use vulnerable workloads that need urgent attention from developers.

Final thoughts

CVSS is a good starting point, but it’s not really sufficient on its own. Security teams need a blend of vendor-provided severity, real-world threat intelligence (like EPSS), contextual exploitability (via VEX), stakeholder-driven prioritization (through SSVC), and environment-specific analysis (like Reachability Analysis), all reinforced by automated policy enforcement tools (such as OPA) to make informed, risk-based decisions. CVSS is just noise until enriched with context.

More from We Love Open Source

• 15 overlooked rules of AI
• Introduction to Falco and how to set up rules
• Detecting vulnerabilities in public Helm charts
• Why Kubernetes is essential for AI and open source projects in 2025
• How curiosity, Kubernetes, and community shaped my open source journey