Safeguard
Security Guides•

What can KEV, EPSS and exploit databases not tell you?

Each exploit signal has blind spots: KEV is narrow, EPSS is a population forecast, exploit archives show code not use. A table of limits and fixes.

Safeguard Security Team
4 min read

KEV cannot tell you about exploitation that has not been reliably reported. EPSS cannot tell you about your own environment or confirm an attack. Public exploit archives show that code exists, not that anyone uses it or that it works on your version. Use them together, then add local checks.

The limits at a glance

SignalWhat it isWhat it cannot tell you
CISA KEVCurated list of CVEs with reliable evidence of active exploitation and clear remediationAnything unreported, unconfirmed or without a fix yet; it is a short list, roughly 0.5 percent of CVEs per FIRST
EPSSCalibrated probability of observed exploitation activity in the next 30 daysYour assets, controls or impact; whether exploitation happens to you; it is not a risk score
Public exploit archiveA repository of exploits and proofs of conceptWhether attackers use them, whether they work on your version, or whether the code is safe to run
Vendor noticeThe maker's statementWhat the vendor did not see or chose not to say

KEV's blind spots

KEV needs a CVE ID, reliable evidence and a clear fix. Everything before that point is invisible to it. It also says nothing about how widespread the exploitation is. FIRST notes a listing may record an isolated incident. And the list reflects only what CISA could verify as reliable.

EPSS's blind spots

EPSS learns from data partners with bounded visibility. FIRST says an exploitation attempt that generates no sensor data, no IPS alert and no report is invisible to everyone. Most vulnerability-day records carry no observed exploitation, but that does not mean none happened. FIRST handles this with a positive-unlabeled learning approach, which treats unlabeled records as a mixture rather than confirmed negatives. Even so, it is a forecast. Its FAQ is clear that a low score is not a guarantee, and a population score cannot know your context.

Exploit archives' blind spots

The Exploit Database describes itself as a CVE compliant archive of public exploits and proof of concept code, for penetration testers and researchers, that is a repository of exploits rather than advisories. That is useful, but an entry is code someone published. It does not tell you the quality, reliability or use in attacks. FIRST makes the same distinction when it contrasts a tested module in an exploit framework with a proof of concept pasted on a blog.

A layered routine

  1. Start with KEV. A match on a system you run goes to the emergency path.
  2. Read EPSS probability and percentile to order everything else, and check whether it jumped recently.
  3. Search exploit sources for public code, and read it or a trusted write up before you decide how serious it is.
  4. Read the vendor advisory for exploitation statements and fixed versions.
  5. Add presence, reachability and consequence in your own estate.

Missing a signal is not a pass. If all of the first four are quiet but the component is internet facing and the flaw is remote code execution, you may still choose to move fast. The inverse also holds. A loud signal on a component that is not present closes quickly with evidence.

Document the gap

When you close a finding as no action, note which signals you checked and the date. That record shows you did not rely on one feed, and it lets you re-check when the picture changes.

Safeguard's reachability analysis, asset discovery and SBOM and dependency scanning supply the local half. You can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Follow the check and see which questions only your own code can answer.

Quick check

If a CVE is not on KEV, is it safe?

No. KEV is a narrow, curated list. Absence means CISA has not listed it, not that nobody is exploiting it.

Does a published exploit prove attacks are happening?

No. CISA says a public proof of concept does not automatically indicate that a flaw has been or will be exploited, though it can raise the likelihood.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.