Fix first what attackers are already using and what your software actually exposes. Check whether the CVE is on CISA's Known Exploited Vulnerabilities list, look at its EPSS score for likelihood, and confirm whether your code reaches the flawed component. Severity score alone is a weak guide.
Three signals, in order
Small teams cannot fix every alert. A short ordered check keeps effort on real risk.
| Order | Signal | What it tells you |
|---|---|---|
| 1 | Is it in the KEV catalog? | Exploitation in the wild has been observed |
| 2 | What is its EPSS score? | Estimated chance of exploitation in the next 30 days |
| 3 | Is it reachable and exposed in your code? | Whether your build can actually trigger it |
Signal one: the KEV catalog
CISA maintains the Known Exploited Vulnerabilities catalog as an authoritative source of vulnerabilities exploited in the wild, and advises organizations to use it as an input to their vulnerability management prioritization. It is available as CSV and JSON, so you can match it against your dependency list automatically. A match means move it to the top of the queue.
Signal two: EPSS
The Exploit Prediction Scoring System is a data driven model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. FIRST publishes a score between 0 and 1 for every CVE each day, free, via CSV and API. Use it to sort the items that are not on the KEV list. A higher score means look sooner. It is a probability, not a verdict, and it says nothing about whether you run the vulnerable code path.
Signal three: reachability and exposure
A flaw in a package you installed matters most if your code calls the vulnerable function and an attacker can reach that code. Ask three questions: is the component in production, does our code call the affected feature, and is the service reachable from the internet or from untrusted input? An unreachable finding in an internal tool can wait. A reachable one in a public API cannot.
Turning it into a rule
Write the rule on one page so any engineer can apply it.
- KEV match in production, fix now.
- High EPSS and reachable, fix this sprint.
- Everything else, batch it into routine updates.
Add one exception line: anything with a public exploit and your internet facing service gets looked at the same day.
Pitfalls
Treating CVSS as a ranking. Ignoring dev dependencies that reach your build pipeline. Forgetting container base images. Letting a "fix later" item sit without a date, which is why a risk record helps.
Where Safeguard fits
Safeguard's reachability analysis shows which dependency findings your code actually reaches, which supports the third check. Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one finding is judged for exploitability, which is the third check above.
Quick check
Does a low EPSS mean it is safe?
No. It means exploitation is less likely in the next 30 days. Combine it with exposure and with KEV status.
Is the KEV list only for government?
Anyone can use it. CISA recommends organizations use it as an input to prioritization.
Sources
Last reviewed: 19 October 2026.
