CVSS, EPSS and CISA KEV: how each informs prioritization

What each signal measures, and what it does not

CVSS: severity, not risk

FIRST’s CVSS v4.0 user guide says Base scores “are designed to measure the severity of a vulnerability” and “should not be used alone to assess risk.”^[1] The v4.0 specification (first published November 2023) defines four metric groups: Base, Threat, Environmental and Supplemental^[2]. Base describes characteristics that are constant over time and across environments. Threat adds characteristics that change over time, and Environmental adds those specific to a consumer’s own environment. A Base-only score is labelled CVSS-B; adding Threat and Environmental gives CVSS-BTE. FIRST says the BTE score “can be considered much closer to ‘Risk’”^[1].

EPSS: a forecast

FIRST describes EPSS as a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days^[3]. It is a prediction built from empirical signals, not a record of what has happened. FIRST’s FAQ is direct about limits: “EPSS is not a complete risk score,” and multiplying EPSS by a CVSS score “is never a good idea.”^[4] It also says that if direct evidence of active exploitation exists, that evidence should supersede EPSS^[4].

CISA KEV: evidence of exploitation

CISA maintains the catalog as “the authoritative source of vulnerabilities that have been exploited in the wild,” and says organizations “should use the KEV catalog as an input to their vulnerability management prioritization framework.”^[5] Under BOD 22-01, the inclusion criteria were a CVE ID, clear remediation guidance and reliable evidence of exploitation in the wild^[6]. That directive has since been superseded by BOD 26-04, which keeps KEV status as one of four questions (public exposure, KEV listing, whether an adversary can automate exploitation, and what control the adversary gains)^[7]. Note that these directives bind US federal agencies. For everyone else, KEV is guidance.

KEV is a floor, not a complete list. CISA invites organizations to report exploited vulnerabilities that are not in the catalog^[6], so a CVE that is absent has not been proven unexploited, only not listed.

Three claims that get confused

• “A public exploit exists.” Proof-of-concept code is available. CVSS v4.0’s Exploit Maturity metric separates this (“Proof-of-concept exploit code is publicly available”) from “Attacked” (“Attacks targeting this vulnerability (attempted or successful) have been reported”)^[2].
• “Confirmed exploited in the wild.” This is what KEV listing signals, on the basis of reliable evidence.
• “Likely to be exploited.” This is what a high EPSS probability says. It is a forecast and can be wrong in either direction.

These are three different levels of evidence. A public proof of concept does not mean attackers use it. A high EPSS does not mean exploitation has happened. KEV is the strongest of the three, but it says nothing about whether your customer is exposed.

Combining the signals with asset context

The signals describe the vulnerability. Order of work also depends on the asset, which none of them can see. CISA says as much: stakeholders are responsible for evaluating each asset’s internet exposure^[5]. A workable sequence for a technician:

1. Start with evidence of exploitation. Anything in KEV that is present on your estate goes to the top of the review queue.
2. Ask whether it is reachable. An exposed service on an internet-facing host outranks the same flaw on an isolated internal system. BOD 26-04 uses public exposure as a decision variable for the same reason^[7].
3. Ask what the asset is. A domain controller, a backup server or a customer’s line-of-business system carries more consequence than a lab machine.
4. Use EPSS to order what is left. Among vulnerabilities not in KEV, a higher EPSS probability is a reasonable tie-breaker, treated as a forecast.
5. Use CVSS for impact, and enrich it. Read the Base score as severity and add Threat and Environmental context where you can^[1].
6. Write down the decision. Record the signals, the asset context and the reason, including anything you decided to defer.

None of the signals above is a substitute for confirming the fix afterwards. See why a successful patch job is not verification.

How Exploit Hound handles this

Product behaviour, not an industry claim

• The Threat Radar page shows CISA KEV and EPSS data taken from public sources, alongside CVSS and public exploit availability.
• Fix First ranks remediation actions by the exposure each one removes, so the order reflects what is present on the customer’s estate and not only the severity of a CVE.
• Findings use the terms detected, high confidence and safely validated, defined in the terminology section.
• After the work, the exposure is re-checked, and what could not be checked is reported as unverified, never as fixed. See vulnerability prioritization and remediation verification.