CVSS vs EPSS vs SSVC vs KEV — How to Actually Prioritize Vulnerabilities

Every vulnerability management program needs a prioritization framework. The question is which one - and increasingly, the answer is "more than one."

Four frameworks dominate the conversation: CVSS, EPSS, SSVC, and KEV. Each answers a different question. Each has strengths and blind spots. And none of them, individually, gives you what you actually need: a prioritization that reflects the real risk in your specific environment.

This guide breaks down what each framework does, where it falls short, and how to think about combining them - including the dimension none of them cover.

CVSS - Common Vulnerability Scoring System

What it measures: Intrinsic severity - how bad a vulnerability could be under worst-case conditions.

Current version: CVSS v3.1 (v4.0 released 2023, adoption still growing)

How it works: A vector of metrics - attack vector, attack complexity, privileges required, user interaction, scope, and impact (confidentiality, integrity, availability) - produces a score from 0.0 to 10.0.

Scoring bands:

Strengths:

• Universal language - every scanner, every database, every report uses CVSS
• Standardized and well-understood
• Stable - a CVSS score doesn't change over time (for a given version)
• CVSS v4.0 adds supplemental metrics (Automatable, Recovery, Safety) for richer context

Weaknesses:

• Context-free. CVSS doesn't know your environment. A 9.8 on an internet-facing server and a 9.8 on an isolated dev box get the same score.
• Severity inflation. In 2025, 8.3% of all CVEs scored Critical and 31.1% scored High [1]. When nearly 40% of CVEs are High or Critical, the bands stop differentiating.
• No exploitation intelligence. CVSS doesn't consider whether a vulnerability is being actively exploited, whether exploit code exists, or how likely exploitation is.
• Inconsistent scoring across CNAs. Different CVE Numbering Authorities interpret CVSS metrics differently, leading to scoring inconsistencies across the ecosystem.
• Static. A CVSS score is assigned once and doesn't change as the threat landscape evolves.

The efficiency problem: FIRST's analysis shows that remediating all CVSS 7.0+ vulnerabilities requires addressing 57.4% of all vulnerabilities but catches only 82.2% of those that are actually exploited [2]. That's a lot of effort for incomplete coverage.

Best used for: Establishing a baseline severity. Useful as one input, not as the sole prioritization mechanism.

EPSS - Exploit Prediction Scoring System

What it measures: Probability that a vulnerability will be exploited in the wild within the next 30 days.

Current version: EPSS v4 (released March 2025)

How it works: A machine learning model trained on historical exploitation data, CVE characteristics, and exploit intelligence signals. Produces a probability (0.0 to 1.0) for each CVE, updated daily.

Performance: ROC AUC of 0.838 [2]. Significantly better than random and demonstrably better than CVSS at predicting actual exploitation.

Strengths:

• Exploitation-aware. Unlike CVSS, EPSS incorporates whether exploit code exists, active exploitation signals, and threat intelligence.
• Dynamic. Updated daily - reflects the evolving threat landscape.
• Efficient. Remediating vulnerabilities with EPSS ≥ 0.1 requires addressing only 2.7% of all vulnerabilities but catches 63.2% of those actually exploited [2]. Over 20x more efficient than CVSS 7+ by effort-to-coverage ratio.
• Open. Free, community-maintained by FIRST.org. API available.

Weaknesses:

• Environment-blind. Like CVSS, EPSS doesn't know your infrastructure. It tells you a CVE has a 40% chance of being exploited somewhere - not whether it's exploitable or exposed in your environment.
• Probability, not certainty. A low EPSS doesn't mean safe - it means exploitation hasn't been predicted yet. Novel exploitation paths, targeted attacks, and newly published PoCs can change the picture overnight.
• Aggregate model. EPSS predicts exploitation in the wild broadly. It doesn't distinguish between "exploited against Fortune 500 companies" and "exploited against exposed IoT devices."
• Dependent on observable signals. EPSS is only as good as the exploitation data it's trained on. Vulnerabilities exploited by state actors or in targeted campaigns may not generate the public signals EPSS relies on.

Best used for: Adding exploitation likelihood to your prioritization. Dramatically more efficient than CVSS alone. Best combined with environmental context.

SSVC - Stakeholder-Specific Vulnerability Categorization

What it measures: What action to take, based on a decision tree that considers exploitation status, technical impact, and stakeholder-specific context.

Developed by: Carnegie Mellon's Software Engineering Institute (SEI), adopted by CISA.

How it works: Instead of a numeric score, SSVC produces an action recommendation: Act, Attend, Track, or Track* - based on decision points:

CISA publishes its own SSVC decision tree for federal agencies [3].

Strengths:

• Decision-oriented. SSVC outputs an action (Act/Attend/Track), not a number. This is closer to what practitioners actually need.
• Stakeholder-aware. Different organizations can apply different decision trees based on their context - a hospital and a tech startup have different mission prevalence criteria.
• Exploitation-informed. Factors in whether exploitation is active, PoC exists, or no exploitation is known.
• Automatable consideration. Whether the exploit can be automated at scale changes the urgency.

Weaknesses:

• Coarse-grained. Four categories (Act/Attend/Track/Track*) provide less granularity than CVSS or EPSS. If 500 CVEs all map to "Act," you still need to order them.
• Manual input required. Some decision points (Mission Prevalence, Public Well-Being) require human judgment per vulnerability per organization. This doesn't scale against the volume your scanners actually report.
• No environmental topology. SSVC considers whether your mission depends on the affected system, but doesn't model attack paths, network reachability, or blast radius.
• Adoption still nascent. Fewer tools natively support SSVC than CVSS or EPSS. Implementing SSVC requires workflow changes.

Best used for: Establishing organizational decision policies. Excellent as a framework for defining "what do we do about Act vs. Attend," less useful as a real-time scoring mechanism at scale.

KEV - CISA Known Exploited Vulnerabilities Catalog

What it measures: Confirmed active exploitation - a vulnerability is in KEV only if CISA has evidence of active exploitation in the wild.

Maintained by: Cybersecurity and Infrastructure Security Agency (CISA)

How it works: CISA adds CVEs to the KEV catalog when they have reliable evidence of active exploitation. Federal agencies are mandated to remediate KEV entries within specified timelines (typically 14-21 days). Non-federal organizations increasingly use KEV as a prioritization input.

2025 data: 884 KEVs added during 2025 [4]. 28.96% were exploited on or before disclosure day [4].

Strengths:

• Ground truth. If a CVE is in KEV, it's being exploited. No prediction, no probability - confirmed evidence.
• High signal-to-noise. In 2025, 884 KEVs out of 48,185 total CVEs - less than 2% of all CVEs. When KEV says "act," it means it.
• Mandated for federal. BOD 22-01 requires federal agencies to remediate KEV entries, giving it institutional weight.
• Free, public, machine-readable. Available via API, updated frequently.

Weaknesses:

• Lagging indicator. KEV entries are added after exploitation is confirmed - which means the vulnerability has already been weaponized by the time it appears. Nearly 29% are exploited on disclosure day [4]; KEV often confirms what's already happened.
• Incomplete. Not all exploited vulnerabilities make it into KEV. Targeted attacks, state-sponsored exploitation, and campaigns below CISA's visibility may not appear. KEV is a floor, not a ceiling.
• No prioritization within the catalog. All KEV entries are treated as "must remediate." There's no differentiation between a KEV entry being mass-exploited versus a KEV entry from a targeted campaign against a specific sector.
• No environmental context. Like CVSS and EPSS, KEV doesn't know your infrastructure. A KEV entry for a Windows RDP vulnerability doesn't tell you whether your RDP services are exposed.

Best used for: Absolute minimum baseline. If it's in KEV and you're affected, remediate. But KEV alone misses too much to be a complete strategy.

The comparison matrix

What none of them cover: internal signals

CVSS, EPSS, SSVC, and KEV are all external signals. They tell you what's true about a vulnerability in the world: how severe it is, how likely exploitation is, whether it's being actively exploited, what action category it falls into. Every vulnerability management program needs them.

But external signals don't know your environment. They can't tell you whether a CVE is actually exploitable on your hosts, how an attacker would reach it, or what's at stake if they did. Those answers come from internal signals: your network topology, your configurations, your exposure surface, your business context.

A CVE can score CVSS 9.8, EPSS 0.9, SSVC "Act," and appear in KEV, and still not be exploitable on your host because:

• The vulnerable feature isn't compiled in
• The required configuration isn't set
• The necessary precondition doesn't hold
• The attack vector is blocked by your network topology

That's the gap. External signals tell you what could happen somewhere. Internal signals tell you what applies here.

Condition-level verification is the first internal signal: for each vulnerability on each resource, it checks whether the specific exploitation conditions are met, with full audit trail from OSINT source to test plan to verdict. The output isn't a score or a probability. It's a binary answer grounded in your environment: exploitable or not.

Internet exposure, critical resource exposure, and business impact are the other internal signals: how reachable is the vulnerability, what's downstream if it's exploited, and how much does the organization care about what's at risk.

When you combine both:

External signals are publicly available for every CVE. Internal signals require knowledge of your environment. The programs that combine both have a prioritization that reflects actual risk, not theoretical severity or aggregate probability.

Practical recommendations

If you're using CVSS alone: Add EPSS immediately. It's free, API-available, and dramatically more efficient. A CVSS 9.8 with EPSS 0.01 is a different priority than a CVSS 7.0 with EPSS 0.8.

If you're using CVSS + EPSS: Add KEV as a hard filter. Any KEV entry in your environment gets immediate attention. Then start asking the internal signal questions: which of your high-EPSS, high-CVSS findings are actually reachable, and what's downstream?

If you're using CVSS + EPSS + KEV: The next leverage point is exploitability verification. Confirming which findings have exploitation conditions met in your environment eliminates the largest category of wasted effort: high-severity, high-probability findings that aren't actually exploitable on your hosts.

If you want the full picture: Combine all external signals with all internal signals. Verify exploitability, map exposure and blast radius, weight by business impact. Score at the component level. Surface remediation options. That's where vulnerability management becomes risk management.

References

[1] Gamblin, J. (2026, January 1). "2025 CVE Data Review." https://jerrygamblin.com/2026/01/01/2025-cve-data-review/

[2] FIRST. "Exploit Prediction Scoring System (EPSS)." https://www.first.org/epss/

[3] CISA. "Stakeholder-Specific Vulnerability Categorization (SSVC)." https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc

[4] VulnCheck. (2026). "State of Exploitation 2026." https://www.vulncheck.com/blog/state-of-exploitation-2026