ASPM tools usually prioritize by combining several signals: CVSS for severity, EPSS for the likelihood of exploitation, the CISA KEV catalog for confirmed exploitation, and local context such as whether the code is reachable and exposed. No single signal is enough on its own.
What each signal tells you
| Signal | Source | What it answers | What it cannot tell you |
|---|---|---|---|
| CVSS | FIRST | How severe is the flaw in general? | Whether it matters in your app |
| EPSS | FIRST | How likely is exploitation in the next 30 days? | Impact on your systems |
| KEV | CISA | Has it been exploited in the wild? | Whether you are exposed |
| Reachability | Your code analysis | Does your code call the vulnerable part? | Whether attackers can reach it |
| Exposure | Your environment | Is the service internet facing? | Severity of the flaw itself |
FIRST describes CVSS as a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity, now at version 4.0. It describes EPSS as a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days, published daily as a value between 0 and 1. CISA describes the KEV catalog as the authoritative source of vulnerabilities that have been exploited in the wild.
A simple way to combine them
Many teams use a tiered approach. Start with the strongest evidence and work down.
- Tier one. In KEV and present in a running service. Fix on your shortest timeline.
- Tier two. High EPSS or high CVSS, and reachable in your code. Fix on a standard timeline.
- Tier three. High severity but unreachable or not exposed. Schedule, and revisit if context changes.
- Tier four. Low on all signals. Batch with routine updates.
The exact thresholds are yours to choose. FIRST publishes guidance on setting EPSS thresholds and combining it with CVSS and KEV. Read that before picking numbers rather than borrowing a cutoff from a vendor slide.
Why not just use CVSS
A high CVSS score on a library function you never call is a real finding but not an urgent one. A medium score on an internet facing component that attackers are already using is urgent. CVSS alone ranks them the wrong way round. This is the main reason ASPM platforms add other inputs.
Why not just use EPSS
EPSS is a probability across all deployments of a flaw, not a statement about yours. It also changes daily, so a finding's rank can move. Expect that and avoid freezing a decision on a single day's value.
What to do when signals disagree
Write down the reasoning, not just the outcome. For example: "KEV listed, but the component is only used in a build tool that never ships. Reviewed by the service owner, revisit on next upgrade." A recorded reason is what makes the decision defensible later.
A worked example with three findings
The values below are invented for illustration.
| Finding | CVSS severity | EPSS | In KEV | Reachable | Internet facing |
|---|---|---|---|---|---|
| A: parsing library flaw | Critical | Low | No | No | Yes |
| B: web framework flaw | Medium | High | Yes | Yes | Yes |
| C: build tool flaw | High | Low | No | Not applicable | No |
A ranking by CVSS alone would put A first, then C, then B. That is the wrong order for most teams.
Applying the tier approach from earlier:
- B is in KEV, reachable and internet facing. It is tier one, fix now.
- A has a critical score but no call path from your code, so it is tier three, scheduled, with a recorded reason and a review date.
- C is high severity but sits in a build tool that does not ship and is not exposed. Tier three or four, handled with routine updates.
The order becomes B, A, C. The reasoning for each is a sentence long, which is exactly what you would show an auditor or a developer who asks why.
Step by step: setting up your own priority rules
- List the signals you can get reliably today: CVSS, EPSS, KEV, reachability, exposure.
- Write two or three rules in plain language, such as "KEV plus running in production is tier one."
- Test the rules on fifty past findings and see whether the order matches what experienced engineers would choose.
- Adjust, and write down why you adjusted.
- Review the rules every quarter, since data sources and your estate change.
Watching for score movement
EPSS is published daily, so the score for a CVE can change. A finding that was low last month may be higher now. Decide whether your platform recalculates automatically and how you are notified. A rule such as "reopen any scheduled item when it enters KEV" is simple and effective.
Why you still need a human
A scoring scheme tells you the order to look in. It cannot know that a particular service is about to be retired, or that a fix needs a coordinated release with another team. Keep a place for judgment, and require a short written reason whenever people override the order.
Where Safeguard fits
Safeguard provides reachability analysis and zero-day discovery, plus policies and gates to turn a priority decision into a rule. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how the signals line up for one finding.
Quick check
Is a KEV listing always urgent?
It raises priority because exploitation has been observed, but you still need to confirm you run the affected component.
Does a low EPSS score mean safe?
No. It means exploitation is less likely in the next 30 days, not impossible.
Do I need all of these signals to start?
No. Begin with severity and KEV, which are simple to use, and add reachability and exposure as your tooling allows.
Sources
Last reviewed: 19 October 2026.
