None of them should drive the queue alone. CVSS rates how severe a flaw is, EPSS estimates the chance it will be exploited in the next 30 days, and the CISA KEV catalog lists flaws already exploited in the wild. Start with KEV, then EPSS, then use CVSS as a tiebreaker.
What each signal actually says
CVSS produces a numeric severity score that can be mapped to low, medium, high or critical. FIRST describes it as capturing the principal characteristics of a vulnerability. The current version is CVSS v4.0. Severity describes the flaw in the abstract, not whether anyone is attacking it.
EPSS is a model maintained by an EPSS special interest group at FIRST. It publishes a probability between 0 and 1, plus a percentile, every day for every CVE. The probability is for exploitation in the wild in the next 30 days.
KEV is the CISA Known Exploited Vulnerabilities catalog. Entries are vulnerabilities that have been exploited in the wild. Each carries a date added and a due date, and CISA positions the list as one input to prioritization.
| Signal | Answers | Type | Update rhythm |
|---|---|---|---|
| CVSS | How bad could it be? | Severity score | Set when scored, may be revised |
| EPSS | How likely is exploitation soon? | Probability | Daily |
| KEV | Is it being exploited now? | Catalog | As entries are added |
A simple ordering
- Check KEV first. If a component you ship is listed, treat it as urgent. Exploitation is confirmed.
- Then look at EPSS. Among the rest, a higher probability means higher priority.
- Use CVSS to break ties and to weigh impact if exploited.
- Add your own context. Is the vulnerable code reachable? Is the service internet facing? Does it hold sensitive data?
Step four matters most. None of the public signals know your environment.
Common mistakes
- Sorting by CVSS only. A critical score on a library that your code never calls can outrank a medium score on something under active attack.
- Treating a low EPSS as safe. It is a probability, not a guarantee. A low score for a very exposed system can still deserve a fix.
- Ignoring KEV because you are not a federal agency. The catalog is useful to any defender as evidence of real attacks.
- Using static thresholds forever. EPSS changes daily, so a nightly re-rank beats a one time triage.
Turning it into policy
Write the ordering down. For example: KEV listed and reachable means fix within your shortest service level. High EPSS and reachable means the next tier. Everything else follows normal upgrade cycles. Put numbers on the tiers using your own risk appetite rather than copying someone else's.
A worked example
Take three findings in one application. The numbers below are invented to show the method.
| Finding | CVSS severity | On KEV list | EPSS | Reachable | Internet facing |
|---|---|---|---|---|---|
| A | High | No | Low | No | No |
| B | Medium | Yes | High | Yes | Yes |
| C | Critical | No | Medium | Yes | No |
A severity only sort puts C first, then A, then B. The ordering described above puts B first, because exploitation is confirmed and the code is reachable and exposed. C follows, since it is reachable and severe. A comes last because nothing suggests it is urgent.
Step by step: build the ordering into your queue
- Export findings with CVE IDs. Both KEV and EPSS are keyed by CVE.
- Add a KEV column. Look up each CVE in the CISA catalog. Treat a match as the top tier.
- Add an EPSS column. FIRST publishes a probability and percentile daily for every CVE. Refresh it on a schedule.
- Add reachability and exposure. These come from your own tools and inventory.
- Define tiers. For example, tier one is KEV listed and reachable, tier two is high EPSS and reachable, tier three is everything else.
- Attach deadlines to tiers. Use numbers you can meet.
- Review exceptions monthly. Items parked because they are not reachable should return to the queue if the code changes.
Limits to remember
- EPSS is a probability for a window of 30 days. It is not a verdict, and brand new CVEs may have little history behind the number.
- KEV lists confirmed exploitation, not all exploitation. A CVE missing from the catalog is not proof of safety.
- CVSS can be adjusted. FIRST notes that environmental guidance exists so users can tailor scores to their deployment, which helps when you know your context.
- Your own context beats all three. A reachable flaw in an exposed service deserves attention even if public signals are modest.
How to explain this to leadership
Use plain terms. Severity says how bad it could be. Exploitation evidence says whether attackers are using it. Reachability says whether our code can trigger it. We fix first what is bad, in use and reachable. That framing usually ends debates about why the highest score is not always first.
Try it yourself
Pick a finding and see how exploitability signals change its rank compared with severity alone.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis supply the environment context these public signals lack, and policies can turn an ordering like the one above into an enforced gate. A free scan is at gold.safeguard.sh/scan.
Quick check
Is EPSS a replacement for CVSS?
No. They answer different questions. CVSS describes severity, EPSS estimates likelihood of exploitation.
How often should I re-rank findings?
EPSS publishes daily, so re-ranking at least daily keeps the queue current.
What if a CVE has no EPSS score yet?
Fall back on KEV status, reachability and exposure, and re-check the score as history builds, since EPSS publishes daily.
Sources
Last reviewed: 19 October 2026.
