A typical enterprise application, scanned honestly, returns thousands of vulnerabilities. If you sort that list by CVSS severity and start at the top, you will spend the next quarter patching "critical" findings that no attacker will ever touch while a medium-severity bug that's actively being exploited in the wild sits untouched at position 800. The problem isn't that you have too many vulnerabilities. It's that severity — how bad a vulnerability would be if exploited — is the wrong primary sort key. What you need to know first is how likely it is to be exploited and whether it's even reachable in your environment. This guide lays out the signals that answer those questions and how to combine them into a defensible priority model.
Why CVSS is a bad priority signal on its own
CVSS measures intrinsic severity — the theoretical impact and exploitability of a vulnerability in the abstract. It was never designed to be a risk score, and its own maintainers say so. The base score doesn't know whether the vulnerable code path exists in your build, whether a public exploit exists, or whether attackers are using it right now. The result of prioritizing by CVSS alone is predictable: a huge pile of 7.0-plus findings, most of which will never be weaponized, and no way to tell them apart. CVSS v4.0 (released late 2023) improved the base metrics, but it's still an input to prioritization, not the answer.
The four signals that actually predict risk
Effective prioritization combines four independent signals. Each answers a different question:
- EPSS (Exploit Prediction Scoring System) — a FIRST.org model that outputs a 0-to-1 probability that a vulnerability will be exploited in the next 30 days, based on real-world exploitation data. This answers how likely is exploitation? Most CVEs score very low; a small fraction score high, and that's your signal.
- CISA KEV (Known Exploited Vulnerabilities) — a curated catalog of vulnerabilities confirmed to be actively exploited in the wild. Presence in KEV answers is this being used against real targets right now? — and for U.S. federal agencies it carries a binding remediation deadline.
- Reachability — static analysis of whether the vulnerable function is actually invoked from your application's call graph. This answers does this even apply to us? A CVE in a package you import but never call the affected code of is, for practical purposes, not your problem this sprint.
- Business context / exposure — is the affected service internet-facing, does it handle sensitive data, is it in the authentication path? This answers what happens if it does get exploited here?
Use SSVC to turn signals into a decision
Rather than collapsing everything into a single number, CISA and Carnegie Mellon's SEI promote SSVC (Stakeholder-Specific Vulnerability Categorization) — a decision tree that routes each vulnerability to an action based on exploitation status, exposure, and impact. The outputs are concrete: Track (fix on normal cadence), Track*, Attend (prioritize this sprint), or Act (drop everything). SSVC's virtue is that it's a decision, not a score you then have to interpret. A vulnerability that's actively exploited (in KEV), reachable, and on an internet-facing service resolves to Act; the same CVSS 9.8 in an unreachable dev dependency resolves to Track.
A practical priority model
Combine the signals into tiers your team can act on without debating each finding:
| Tier | Condition | SLA |
|---|---|---|
| P0 — Act now | Reachable AND (in KEV OR EPSS ≥ 0.5) | Hours to 3 days |
| P1 — This sprint | Reachable AND high severity AND EPSS elevated | ≤ 2 weeks |
| P2 — Scheduled | Reachable, moderate severity/likelihood | Next release |
| P3 — Backlog | Not reachable, or dev-only, low EPSS | Track, batch-fix |
The most important line in that table is the reachability qualifier on the top tiers. Reachability is what shrinks a five-figure finding count to a two-figure action list. Without it, EPSS and KEV still improve your ordering, but you're ordering a list that's mostly irrelevant to your actual attack surface.
Wire prioritization into the pipeline, not a spreadsheet
Prioritization that lives in a monthly review meeting is always behind the exploit curve — EPSS scores move daily and KEV entries appear the moment CISA confirms exploitation. Enrich findings automatically at scan time so the priority is attached to the finding when the developer sees it, and gate merges only on the top tiers. Everything below the block threshold surfaces as advisory. This is where software composition analysis with built-in reachability and exploit enrichment earns its keep: the developer opening a pull request sees "reachable, in KEV, fix available" on the one finding that matters, not a severity histogram of 400.
How Safeguard Helps
Safeguard's SCA engine computes reachability against your actual call graph and enriches every finding with live EPSS probability and CISA KEV status, so the priority is decided at scan time rather than in a triage meeting. Policy gates block only the reachable, exploitable tiers and route the rest to backlog, which keeps false positives — and developer frustration — low. Griffin AI explains why a given finding scored the way it did and what the safest fix is, in plain language attached to the pull request. If you're comparing against reachability claims from other vendors, our Safeguard vs Snyk comparison shows how the models differ, and pricing covers what's included at each tier.
Start prioritizing by exploitability free at app.safeguard.sh/register, or read the scanning and policy docs at docs.safeguard.sh.