Beyond CVSS: Prioritizing Vulnerabilities With the CISA KEV Catalog

Every security team that has run a dependency scan knows the feeling: the report comes back with hundreds of CVEs, dozens of them flagged “Critical,” and a development backlog that has no room to fix them all. The instinct is to sort by CVSS score and start at the top. But that instinct quietly conflates two different questions. CVSS tells you how bad a vulnerability could be in theory. It tells you nothing about whether anyone is actually exploiting it right now. Closing that gap is the difference between burning sprint capacity on phantom risk and fixing the flaws attackers are already using against organizations like yours.

The Problem: A CVE Is Not a Risk

A CVE identifier confirms that a vulnerability exists. A CVSS score rates its technical severity on a scale up to 10. Neither answers the question that actually matters for prioritization: is this being weaponized?

The disconnect runs in both directions. A vulnerability rated CVSS 9.8 may have a fearsome theoretical impact and yet never appear in a single real-world attack — perhaps the preconditions are exotic, or no reliable exploit was ever published. Meanwhile, a flaw scored a modest 5.3 can be actively chained into live intrusion campaigns. If you triage purely by CVSS, you will patch the 9.8 first and leave the 5.3 — the one attackers are actually using — sitting in the backlog.

Severity and exploitation are simply different axes. Treating the severity score as a proxy for risk is the root cause of alert fatigue in most vulnerability programs.

What the CISA KEV Catalog Adds

The Known Exploited Vulnerabilities (KEV) catalog, maintained by the U.S. Cybersecurity and Infrastructure Security Agency, is a public list of vulnerabilities with confirmed exploitation in real attacks. Inclusion is not based on theoretical reachability — it is based on evidence.

That evidence is drawn from several streams:

• Government and partner threat intelligence
• Incident response investigations
• Reporting from security vendors
• OSINT and malware campaign analysis

A KEV entry typically carries the CVE identifier, the affected vendor and product, a short description of the required action, and a due date by which federal agencies must remediate. The signal it provides is binary and unambiguous: this vulnerability is being used in the wild.

KEV, CVSS, and EPSS Are Complementary

These data sources are often presented as competitors. They are not — each answers a distinct question, and a mature program uses all of them together.

Data source	What it tells you
CVE	A vulnerability exists
CVSS	Its technical severity
EPSS	The statistical probability it will be exploited
KEV	The confirmed fact that it has been exploited

EPSS (the Exploit Prediction Scoring System) is the predictive middle ground: a probability that a given flaw will see exploitation in the near term. KEV is the ground truth. A practical prioritization order falls out naturally:

1. In KEV → Priority 1. Confirmed exploitation. Remediate immediately, regardless of CVSS.
2. High EPSS → Priority 2. High likelihood of imminent exploitation.
3. High CVSS only → Priority 3. Severe in theory, but no evidence of use.

Consider three realistic cases. An RCE with CVSS 9.8 and a moderate EPSS score that also appears in KEV jumps to the front of the queue — confirmed use overrides the lukewarm probability. A different flaw at CVSS 9.0 with low EPSS and no KEV entry can reasonably be deferred. And a humble CVSS 6.5 vulnerability that is listed in KEV should outrank an unexploited “critical,” because someone is demonstrably attacking it.

Putting KEV to Work in Software Composition Analysis

The natural place to operationalize this is in Software Composition Analysis (SCA), where the noise problem is most acute. A typical workflow:

• The scanner inventories project dependencies and produces a Software Bill of Materials (SBOM) with an associated list of CVEs.
• Each component’s vulnerabilities are enriched with metadata — including pre-imported KEV status — from a vulnerability data feed.
• Quality gates then evaluate the findings against policy. A KEV-aware gate can fail a build the moment a dependency introduces a known-exploited vulnerability.

The same gating logic extends upstream into open-source governance. Integrated with a repository manager, a policy engine can intercept a developer’s request to pull a new open-source component, check its CVEs against KEV, and block the download before a known-exploited package ever enters the codebase.

The payoff is concrete: triage shrinks from hundreds of undifferentiated CVEs to the dozens that represent confirmed, attacker-relevant risk. Teams stop drowning and start fixing the things that matter.

Know the Limits

KEV is a powerful filter, not an oracle. Three caveats deserve attention:

• Coverage is incomplete. A vulnerability appears only once CISA has gathered exploitation evidence. Absence from KEV is not proof of safety.
• There is a time lag. Active exploitation usually begins before the catalog entry is published, so KEV trails the threat by some interval.
• It lacks your context. KEV says a flaw is exploited somewhere — not whether it is reachable in your specific architecture, or whether compensating controls already neutralize it.

This is precisely why KEV does not replace CVSS or EPSS. It is the highest-confidence layer in a stack that still needs theoretical severity, statistical likelihood, and your own environmental analysis to be complete.

Key Takeaways

• CVSS measures theoretical severity, not real-world exploitation — sorting by score alone misdirects remediation effort.
• The CISA KEV catalog provides confirmed-exploitation ground truth, the single strongest signal for prioritization.
• Layer the signals: KEV first, then EPSS probability, then high CVSS. They answer different questions and belong together.
• Operationalize KEV in SCA and open-source governance via quality gates that fail builds or block downloads on known-exploited components.
• Respect KEV’s limits: incomplete coverage, publication lag, and no awareness of your environment mean it sharpens prioritization rather than replacing contextual analysis.