Exploit Evidence: How to Read KEV, EPSS and Public PoCs

A CVSS score tells you how bad a vulnerability could be. It says nothing about whether anyone is using it. Exploit evidence is the set of signals that answers the second question: is this flaw in the CISA KEV catalog, what is its EPSS score, is there public exploit code, and is the package itself the attack.

Most teams see these signals as badges on a finding and treat them as interchangeable. They are not. A KEV listing, an EPSS probability and a Metasploit module mean different things, come from different sources and deserve different responses.

This post explains what each exploit signal means, how they combine into an exploit level, and what to do when a finding is rated Confirmed, Probable or Unlikely.

Why CVSS is not exploit evidence

CVSS measures the characteristics of a vulnerability: attack vector, complexity, privileges required, and the impact on confidentiality, integrity and availability. It is a severity score. It was never designed to predict whether a flaw will be exploited, and most high and critical CVEs never are.

The score also depends on who did the scoring. The CVE Numbering Authority that published the CVE may score it. NIST NVD may score it. CISA's Authorized Data Publisher may add its own score and an SSVC decision. GitHub, Red Hat and other vendors publish ratings for their own ecosystems. Two sources can disagree by a full severity tier, and a finding that shows one number without naming the source hides that disagreement.

Severity still matters. It tells you how much damage a successful exploit does. But severity alone treats a critical CVE nobody has touched the same as one ransomware crews are using this week. That is the gap exploit evidence closes.

CISA KEV: confirmed exploitation with a deadline

The CISA Known Exploited Vulnerabilities catalog lists CVEs with reliable evidence of active exploitation in the wild. It is the strongest signal on a finding because it is not a prediction. Someone has seen this vulnerability used against a real target. The catalog is published as a JSON feed you can pull into your own tooling.

Each KEV entry carries more than a yes. Read these fields:

• Date added. A CVE added this week is a live campaign. One added two years ago is a known tool in attacker kits, which is still dangerous but a different kind of urgency.
• Due date. CISA sets a remediation deadline for federal civilian agencies under Binding Operational Directive 22-01. You are probably not bound by it, but it is a reasonable external benchmark for your own SLO.
• Known ransomware campaign use. A flag that says whether the vulnerability has been used in ransomware operations. This is the field to escalate on.
• Required action. Usually "apply updates per vendor instructions," but sometimes a mitigation or a discontinue-use instruction when no patch exists.

VulnCheck maintains a separate KEV catalog that tends to list exploitation earlier and more broadly than CISA, because it does not have CISA's federal remediation mandate attached. Treat a VulnCheck entry as confirmed exploitation as well, and read the exploitation reports behind it.

One caution. Catalog membership and confirmed exploitation are not always the same thing. Provisional or canary entries exist, so rest the rating on the confirmed listing, not on an identifier in a feed.

EPSS: a probability, not a verdict

The FIRST Exploit Prediction Scoring System estimates the probability that a vulnerability will see exploitation activity in the next 30 days. The output is a number between 0 and 1, refreshed daily, plus a percentile that places the CVE against every other scored CVE.

EPSS is a model, trained on observed exploitation activity and on features of the vulnerability such as its CWE, its vendor and whether exploit code is public. It separates the small set of CVEs that attract attackers from the mass that never will. It is not an observation. A score of 0.60 does not mean anyone has exploited the flaw. It means the model thinks the odds are high.

Three reading rules:

• Look at the trend, not only the value. A score that jumped from 0.02 to 0.45 in a week usually means a public exploit or a write-up appeared. That event matters more than the absolute number.
• Use a threshold, and say what it is. Heeler treats an EPSS score at or above 0.40 as a high predicted probability. Whatever your cutoff, make it explicit so two engineers triage the same way.
• Do not let EPSS override KEV. A CVE on KEV with a low EPSS score is still confirmed exploited. The model can lag the catalog.

Engineers who want the raw data can pull it from the FIRST API directly:

curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228"

The response includes the score, the percentile and the date it was computed. The date matters: an EPSS value is only meaningful alongside the day it was produced.

Public exploit code and proof-of-concept decisions

Between "nobody is exploiting this" and "CISA has confirmed exploitation" sits a wide middle ground: the exploit exists, and anyone can run it. A Metasploit module, a GitHub repository with a working proof of concept, or a Nuclei template each lower the cost of attack to near zero. Exploitation may not have been observed yet, but the barrier is gone.

This is the signal that EPSS alone handles worst. A fresh PoC can take days to move the EPSS score, and a CVE with a working Metasploit module can sit at a low probability long enough to be ignored. Treating a public exploit as its own evidence class, independent of the model, is the correct response.

CISA's SSVC decision tree captures the same idea. Its exploitation decision point has three values: none, public proof of concept, and active. When CISA's Authorized Data Publisher attaches an SSVC "public PoC" decision to a CVE record, that is an authoritative statement that exploit code is available, even if the CVE is not on KEV.

For reading purposes: public exploit code is a reason to raise a finding above "unlikely" on its own. It is not, by itself, a reason to treat it as confirmed exploitation.

Supply-chain advisories: when the package is the exploit

A malicious or compromised package is a different category of exploit evidence. There is no vulnerable function to reach and no exploit to run. Installing the package is the compromise. A typosquat, a hijacked maintainer account or a poisoned release carries its payload in the install script or the module itself.

For these, the evidence is the advisory: who reported it, which source published it, which versions are affected and what the payload does. The right response is also different. You do not upgrade. You remove the package, rotate anything the install could have reached, and check whether it ran in CI or on a developer machine. That is incident response, not patch management.

How exploit evidence combines into an exploit level

Each signal above is useful on its own. A prioritization system needs them combined into a single exploit level that a human can read in one glance and that the risk math can use. Heeler's Exploit Threat field has three values:

• Confirmed. The CVE has confirmed exploitation on CISA KEV or VulnCheck KEV, or the package itself is malicious or compromised.
• Probable. The EPSS score is at or above 0.40, or public exploit code exists, or CISA's SSVC decision for the CVE is "public proof of concept." No exploitation has been confirmed, but the odds or the means are there.
• Unlikely. No active-exploitation signal. The vulnerability is real, but nobody appears to be using it and there is no public exploit.

Two design choices in this ladder are worth copying, whatever tool you use.

First, the public-exploit rule is a floor. A CVE with a Metasploit module and an EPSS score of 0.05 is Probable, not Unlikely. The model's lag does not get to hide a working exploit.

Second, the level is resolved through aliases. The same vulnerability is often stored under a CVE id, a GHSA id and an ecosystem-specific id. If the exploit evidence attaches to the CVE but the finding is keyed by the GHSA, a naive system shows one level on the page and grades risk with another. Resolve the aliases first, then rate.

Ransomware association and CWE data are shown for context but do not change the level. They tell you what kind of attacker and what kind of bug, not whether exploitation is happening.

Exploit level is one input, not the answer

An exploit level only tells you what attackers are doing in the world. It does not tell you whether they can do it to you. That takes two more questions: is the vulnerable code reachable and running in an internet-facing deployment, and how much is the service worth.

Heeler's Autotriage combines threat with environment impact and business impact and bands each finding Urgent, Plan or Defer. A Confirmed exploit on a library that is loaded in production but never called by your code lands in Defer, because it is not exploitable. A Confirmed exploit on a reachable, internet-exposed, tier-1 service is Urgent. The prioritization reference has the full table.

Reachability is its own topic. If you want the long version, read reachability analysis explained.

What to do with Confirmed, Probable and Unlikely

A practical playbook per level:

Confirmed

• Check the KEV fields: date added, ransomware use, due date. A ransomware-linked CVE added this week on an exposed service is an incident, not a ticket.
• Fix every reachable, deployed instance first, then sweep the rest. Do not wait for the SLO.
• If the package is malicious rather than vulnerable, remove it, rotate credentials the install could reach, and audit CI runs that pulled it.

Probable

• Read why it is Probable. A public Metasploit module on an internet-facing service deserves faster treatment than an EPSS score that crept over the threshold.
• Schedule the fix inside the SLO window and let a Guardrail stop new instances from entering through pull requests.
• Watch the EPSS trend. A Probable finding whose score keeps climbing is on its way to KEV.

Unlikely

• Keep it on a clock. Unlikely is a statement about today. Exploit evidence changes, and a finding should re-rate the day it does, with no rescan.
• Fix it in bulk when a dependency upgrade clears several findings at once, rather than one ticket at a time.
• If your context makes it unreachable or mitigated, record a risk override with a reason and an expiry so the decision is reviewable.

How Heeler shows exploit evidence on a finding

The finding page, the vulnerability overview and the container finding drawer each carry an Exploit Evidence card. It shows the CISA KEV listing with its remediation due date and known ransomware use, public exploit code, VulnCheck exploitation reports, the EPSS score with the dates it last changed, and, for a malicious package, the supply-chain advisory with its source, reporter and references. The exploit level is not a badge you take on faith. The evidence is next to it.

Severity is shown with its provenance: the CVSS score from each source, the source that decided the severity, aliases, and vendor ratings. The Source row names the CNA or the CISA ADP when they scored the CVE. Heeler takes the CNA's score when it has one, then NVD, then CISA ADP, GitHub, Red Hat and Bitnami, in that order. A withdrawn advisory is marked withdrawn.

The same Exploit Threat rule decides the level on the finding page, in risk and SLO grading, on container findings and in SBOM assessment, and it reads the vulnerability through its aliases. One rating, everywhere it is shown. The findings reference lists the Exploit Threat filter and column, and the exploitability use case walks a new CVE from blast radius to the handful of instances that are reachable, running and exposed.

From there, the Context Engine supplies the reachability and exposure that turn an exploit level into a Heeler Risk band, Auto-fix opens the upgrade pull request for the findings that have one, and SCA keeps the finding open until the fix is deployed, not just merged.

FAQ

What is exploit evidence on a vulnerability?

Exploit evidence is the set of observed or predicted signals that a vulnerability is being, or can be, exploited: a CISA or VulnCheck KEV listing, an EPSS probability, public exploit code, an SSVC proof-of-concept decision, and for packages, a malicious-package advisory. It is distinct from CVSS severity, which measures potential impact rather than attacker activity.

What is the difference between KEV and EPSS?

KEV is a catalog of vulnerabilities with confirmed exploitation in the wild, while EPSS is a daily model-generated probability that a vulnerability will be exploited in the next 30 days. KEV is an observation and EPSS is a prediction. A CVE can be on KEV with a low EPSS score, and the KEV listing wins.

Does a public proof of concept mean a vulnerability is being exploited?

No. A public proof of concept means the exploit exists and anyone can run it, which removes the cost barrier, but it is not evidence that exploitation has been observed. Heeler rates a vulnerability with public exploit code or a CISA SSVC public-PoC decision as Probable, not Confirmed.

Should a Confirmed exploit always be fixed first?

Only when it is exploitable in your environment. A Confirmed exploit on a library that is not reachable, not deployed or not internet-facing is not an active risk, and Heeler bands it Defer while keeping it on an SLO. The order of work comes from exploit evidence combined with reachability, exposure and business impact, not from exploit evidence alone.

Why do CVSS scores differ between sources?

Because the CNA, NIST NVD, CISA's ADP and ecosystem vendors each score independently and can weigh attack complexity or impact differently. Heeler shows the score from each source and names the one that decided the severity, so the disagreement is visible.

If your findings list shows an exploit badge with nothing behind it, you are asking engineers to trust a label. Heeler puts the KEV entry, the EPSS history, the exploit code and the advisory on the finding, grades the level the same way everywhere, and combines it with what is reachable and exposed in your environment. See it on your own repositories. Get a demo