Vulnerability prioritization that works
If your remediation queue is "everything CVSS ≥ 7, sorted by CVSS," you are working off the weakest useful signal in vulnerability intelligence. This page lays out a prioritization model grounded in what actually predicts exploitation, how CISA's SSVC framework fits, and how we fused these signals into a concrete P1–P4 ranking, with worked examples where the popular intuition is wrong.
Why CVSS-driven prioritization fails
CVSS measures severity, how bad a vulnerability is if exploited. It says almost nothing about whether it will be. Measured against CISA KEV as ground truth:
- Critical CVSS (9.0–10.0) CVEs are actually exploited only a small fraction of the time.
- High-EPSS CVEs are exploited at a much higher rate, roughly an order of magnitude better as a predictor.
- And CVSS is nearly redundant given EPSS: combining both barely beats EPSS alone.
There are tens of thousands of "critical" CVEs. Treating them as one undifferentiated fire is how teams burn out and still miss the bug that gets them. CVSS belongs in a priority model, but as the impact term, not the likelihood term. The data behind these claims is in what actually predicts exploitation.
The signals that matter, in order
A defensible priority model fuses four things, each answering a different question:
| Signal | Question it answers | Source |
|---|---|---|
| KEV | Is it being exploited right now? (ground truth) | CISA Known Exploited Vulnerabilities |
| SSVC "exploitation" | exploitation state: none / PoC / active | CISA Vulnrichment |
| EPSS | How likely is exploitation soon? | FIRST EPSS |
| CVSS | How bad if exploited? (impact) | NVD |
The first three are about likelihood; the last is about impact. The common mistake is using CVSS for both.
SSVC: the underused signal
SSVC (Stakeholder-Specific Vulnerability Categorization) is CISA's decision framework, published per-CVE through the Vulnrichment program. Its three decision points are exactly what a triager wants:
- Exploitation:
none/poc/active - Automatable: can an attacker mass-exploit it?
yes/no - Technical impact:
partial/total
The striking thing, measured on the corpus: SSVC's active exploitation independently tracks the KEV catalog almost perfectly. Nearly every CVE marked active is also in KEV. That's two separate CISA programs agreeing closely, which is exactly what you want from a ground-truth signal.
Even better, the small disagreement is signal, not noise: a handful of CVEs are marked SSVC-active but aren't yet in KEV, actively-exploited bugs the exploited-list hadn't caught up to. That's a leading edge worth watching.
And the poc tier fills a real gap: a public proof-of-concept exists but exploitation isn't confirmed active. That's a meaningful escalation between "nothing" and "in the wild."
A concrete P1–P4 model
Here's the model we actually ship, exploitation-first, where each signal raises priority and never lowers it:
- P1 (Fix now): actively exploited (KEV or SSVC
active) and critical impact (CVSS ≥ 9). - P2 (Fix this week): actively exploited (KEV or SSVC
active), any severity. - P3 (Schedule): high CVSS (≥ 7) or high EPSS (top 10%) or a public PoC exists (SSVC
poc). - P4 (Monitor): everything else.
Fusing SSVC into this, letting active drive P1/P2 and poc drive P3, is small but consequential. It keeps the act-now tiers tight (you can't flood "fix now" with theoretical risk) while pulling genuinely dangerous bugs out of the "monitor" bucket.
Worked examples (where intuition is wrong)
Three real CVEs show why exploitation-first beats severity-first:
Log4Shell, CVE-2021-44228 → P1.
KEV-listed, SSVC active, high EPSS, CVSS 10. Every signal screams. The easy case, and the model agrees: fix now.
BlackLotus Secure Boot bypass, CVE-2022-21894 → P2 (not P4).
CVSS is only 4.4. Under pure CVSS prioritization this UEFI bootkit bug sits near the bottom of the queue. But SSVC marks it active (it's genuinely exploited), so exploitation-first correctly pulls it up to P2, "active exploitation despite lower severity." This is the case CVSS-driven triage gets catastrophically wrong.
The xz-utils backdoor, CVE-2024-3094 → P3 (and that's correct).
This is one of the most severe supply-chain incidents in years (CVSS 10), and the intuition is "obviously P1." But it was caught before deployment, never exploited in the wild, and SSVC accordingly marks exploitation none. So an honest exploitation-first model places it at P3 ("high severity, schedule") and says so: "no active exploitation detected." That's not a miss; it's the model being honest that potential ≠ active. A prioritization engine that can't make this distinction is just a severity sorter with extra steps.
Recon-to-dig-order: prioritization for hunters
For bug-bounty hunters and pentesters, prioritization isn't a patch queue, it's where to spend the next hour. The same signals power a different output: a ranked dig-order for a discovered stack.
Given a recon'd stack (say craftcms 4.4, nginx, keycloak), a hunter-facing tool returns, per component:
- its top high-risk CVEs (KEV / SSVC-active / high-EPSS first, version-aware),
- and its recurring loci, the bug classes that product family repeatedly fails at, weighted by real in-the-wild exploitation.
In practice that surfaces things like: Craft CMS repeatedly breaks at code/command injection (probe template and eval surfaces first); OpenSSL at memory and crypto; lodash at prototype pollution. It's not the model guessing, it's the exploitation data telling you where this family historically bleeds. Where to look, and what shape to expect.
A note on freshness
Time-to-exploit has collapsed to days. A priority model is only as good as the data behind it is fresh. A KEV listing you ingest a week late, or an EPSS score you don't refresh daily, quietly turns a P1 into a missed P4. Prioritization and freshness are the same problem.
FAQ
Should I prioritize vulnerabilities by CVSS? Not by CVSS alone. CVSS measures impact, not likelihood; critical-CVSS CVEs are exploited only a small fraction of the time, while high-EPSS CVEs are exploited at a much higher rate. Use EPSS, KEV, and SSVC for likelihood and CVSS for impact.
What is SSVC and how does it relate to KEV?
SSVC (Stakeholder-Specific Vulnerability Categorization) is CISA's per-CVE decision framework with three points: exploitation (none/poc/active), automatable, and technical impact. Its active tier closely tracks the KEV exploited-list in our data, and occasionally flags actively-exploited CVEs before KEV catches them.
How should I combine EPSS, KEV, SSVC, and CVSS?
Exploitation-first: KEV or SSVC-active → top tier (fix now/this week); high EPSS or a public PoC → schedule; CVSS for the impact dimension. Let each signal raise priority; never let severity alone define the top tier.
Why is a CVSS 10 vulnerability sometimes low priority?
Because severity isn't exploitation. The xz backdoor (CVSS 10) was caught before any in-the-wild use, so its SSVC exploitation is none and an honest model schedules it (P3) rather than treating it as actively-exploited. Conversely, a low-severity bug that is being exploited (BlackLotus) belongs near the top.
The data behind these signals: What actually predicts vulnerability exploitation. Whether an LLM can reason over this corpus better than a base model: Eight experiments.