Risk-Based Vulnerability Management: Why CVSS Alone Isn't Enough

CVSS tells you how severe a vulnerability is in the abstract. It doesn't tell you whether attackers are using it, whether the affected system matters to your business, or whether anyone could even reach it. Risk-based vulnerability management fills those gaps. You keep CVSS as one input, then add evidence of active exploitation (CISA's Known Exploited Vulnerabilities catalog), the likelihood of exploitation (FIRST's EPSS), how critical the asset is and how exposed it is. The result is a shorter, better-ordered list of fixes.

Most security teams face the same arithmetic problem. Scanners produce far more findings than anyone can patch, and sorting by CVSS score leaves you with hundreds of "critical" and "high" items and no sensible way to choose between them. This post explains why that happens and how to build a prioritization model that holds up.

What is risk-based vulnerability management?

Risk-based vulnerability management ranks vulnerabilities by the risk they pose to your organization rather than by severity alone. Risk combines three questions: how likely is exploitation, can an attacker reach the vulnerable component, and how much damage would exploitation do to the specific system and data involved?

The point is ordering. You still work through the backlog, but you spend limited hours and maintenance windows on the vulnerabilities most likely to hurt you first. Just as important, you can explain those choices to auditors and leadership.

What does CVSS actually measure?

The Common Vulnerability Scoring System, maintained by FIRST, rates the characteristics of a vulnerability on a 0 to 10 scale. Version 3.1 is the current release. Its base metrics describe how the vulnerability can be exploited (attack vector, attack complexity, privileges required, user interaction) and what exploitation does to confidentiality, integrity and availability.

Scores map to qualitative ratings:

CVSS also defines temporal metrics, such as exploit code maturity, and environmental metrics that let you adjust for your own security requirements. In practice, the number most teams see in scanners and advisories is the base score alone, as published by the vendor or the National Vulnerability Database (NVD).

FIRST is clear about the limits. The CVSS v3.1 User Guide includes a section titled "CVSS Measures Severity, not Risk," which says CVSS "should not be used alone to assess risk."

Why does CVSS alone lead to the wrong priorities?

A base score describes the vulnerability, not your situation. That creates a few predictable problems.

• It's static. The base score is set when the vulnerability is published and rarely changes, whether exploitation starts next week or never happens at all.
• It's generic. The score assumes a reasonable worst case, not your deployment. The same 9.8 applies to an isolated test server and to an internet-facing file transfer gateway.
• It crowds the top. Plenty of published vulnerabilities land in the high and critical bands, so a policy of "fix everything 7.0 and above within 30 days" quickly outgrows most teams' capacity.
• It ignores what attackers actually do. Research behind EPSS and related academic work has consistently found that only a small minority of published vulnerabilities are ever seen exploited in the wild. CVSS doesn't tell you which ones.

Here's how that plays out. Say your scanner reports two findings this week. One is a 9.8 in a library on an internal build server that only three engineers can reach. The other is a 7.5 in the management interface of an internet-facing VPN appliance, and it's listed in CISA's KEV catalog. Sort by CVSS and the build server goes first. Almost any practitioner would patch the VPN appliance first, and they'd be right.

Which signals turn severity into risk?

Four inputs do most of the work. Two describe the threat, and two describe your environment.

1. Evidence of exploitation: CISA's KEV catalog

In November 2021, CISA launched the Known Exploited Vulnerabilities (KEV) catalog alongside Binding Operational Directive 22-01, which requires US federal civilian agencies to remediate listed vulnerabilities by set deadlines. A vulnerability is added only when it has a CVE ID, there is reliable evidence of active exploitation, and there's clear remediation guidance such as a vendor update.

For organizations outside government, KEV is a free, authoritative "attackers are using this" flag. CISA publishes it as CSV and JSON, so it's easy to match against scanner output by CVE ID. A KEV match on an exposed or critical system belongs at the top of your queue.

One caution: KEV is conservative by design. It needs reliable evidence before a vulnerability goes on the list, so absence from KEV doesn't mean a vulnerability is safe to ignore.

2. Likelihood of exploitation: EPSS

The Exploit Prediction Scoring System (EPSS), maintained by a special interest group at FIRST, estimates the probability that a vulnerability will see exploitation activity in the next 30 days. Scores run from 0 to 1 and are recalculated daily for published CVEs, using signals such as the availability of exploit code and observed exploitation attempts. The current model was released in February 2022, and FIRST publishes the scores for free through its EPSS site and API.

EPSS is most useful where KEV is silent, among the many CVEs with no confirmed exploitation. A CVE with a high EPSS score deserves attention before one with a near-zero score, even when their CVSS scores match. Remember that EPSS measures threat, not impact, and it knows nothing about your environment.

3. Asset criticality

Not every system matters equally. A vulnerability on the server that holds customer records, runs payroll or authenticates every user deserves more urgency than the same flaw on a lobby kiosk.

Keep criticality simple. Three or four tiers is plenty:

• Tier 1: systems whose compromise or outage would stop the business or expose regulated data, such as identity providers, core databases, payment systems and backups
• Tier 2: important business applications and the servers that run them
• Tier 3: standard endpoints and internal tools
• Tier 4: test, lab and isolated systems

System owners usually know which tier a system belongs in. The hard part is writing it down somewhere your vulnerability data can use it.

4. Exposure

Exposure asks whether an attacker can actually reach the vulnerable component. An internet-facing service with no authentication in front of it is far more exposed than the same software on a segmented internal network.

Useful questions to ask:

• Is the service reachable from the internet, or from a large internal network?
• Does exploitation require authentication, and would a set of stolen credentials be enough?
• Is the vulnerable component actually installed and running, or just present on disk?
• Are there compensating controls, such as segmentation or a disabled feature?

How do you combine the signals into a priority model?

You don't need a sophisticated formula. A simple decision table that everyone understands usually beats a weighted score nobody can explain. Here's a starting point to adapt to your own capacity:

The timelines are illustrative. Set yours from what your team can actually deliver, then tighten them as the process matures. The two-week window in P2 happens to match BOD 22-01's default deadline for KEV entries with CVE IDs assigned in 2021 or later, which is a reasonable benchmark.

There's no official EPSS cutoff for "high." A practical way to choose one is to look at your open findings, count how many sit above a few candidate thresholds, and pick the level that produces a workload you can clear. Revisit it every quarter.

What do you need in place first?

Risk-based prioritization depends on data about your environment. Before you change any policy, check that you have the basics:

1. An asset inventory that records an owner, a criticality tier and an exposure flag for each system.
2. Scan results that report CVE IDs and are deduplicated across tools.
3. A regular pull of the KEV and EPSS data, joined to your findings by CVE ID.
4. Agreed remediation timelines for each priority level, signed off by leadership.
5. An exception process, with expiry dates, for anything that can't be fixed on time.

None of this needs special tooling to get started. A short script that joins scanner exports with the KEV JSON file and the EPSS data, keyed on CVE ID, will take a small team a long way.

What are the most common mistakes?

A few errors come up again and again when teams move away from pure CVSS sorting.

• Treating EPSS as a risk score. It estimates the likelihood of exploitation activity. It says nothing about impact on your business.
• Reading "not in KEV" as "not exploited." KEV requires evidence, and evidence lags reality.
• Scoring once and never revisiting. EPSS changes daily and KEV keeps growing. Priorities from last month may be wrong today.
• Forgetting what the scores miss. Misconfigurations, exposed cloud storage and default credentials have no CVE, no CVSS score and no EPSS score, yet they're often easier to abuse than anything on your CVE list. End-of-life software needs its own plan too, because new flaws in it won't be fixed.
• Letting P4 mean "never." Low priority still needs an owner and a date, or the backlog grows until it hides real problems.

Frequently asked questions

Should we stop using CVSS?

No. CVSS is still the common language for describing severity, and vendors, regulators and tools all use it. Keep it as one input, and if your tooling supports them, use the environmental metrics to reflect how a system is deployed.

Is EPSS a replacement for CVSS?

No. They measure different things. CVSS describes how bad exploitation could be, while EPSS estimates how likely exploitation activity is in the near term. Used together, they separate "severe and likely" from "severe but unlikely."

How often should we re-prioritize?

For most small and mid-sized organizations, a weekly re-run of the full model is a sensible rhythm. Add a quick check of new KEV entries against internet-facing systems whenever CISA updates the catalog, since those are the findings where days matter.

Does risk-based mean we can ignore low-priority vulnerabilities?

No. It means you fix them later, on a schedule, and document any you decide to accept. Some low-scoring issues can also be chained with others, so an occasional review of long-open items is worth the time.

Key takeaways

• CVSS measures severity. FIRST itself says it shouldn't be used alone to assess risk.
• Add exploitation evidence (KEV) and exploitation likelihood (EPSS) to understand the threat.
• Add asset criticality and exposure to understand what's at stake in your environment.
• Start with a simple decision table and realistic timelines, then refine as your data improves.
• Re-run your prioritization regularly, and keep an eye on the weaknesses that never get a CVE.