All flagged CVEs — severity based on CVSS alone. High and Moderate flood the report. No signal about what's actually being exploited.
32 CVEs removed — EPSS below 5% probability of exploitation. These are real vulnerabilities, but threat actors aren't using them.
CVE-A: On CISA KEV — confirmed active exploitation. Patch in 24h.
CVE-B: EPSS 0.87, public PoC published 3 days ago. Patch this week.
Your scanner reports 127 vulnerabilities. Your team has capacity to patch 15 this sprint.
Which 15?
If you're sorting by CVSS score — highest first — you're almost certainly getting it wrong. Research shows that at most about 6% of published CVEs are ever exploited in the wild, and stricter datasets put it nearer 1–2%. That means at least 119 of those 127 findings will never be used in an actual attack. But CVSS can't tell you which ones. It measures how bad a vulnerability could be, not how likely it is to hurt you — see CVSS vs EPSS: two scores, two different questions for a side-by-side of what each score actually answers.
The result is predictable: teams burn out patching CVSS 9.8 vulnerabilities that no attacker cares about while CVSS 4.0 flaws with active exploits sit unpatched for weeks.
There's a better way.
TL;DR: The 3-Signal Triage Method uses three data points — CVSS (severity), EPSS (exploitation probability), and CISA KEV (confirmed exploitation) — to sort vulnerabilities by actual risk. Start with these 3 signals. That alone eliminates 70-80% of the noise, leaving your team focused on the vulnerabilities that will actually be used in attacks.
What We'll Cover
- Why CVSS-only prioritization fails
- The 3 signals explained
- The CVSS x EPSS decision matrix
- 5-step triage workflow
- Real-world examples across ecosystems
- Common objections and responses
Why CVSS-Only Prioritization Fails
CVSS was designed to describe characteristics of a vulnerability — attack vector, complexity, required privileges, impact on confidentiality/integrity/availability. It does this well. What it was never designed to do is predict whether anyone will actually exploit the flaw.
The disconnect is dramatic:
CVSS Score Distribution vs Actual Exploitation
CVSS Range % of CVEs % Actually Exploited
─────────────────────────────────────────────────
9.0–10.0 ████ ~8% of all CVEs ~12% exploited
7.0–8.9 ██████████ ~22% of all CVEs ~8% exploited
4.0–6.9 ████████████ ~35% of all CVEs ~5% exploited
0.1–3.9 ████████████ ~35% of all CVEs ~2% exploited
─────────────────────────────────────────────────
Key insight: High CVSS ≠ high exploitation rate.
A CVSS 9.0+ CVE is only ~12% likely to be exploited.
If you patch every CVSS 7.0+ vulnerability with equal urgency, you're treating a 92% false-positive rate as acceptable. Your team is doing the security equivalent of treating every headache like a brain tumor.
The core problem: CVSS is severity without context. It tells you the blast radius if a bomb goes off but nothing about whether anyone is building the bomb.
The 3 Signals Explained
The 3-Signal Triage Method layers three orthogonal data sources to produce a single prioritization:
Signal 1: CVSS — Theoretical Severity
What it answers: "How bad could this be if exploited?"
CVSS (Common Vulnerability Scoring System) rates vulnerabilities from 0.0 to 10.0 based on attack characteristics. It's a useful measure of blast radius — a CVSS 9.8 remote code execution is objectively more dangerous than a CVSS 3.1 information disclosure if exploited.
Role in triage: Tiebreaker. When two vulnerabilities have the same EPSS score, patch the higher CVSS first. CVSS also matters for compliance — frameworks like PCI-DSS mandate patching CVSS 7.0+ within specific timeframes regardless of exploitation status.
Signal 2: EPSS — Exploitation Probability
What it answers: "Will someone exploit this in the next 30 days?"
EPSS (Exploit Prediction Scoring System) is a machine learning model maintained by FIRST.org that predicts the probability a CVE will be exploited within 30 days. It ingests threat intelligence feeds, proof-of-concept code, malware analysis, and dark web mentions to produce a daily-updated score from 0.0 to 1.0.
Role in triage: Primary sort key. EPSS is what separates "theoretically bad" from "practically dangerous." About 85% of CVEs have EPSS below 0.1 — meaning the vast majority of scanner findings are noise.
Signal 3: CISA KEV — Confirmed Active Exploitation
What it answers: "Is someone exploiting this RIGHT NOW?"
CISA KEV (Known Exploited Vulnerabilities) is a curated catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency. Every entry has been confirmed as actively exploited by real threat actors. It's the highest-confidence signal available.
Role in triage: Override. Any vulnerability on CISA KEV jumps to the top of the queue regardless of CVSS or EPSS score. If CISA says it's being exploited, you patch it today.
We audited a full year of KEV listings against our own tracked ecosystems to see how reliable this override signal actually is in practice: our KEV exploitation research found a median 82-day gap between CVE publication and KEV listing, and that EPSS gave zero advance warning in 48.1% of the matched cases — the honest reason KEV has to stay a same-day override rather than something you can always see coming.
How the 3 Signals Work Together
┌──────────────────────────────────────────────────────────────────┐
│ 3-Signal Triage Method │
│ │
│ Signal Question Priority Role │
│ ────── ──────── ───────────── │
│ CISA KEV Being exploited now? Override (→ top) │
│ EPSS Will be exploited soon? Primary sort key │
│ CVSS How bad if exploited? Tiebreaker │
│ │
│ Sort order: KEV first → EPSS descending → CVSS descending │
│ │
│ Result: Your top 15 patches are the 15 most likely to be │
│ used in actual attacks against your systems. │
└──────────────────────────────────────────────────────────────────┘
This is deliberately simple. Three signals. One sort order. No spreadsheets, no committee meetings, no "risk assessment workshops." Start with 3 signals. That alone eliminates 70-80% of noise.
The CVSS x EPSS Decision Matrix
Plot your vulnerabilities on two axes — CVSS (severity) and EPSS (exploitation probability) — and four quadrants emerge:
CVSS Score (Theoretical Severity)
Low (0–5) High (6–10)
┌───────────────────┬───────────────────────┐
High │ PRIORITY ZONE │ CRISIS ZONE │
EPSS 0.5+ │ │ │
(Exploit │ Lower severity │ High severity AND │
proba- │ but actively │ actively exploited. │
bility) │ exploited. Don't │ Emergency patch. │
│ ignore — patch │ 24-hour SLA. │
│ within 1 week. │ │
├───────────────────┼───────────────────────┤
Low │ NOISE ZONE │ MONITORING ZONE │
0.5- │ │ │
│ Low severity, │ Looks scary on paper │
│ nobody exploiting │ (high CVSS) but no │
│ it. Safe to │ exploitation signals. │
│ deprioritize. │ Patch next quarter. │
│ Routine maint. │ Watch for EPSS spike. │
└───────────────────┴───────────────────────┘
CISA KEV override: Any vulnerability on KEV moves to CRISIS
regardless of quadrant. KEV = confirmed exploitation = top priority.
Most vulnerability scanners — npm audit, pip-audit, basic Dependabot — only show the horizontal axis. They tell you "this CVSS is 9.2, patch urgently" without knowing whether anyone is actually exploiting it. If your queue is already GitHub-generated, the practical first step is layering EPSS on top of your existing feed — see prioritize Dependabot alerts with EPSS for the workflow that converts a noisy security tab into an ordered, actionable queue.
The vertical axis (EPSS) is where the signal lives. Adding it transforms your triage from guesswork to data-driven prioritization.
The 5-Step Triage Workflow
Here's the complete workflow, from scanner output to patch plan:
┌─────────────────────────────────────────────────────────────┐
│ 5-Step Triage Workflow │
│ │
│ Step 1: SCAN │
│ ├─ Upload lock file or connect repository │
│ └─ Get full vulnerability list with CVSS + EPSS + KEV │
│ │
│ Step 2: FILTER — Remove noise │
│ ├─ Dev-only dependencies → log, don't prioritize │
│ ├─ EPSS < 0.1 AND not on KEV → routine maintenance │
│ └─ Unreachable code paths → document and deprioritize │
│ │
│ Step 3: SORT — Apply the 3-Signal priority │
│ ├─ 1st: CISA KEV entries → top of queue │
│ ├─ 2nd: EPSS descending (highest exploitation prob first) │
│ └─ 3rd: CVSS descending (tiebreaker) │
│ │
│ Step 4: ASSIGN — Set SLAs by tier │
│ ├─ KEV or EPSS > 0.9 → Patch within 24 hours │
│ ├─ EPSS 0.7–0.9 → Patch within 1 week │
│ ├─ EPSS 0.3–0.7 → Patch within 2 weeks │
│ ├─ EPSS 0.1–0.3 → Patch within 30 days │
│ └─ EPSS < 0.1 → Routine maintenance (quarterly) │
│ │
│ Step 5: MONITOR — Watch for changes │
│ ├─ Re-scan on schedule (daily for prod, weekly otherwise) │
│ ├─ Alert on EPSS spikes (score increase > 0.3) │
│ └─ Alert on new KEV entries matching your dependencies │
│ │
└─────────────────────────────────────────────────────────────┘
The key insight is Step 2: filtering removes 70-80% of findings before you even start prioritizing. Most vulnerabilities have EPSS below 0.1 and aren't on KEV. They're real vulnerabilities that deserve eventual patching, but they're not the ones that will be used in an attack against your systems this month.
Real-World Examples Across Ecosystems
The 3-Signal Triage Method works the same regardless of your stack. Here's how it plays out in practice:
npm — The Transitive Dependency Problem
Finding: lodash prototype pollution (CVE-2020-8203)
CVSS: 7.2 (High) npm audit says: "HIGH — patch urgently"
EPSS: 0.02 Reality: Almost no one exploiting this
KEV: No 3-Signal verdict: Routine maintenance
Finding: express path traversal (CVE-2024-29041)
CVSS: 7.8 (High) npm audit says: "HIGH — patch urgently"
EPSS: 0.68 Reality: Actively weaponized
KEV: Yes 3-Signal verdict: PATCH TODAY
npm audit gives these identical urgency. The 3-Signal Method doesn't.
The scores above are illustrative, chosen to demonstrate the divergence the 3-Signal Method is built to catch — check CVE-2024-29041's live record for its actual current EPSS score and KEV status rather than treating this table as a live lookup.
For a deeper dive into npm-specific prioritization, see npm audit vs GeekWala.
Python — Fragmented Advisory Databases
Python's security ecosystem is fragmented across PyPI advisories, GitHub Security Advisories, and OSV. A single CVE might appear in one database but not another. EPSS cuts through this fragmentation because it scores the CVE itself, not the advisory source.
A requests library vulnerability with CVSS 7.5 but EPSS 0.03 is routine maintenance. A cryptography flaw with CVSS 5.9 but EPSS 0.71 needs immediate attention — regardless of which advisory database flagged it first.
Go — Stdlib Vulnerabilities Affect Everything
Go's module system means stdlib vulnerabilities (like those in net/http or crypto/tls) affect every Go service. When govulncheck reports a stdlib CVE, the 3-Signal Method helps you decide whether to rush a Go version upgrade or schedule it normally.
Java — 200+ Transitive Dependencies
Enterprise Java projects routinely have 200+ transitive dependencies through Maven. Running a scanner produces overwhelming results. The 3-Signal Method is especially valuable here because it compresses 200 findings into a manageable action list of 5-10 items that actually need urgent attention.
Common Objections and Responses
"Our compliance framework requires patching all CVSS 7.0+ within 30 days"
The 3-Signal Method doesn't replace compliance requirements — it optimizes within them. You still patch CVSS 7.0+ within 30 days. But now you know which of those 7.0+ findings to patch on day 1 (KEV entries, high EPSS) versus day 29 (low EPSS, no KEV). Compliance sets the floor. The 3-Signal Method sets the priority order.
"EPSS is only a 30-day prediction. What about long-term risk?"
True — EPSS doesn't predict whether a vulnerability will be exploited six months from now. But "patch everything to be safe" doesn't scale when you have 127 findings and 15 slots. EPSS gives you the tactical answer: what to patch this sprint. Long-term risk management means re-scanning regularly so that EPSS changes (like a score jumping from 0.02 to 0.7 after a PoC is published) get caught in your next cycle.
"We don't have time to check three different data sources"
You don't have to. Tools like GeekWala enrich every CVE with CVSS, EPSS, and KEV status automatically when you scan. The 3-Signal Method is a framework, not a manual process. Upload your lock file, get results sorted by actual risk.
"What about vulnerabilities that aren't in any database yet (zero-days)?"
Zero-days are outside the scope of vulnerability scanning entirely — they don't have CVE IDs yet. The 3-Signal Method applies to known vulnerabilities. For zero-day risk, you need defense-in-depth (WAFs, network segmentation, least privilege), which is complementary to vulnerability prioritization.
Quick Reference: The 3-Signal Triage Card
┌──────────────────────────────────────────────────┐
│ 3-Signal Triage Method │
│ │
│ 1. CHECK KEV STATUS │
│ On CISA KEV? → PATCH WITHIN 24 HOURS │
│ │
│ 2. CHECK EPSS SCORE │
│ > 0.9 → Patch within 24 hours │
│ 0.7–0.9 → Patch within 1 week │
│ 0.3–0.7 → Patch within 2 weeks │
│ 0.1–0.3 → Patch within 30 days │
│ < 0.1 → Routine maintenance │
│ │
│ 3. USE CVSS AS TIEBREAKER │
│ Same EPSS? Higher CVSS goes first. │
│ │
│ Sort: KEV → EPSS desc → CVSS desc │
└──────────────────────────────────────────────────┘
Which vulnerabilities should I fix first?
Anything in CISA KEV, today — those are confirmed active exploitation and the Known Exploited Vulnerabilities catalog is the strongest single signal available. Next, patch EPSS ≥ 0.1 findings that live on a reachable code path or production-exposed service, inside the current sprint. Then schedule CVSS-only critical findings in runtime code for the following sprint, treat everything else as normal patch cadence. That order maps exploitation probability to urgency instead of treating every CVSS 9.8 as an emergency.
Is CVSS score enough to prioritize?
No. CVSS measures blast radius, not likelihood of exploitation — research shows ~12% of CVSS 9.0+ CVEs are ever weaponized. Sorting by CVSS alone means you work through a list that is ~88% false positives by volume while genuinely dangerous CVSS 6.x bugs with active exploits wait for weeks. CVSS vs EPSS: two scores, two different questions unpacks exactly where CVSS-only prioritization breaks and why EPSS is the prioritization signal.
How does KEV membership change priority?
KEV is the override signal. When CISA publishes a vulnerability in the Known Exploited Vulnerabilities catalog, it has already been seen being exploited — no prediction, no probability. Treat KEV as a same-day patch requirement regardless of CVSS (a "moderate" KEV entry is still being actively attacked) and regardless of EPSS (the exploitation already happened, so 30-day probability is academic). If you only act on one signal, make it KEV.
What EPSS threshold actually matters?
0.1 is where the curve turns. Roughly 85% of CVEs sit below EPSS 0.1; above that threshold, exploitation is measurably more likely than the base rate. Start with EPSS ≥ 0.1 as your "patch this sprint" trigger and EPSS ≥ 0.7 as your "patch this week" trigger. Tune from there based on your risk appetite — but avoid the temptation to raise the threshold high enough to make the queue empty, because that's how teams miss the 4% that are actually being exploited.
How do I explain prioritization to engineering?
Frame it as economics, not security: you have limited patching capacity, CVSS alone forces you to spend 80%+ of it on vulnerabilities that no attacker will touch. The 3-Signal Method is how you redirect that capacity toward the ~5-10% of findings that will actually be used in an attack. Show engineers the alert-fatigue-funnel chart above — one slide, two numbers (total CVEs vs CVEs anyone will exploit), and it clicks. They don't need the theoretical argument; they need the queue to be shorter and more honest.
How is the 3-Signal Triage Method different from what FIRST recommends?
FIRST (the organization behind EPSS) recommends using EPSS alongside CVSS but doesn't prescribe a specific workflow. The 3-Signal Triage Method is an opinionated implementation that adds CISA KEV as an override signal and defines concrete SLAs for each EPSS tier. It's a practical application of FIRST's research, not a competing standard.
Can I automate the 3-Signal Method in CI/CD?
Yes. Set your CI pipeline to fail on KEV entries or EPSS above a threshold (0.7 is a good starting point). Let lower-priority findings generate tickets instead of blocking deploys. This prevents alert fatigue in CI while still catching genuinely dangerous vulnerabilities before they ship.
What if a vulnerability has high EPSS but my application doesn't use the affected code path?
Reachability analysis is a valid fourth signal — but it requires deep static analysis that most tools don't provide yet. In practice, if a vulnerability is in a production dependency and has high EPSS, patch it. The cost of patching is almost always lower than the cost of proving unreachability.
How often should I re-scan to catch EPSS changes?
Daily for production systems. EPSS scores change as new threat intelligence arrives — a vulnerability at EPSS 0.05 today can spike to 0.8 tomorrow when a proof-of-concept is published. Weekly scanning is the minimum for any system handling user data.
Does the 3-Signal Method work for container image vulnerabilities too?
Yes. Container image scanners (Trivy, Grype) report CVEs with CVSS scores. You can layer EPSS and KEV data on top using the same framework. The signals are CVE-level, not ecosystem-specific — they work for OS packages, language dependencies, and application libraries equally.
Ready to see your vulnerabilities sorted by actual risk instead of CVSS severity?
Scan your dependencies now → — upload a lock file and get every finding enriched with CVSS, EPSS, and CISA KEV status. The 3-Signal Triage Method, applied automatically. No account needed.
For a practical application of this framework — turning a real 200-CVE scan into a 3-item action list — see What to Do When Your Scanner Finds 200 CVEs.
For the operational side of acting on your prioritized list, see Software Supply Chain Security Guide — a practical framework for building security into your dependency workflow.
