cve-triage.tools

CVSS, EPSS, and KEV: the three signals for CVE triage

Every CVE that lands in a ticket queue arrives with a severity score attached, and for most teams that score is the only thing anyone looks at. That is a mistake. CVSS, EPSS, and CISA KEV measure three different things, and none of them alone tells you when to patch. Triage means reading all three together, not substituting one for the other.

What CVSS actually measures

The Common Vulnerability Scoring System rates how bad a vulnerability would be if someone exploited it successfully. It rolls attack vector, attack complexity, privileges required, user interaction, and the impact to confidentiality, integrity, and availability into a 0 to 10 number, with Low, Medium, High, and Critical bands on top. NVD publishes the score once a CVE is analyzed, and it stays fixed after that except for occasional rescoring. CVSS answers one question: how severe is this, assuming it is exploited. It does not ask whether anyone is exploiting it, how common the vulnerable configuration actually is in the wild, or how exposed your specific deployment is.

Why CVSS alone fails as a triage signal

CVSS collapses two separate questions, severity and likelihood, into a single number, and a triage process built only on that number inherits the confusion. A finding can score 9.8 and never see real exploitation because the preconditions are rare: a specific plugin combination, local access, a race window nobody has bothered to win outside a lab. A different finding can score 6.5 and get hit by every opportunistic scanner on the internet within 48 hours of disclosure because a public one-line payload exists and the affected software is everywhere.

Most security teams do not have the headcount to patch every Critical the week it is published, let alone every High. If the backlog is ranked strictly by CVSS, the queue fills with theoretical Criticals that may never be touched by an attacker, while a Medium that is actively being used in the wild sits unpatched below them. CVSS was built to describe severity, not to be a work queue sort key, and using it as one systematically misallocates a team's limited patching capacity.

What EPSS adds

EPSS, the Exploit Prediction Scoring System from FIRST, estimates the probability that a given CVE will be exploited in the wild in the next 30 days. It is a score from 0 to 100 percent, produced by a model trained on observed exploitation signals, scanner activity, code repositories, and other indicators, and it is recalculated daily as new data comes in. Every CVE also gets a percentile, which matters because the raw score distribution is heavily skewed: the overwhelming majority of CVEs sit near zero, so a score that looks small in isolation can still rank in a high percentile relative to everything else published.

EPSS is the piece CVSS is missing: a forward-looking estimate of real-world attacker interest. A common convention, not an official FIRST threshold, treats scores above roughly 10 percent as elevated and above roughly 50 percent as high priority on their own. It is entirely normal, and expected, for a CVE to carry a Critical CVSS score and a near-zero EPSS score at the same time. That combination means the flaw is severe if someone bothers to exploit it, but almost nobody currently is.

What CISA KEV adds

The Known Exploited Vulnerabilities catalog is CISA's list of CVEs that have been confirmed as exploited in the wild, based on actual evidence rather than prediction. It is binary: a CVE is either on the list or it is not. Federal civilian agencies are required under Binding Operational Directive 22-01 to remediate KEV entries by a published due date, and the catalog grows only when CISA has evidence of real exploitation to add a new entry.

Where EPSS predicts, KEV confirms. A KEV listing means attackers are already using the vulnerability today, not that a model thinks they might next month. That makes any KEV entry top priority on its own merits, regardless of what its CVSS or EPSS numbers happen to say. Log4Shell, CVE-2021-44228, is the reference example: CVSS 10.0, and in KEV from the week exploitation was confirmed.

Combining the three signals into a decision

Check KEV first, because it is the only one of the three built on direct evidence rather than modeling. Then check EPSS, because it tells you whether a non-KEV CVE is trending toward real-world attacker interest. Only after both of those checks does CVSS earn a role, and its role at that point is sizing, not prioritization: how severe would a successful hit actually be, which sets the remediation SLA and whether a rollback plan is needed before you touch production.

KEVEPSSCVSSWhat it means
ListedAnyAnyConfirmed active exploitation. Patch now regardless of the other two numbers.
Not listedHigh (>50%)High/CriticalSevere and trending toward exploitation. Prioritize this sprint.
Not listedElevated (>10%)Medium/HighWorth attention; schedule ahead of routine patching.
Not listedLowCriticalSevere in theory, no current attacker interest. Patch on normal cadence; do not let the CVSS number alone jump the queue.

Common pitfalls

Pulling CVSS, EPSS, and KEV status for a specific CVE by hand means three separate lookups across NVD, FIRST, and CISA. The lookup tool at / pulls all three for a given CVE ID in a single query, which is the fastest way to get the inputs this framework needs before you make a call.

None of these three signals replaces judgment. They replace guessing. A team that checks KEV, then EPSS, then CVSS, in that order, every time, will patch the things attackers are actually using before it burns a sprint on a theoretical score that happens to sit at the top of a dashboard.