Stop Patching by CVSS Score. Use the 3-Signal Triage Method Instead.

To prioritize vulnerabilities when your scanner returns hundreds, triage by three signals in order: patch anything in CISA KEV within 24 hours, then work findings with EPSS of 10% or more on a sliding schedule (above 90% in 24 hours, 10–30% within 30 days), then schedule CVSS-only critical findings in runtime code for the next sprint. Everything else follows normal patch cadence.

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%. FIRST's EPSS model and CISA's KEV catalog are the two primary-source signals this triage method is built on. 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.

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:

Key insight: high CVSS does not mean a 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, established under Binding Operational Directive 22-01. 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

Sort order: KEV first, then EPSS descending, then CVSS descending. Your top 15 patches are then 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:

CISA KEV override: any vulnerability on KEV moves to the crisis zone regardless of quadrant. KEV means confirmed exploitation, so it is top priority.

Most native scanners — npm audit, pip-audit — show at most the horizontal axis: npm audit tells you "this is critical, patch urgently" without knowing whether anyone is actually exploiting it, and pip-audit doesn't even tell you that. If your queue is already GitHub-generated, the practical first step is to filter and sort it by the EPSS score Dependabot already shows, then add the CISA KEV check on top — 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:

1. Scan. Upload a lock file or connect a repository, and get the full vulnerability list with CVSS, EPSS, and KEV.
2. Filter out noise.
   • Dev-only dependencies: log them, don't prioritize.
   • EPSS below 10% and not on KEV: routine maintenance.
   • Unreachable code paths: document and deprioritize.
3. Sort by the 3-signal priority. CISA KEV entries first, then EPSS descending (highest exploitation probability first), then CVSS descending as the tiebreaker.
4. Assign SLAs by tier.
   • On KEV, or EPSS above 90%: patch within 24 hours.
   • EPSS 70–90%: patch within 1 week.
   • EPSS 30–70%: patch within 2 weeks.
   • EPSS 10–30%: patch within 30 days.
   • EPSS below 10% and not on KEV: routine maintenance (quarterly). CVSS-critical findings in runtime code are the exception: schedule them for the next sprint.
5. Monitor. Re-scan on schedule (daily for production, weekly otherwise) so rankings use today's EPSS, re-check anything whose EPSS jumped by more than 30 points, and treat a finding that newly appears on CISA KEV as a 24-hour fix.

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

npm audit rates the lodash finding higher than the jQuery one. The 3-Signal Method reverses that order.

The jQuery EPSS and KEV values are as of October 4, 2026, and the lodash scores are illustrative. Check CVE-2020-11023's live record for its 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, the GitHub Advisory Database, 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

1. Check KEV status. On CISA KEV: patch within 24 hours.
2. Check the EPSS score.
   • Above 90%: patch within 24 hours.
   • 70–90%: patch within 1 week.
   • 30–70%: patch within 2 weeks.
   • 10–30%: patch within 30 days.
   • Below 10%: routine maintenance.
3. Use CVSS as the tiebreaker. Same EPSS? Higher CVSS goes first.

Sort order: KEV, then EPSS descending, then CVSS descending.

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, work the findings with EPSS of 10% or more that live on a reachable code path or production-exposed service, highest first, on the SLA ladder above (24 hours above 90%, down to 30 days at 10–30%). Then schedule CVSS-only critical findings in runtime code for the next sprint, and 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?

10% (EPSS 0.1) is where the curve turns. Roughly 85% of CVEs sit below it; above that threshold, exploitation is measurably more likely than the base rate. Start with EPSS of 10% or more as the cut-off for your patch queue (within 30 days) and 70% or more 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 at the top of this guide — 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 original EPSS paper (Jacobs et al.) describes the model, not an operational SLA framework. 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 (70% 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 up to 10 packages.

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.

Prioritization only answers what to fix first — for the process of actually getting a fix from scan result to merged patch, see Vulnerability Remediation: Scan to Patched Code.