Export the scanner's findings, mark which CVEs appear in the CISA Known Exploited Vulnerabilities (KEV) catalog, look up each CVE's EPSS score, and compare that ranking with the scanner's own. If KEV entries sit at the bottom of the list, the prioritization is not helping you.
Two outside signals
Severity scores such as CVSS describe how bad a flaw could be. They do not say whether anyone is using it. Two public sources add that missing piece.
KEV. CISA describes the KEV catalog as the authoritative source of vulnerabilities that have been exploited in the wild and says organizations should use it as an input to their vulnerability management prioritization framework.
EPSS. The Exploit Prediction Scoring System is, in FIRST's words, a data driven model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a probability between 0 and 1, with percentiles, daily for every CVE.
They answer different questions. KEV is a fact about past exploitation. EPSS is a forecast. Use both.
The method
- Export all findings from the PoC scan with CVE IDs and the scanner's priority or severity.
- Add a column, in KEV or not, using the catalog's downloadable file.
- Add a column for EPSS score from FIRST's data.
- Sort by the scanner's ranking and note where the KEV entries land.
- Sort by KEV first, then EPSS, and compare the two lists.
| What you see | What it suggests |
|---|---|
| KEV entries near the top | Scanner prioritization lines up with exploitation |
| KEV entries buried | Ranking relies on severity alone |
| Scanner shows KEV or EPSS data | Good, check that it matches the public values |
| Scanner shows neither | Ask how it ranks and what inputs it uses |
Caveats you should write down
- Most findings will not be in KEV. That is normal. Do not read an empty KEV column as a problem with the scanner.
- EPSS scores change daily. Record the date you pulled them.
- Neither signal knows your environment. A KEV entry in a package you never call at runtime may matter less than a modest score in your internet facing path. That is where reachability analysis comes in.
- Neither is a substitute for your own judgment on crown jewel systems.
Turn it into a pass mark
A workable criterion: for every KEV listed finding in the sample, the scanner ranks it in the top slice of its list or flags it clearly. Pick the slice size with your team, say the top twenty. Then add a second criterion: the scanner shows why it ranked each finding, so a developer can challenge it.
A short example of reading the result
Say your scan returns a few hundred findings, and only a handful are in KEV. You sort by the scanner's priority and the KEV items appear at positions one, two, four, nine and eighty. Four of five near the top is a pass. The one at eighty deserves a question to the vendor: why was it ranked low? Maybe it is dev only, which is a legitimate reason. Maybe it is a gap. Either way you learned something.
Try it yourself
Open the demo and look at how exploit signals change a finding's priority, then compare that logic with the KEV and EPSS columns you built.
Click through it at your own pace, or open it full screen.
Quick check
Does a high EPSS score mean we are being attacked?
No. It is a probability estimate across all uses of a CVE, not a statement about your systems.
Is KEV enough on its own?
It is a strong signal but a narrow one. Use it with exploit likelihood and reachability.
Sources
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
