CVSS describes severity, EPSS estimates the chance of exploitation in the next 30 days, and KEV lists flaws known to be exploited. A good SCA tool shows all three and uses them to order your work, instead of sorting by one number. Ask to see each signal next to every finding.
What each signal says
CVSS is a severity score. FIRST states in its EPSS FAQ that CVSS base scores are not risk. A critical score on a flaw nobody exploits can be correct, and so can a medium score on one that is widely attacked.
EPSS is a probability between 0 and 1 that a CVE will be exploited in the wild within 30 days. FIRST says scores are generated daily and describes EPSS as a forecast of observed exploitation activity, not a complete risk score.
KEV is CISA's catalog of vulnerabilities known to be exploited in the wild. CISA tells organizations to treat it as one input to their prioritization framework. Entries carry fields such as the date added and whether use in ransomware campaigns is known.
A sensible ordering
None of these signals knows your environment. A workable order for a first pass:
- Findings on the KEV list, in code that is deployed
- Findings with a high EPSS value
- High CVSS findings with no exploit signal
- Everything else, handled in routine upgrades
Then adjust for context. A vulnerable package in an internet facing service outranks the same package in an internal batch job. CISA's KEV page itself says stakeholders are responsible for assessing each asset's internet exposure.
Things to avoid
FIRST says not to multiply EPSS by CVSS, because one is a calibrated probability and the other an expert ranking. If a tool shows a blended score, ask how it is computed and whether you can see the parts.
What to ask a vendor
- Do you show CVSS, EPSS, and KEV status on each finding?
- How often do you refresh EPSS and KEV data?
- Can I filter and set policy on each one separately?
- Can I see why a finding ranks where it does?
Add the missing signal: is the code called?
None of the three tells you whether your application can reach the vulnerable function. That is what reachability analysis addresses. A tool that combines exploit signals with reachability gives you the shortest list. See how to test reachability claims.
Safeguard's scanning includes reachability analysis and policies you can set on severity and other fields. The free scan at https://gold.safeguard.sh/scan shows how a result looks.
A worked example
Imagine three findings. One is a medium CVSS issue that appears on the KEV list in an internet facing service. One is a critical CVSS issue with a very low exploit probability in an internal tool. One is a high CVSS issue with a moderate probability in code your application never calls. The first goes to the top of the queue, even though its severity score is lowest. The second is scheduled. The third is watched, since reachability can change when code does. The numbers inform the order, and your environment decides it.
Quick check
Should I fix every KEV finding first?
Usually those come early, but confirm the vulnerable component is deployed and exposed in your environment.
Sources
Last reviewed: 19 October 2026.
