Yes. A known exploited vulnerability is a good candidate for a hard block, whatever its CVSS score. Exploitation in the wild is evidence that attackers use the flaw. Add it as a rule that sits above your severity threshold, with an exemption path for cases where the code is not exposed.
What "known exploited" means here
CISA maintains the Known Exploited Vulnerabilities catalog, which it describes as an authoritative source of vulnerabilities that have been exploited in the wild. Each entry lists the date added and a due date. The page advises organizations to use the catalog as an input to their vulnerability management prioritization framework.
That wording matters. The catalog is an input, not a legal duty for most private teams, and it says nothing about whether the flaw is reachable in your build.
How to add a KEV rule to a gate
- Pull the catalog on a schedule and store the CVE identifiers.
- When a scan runs, match findings by CVE identifier against that list.
- If a match is found in a package that ships, fail the build.
- Print the CVE, the package, the fixed version and a link to the catalog entry in the failure message.
- Offer an expiring exemption if the team can show the code path is not exposed.
How it compares with other signals
| Signal | What it tells you | Good as |
|---|---|---|
| CVSS band | Intrinsic severity | First filter |
| EPSS | Estimated chance of exploitation in the next 30 days | Ranking inside a band |
| KEV listing | Exploitation already observed | Hard block rule |
| Reachability | Whether your code calls the flaw | Reducing false blocks |
EPSS, per FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and its page covers combining EPSS with CVSS and KEV. A layered rule uses all of them: block on KEV, rank by EPSS, filter by reachability.
Limits to plan for
The catalog is small compared with all published CVEs, so a clean KEV check does not mean you are safe. It also lags: a flaw can be exploited before it is listed. Treat the rule as a floor.
Also decide what happens to dev only packages. A KEV match in a test dependency that never ships usually warrants a ticket, not a blocked release.
Try it yourself
Open the exploitability demo and compare a finding that is exploited with one that is only theoretical. Note how each changes the verdict.
Click through it at your own pace, or open it full screen.
Safeguard's policies and gates can include exploitation status in a rule, and reachability analysis helps decide whether a listed flaw touches your code. A free scan is at gold.safeguard.sh/scan.
Quick check
Do I need to block on every KEV entry in my repository?
Block on those in shipped dependencies. For dev tooling, open a ticket with a short deadline.
Is KEV the same as EPSS?
No. KEV lists flaws with observed exploitation. EPSS is a probability estimate for the next 30 days.
Sources
Last reviewed: 19 October 2026.
