Your Scanner Found 200 CVEs. Here's What to Actually Do.

You run your dependency scanner. It comes back with 200 CVEs. Half of them are red. Two dozen are labeled "Critical."

So you close the tab.

You're not alone. This is exactly what most developers do — not because they don't care about security, but because the list is too long to act on. Alert fatigue is when developers stop responding to security notifications because the volume of alerts exceeds the team's capacity to respond. When everything is critical, nothing is.

The problem isn't your scanner. The problem is that CVSS severity alone is a poor filter. It tells you how bad a vulnerability could be in theory. It doesn't tell you whether anyone is actually exploiting it.

Here's the data that reframes the whole problem: at least 94% of CVEs are never exploited in the wild — and by stricter datasets, closer to 98%. That means at least 188 of your 200 alerts will never be used in an actual attack. You don't need to fix 200 vulnerabilities. You need to identify the handful that matter — and deprioritize the rest.

That's what the 3-Signal Triage Method (CVSS + EPSS + KEV) does.

Filter by CISA KEV first — any CVE with confirmed active exploitation gets patched within 24 hours, no exceptions. Sort remaining alerts by EPSS score: above 10% probability means fix this week; below 1% is accepted risk unless KEV status changes. Use CVSS only as a tiebreaker between similarly scored items. Applied to a 200-CVE scan, this produces a 3-item fix-today list.

Why Most Teams Have 200 CVEs (and Ignore All of Them)

Modern applications have deep dependency trees. A single package.json can pull in 800+ transitive packages. A requirements.txt project might have 300 indirect dependencies. Each package version can carry multiple known CVEs.

The math adds up fast. And the way most scanners surface results makes it worse.

The default sort order is CVSS score, highest first. This sounds logical until you look at what CVSS actually measures. CVSS was designed to describe the characteristics of a vulnerability — attack vector, complexity, privileges required, impact scope. It asks "how bad could this be?" It was never designed to answer "is anyone actually exploiting this?"

The result is a list where a theoretical remote code execution vulnerability with CVSS 9.8 (that no attacker has ever touched) sits above a CVSS 6.1 prototype pollution flaw that attackers used in 50,000 supply chain attacks last month.

Sorting by CVSS creates the illusion of priority. You're not looking at risk — you're looking at theoretical severity.

Teams respond to this in three ways: patch everything (burns sprint capacity on low-impact work), patch nothing (security debt compounds), or cherry-pick randomly (false sense of progress). None of these make you safer.

The exit from this trap is adding two signals that CVSS doesn't have.

The 3-Signal Triage Method — Step 1: Filter by CISA KEV First

The CISA Known Exploited Vulnerabilities catalog is a list maintained by the US Cybersecurity and Infrastructure Security Agency of CVEs with confirmed, active exploitation in the wild. Every entry represents a vulnerability that real attackers are using against real targets, right now.

KEV is binary: a CVE is either on the list or it isn't. No scoring, no probability — confirmation.

Your rule: Any CVE on CISA KEV gets patched within 24 hours. No discussion.

This sounds aggressive. In practice it's manageable because KEV is a small list. As of 2026, the catalog contains roughly 1,300 entries across all CVEs ever published — out of 355,000+ total CVEs. For a typical dependency scan with 200 findings, you might find 0–3 KEV matches.

Those 0–3 items become your immediate action list. They are the CVEs where real attackers have already demonstrated exploitation capability. The 30-day compliance window your framework gives you is irrelevant here — these are live threats.

For a typical scan:

• 200 CVEs total
• ~3–12 KEV matches → Fix within 24 hours
• ~188–197 remaining → Continue to Step 2

Checking KEV manually means cross-referencing each CVE against the CISA catalog — tedious at scale. GeekWala enriches every scan result with KEV status automatically, so KEV matches surface at the top.

The 3-Signal Triage Method — Step 2: Sort by EPSS Score (>10% = Fix This Week)

EPSS (Exploit Prediction Scoring System) is a machine learning model maintained by FIRST.org that estimates the probability that a given CVE will be exploited in the wild within the next 30 days. It's trained on actual exploitation data from honeypots, threat intel feeds, and OSINT sources.

EPSS outputs a score from 0 to 1 (or 0% to 100%). A score of 0.23 means a 23% probability of exploitation in the next 30 days. Scores update daily as new threat intel flows in.

The distribution is heavily skewed: roughly 80% of all CVEs have an EPSS score below 0.1% (essentially no exploitation signal). The CVEs with EPSS above 10% represent the slice where active exploitation is a real probability in the near term.

Your EPSS thresholds:

For the non-KEV CVEs from your 200-CVE scan:

• ~20–35 may have EPSS >10% → Fix this week or this sprint
• ~160–175 have EPSS <10% → Routine monitoring

EPSS is the most powerful filter you can add to your triage workflow. It directly answers the question CVSS can't: "is anyone actually exploiting this?"

The 3-Signal Triage Method — Step 3: Use CVSS to Break Ties (Not as Primary Signal)

After KEV filtering and EPSS sorting, you'll sometimes have multiple CVEs at similar EPSS scores — say, five CVEs all sitting at 15–20% EPSS. This is where CVSS earns its place: not as the primary sort, but as a tiebreaker.

If two CVEs have EPSS scores of 18% and 19%, but one has CVSS 9.1 and the other CVSS 4.3, patch the CVSS 9.1 first. At similar exploitation probability, higher potential impact tips the balance.

CVSS also has value for the long tail — the 164 low-EPSS CVEs you're monitoring but not actively patching. If a low-EPSS CVE surfaces in your monthly review, high CVSS bumps its priority in your next maintenance sprint.

The decision flow looks like this:

flowchart TD
    A[CVE Found by Scanner] --> B{Is it in CISA KEV?}
    B -- Yes --> C[Fix within 24h]
    B -- No --> D{EPSS score > 10%?}
    D -- Yes --> E[Fix this week / this sprint]
    D -- No --> F{CVSS ≥ 7.0?}
    F -- Yes --> G[Plan next sprint]
    F -- No --> H[Log and monitor]

Building Your Remediation Queue — 200 CVEs to a Real Action List

Here's what the 3-Signal Method looks like applied to a real Node.js project scan with 200 CVEs:

Starting inventory: 200 CVEs
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PASS 1: CISA KEV filter
─────────────────────────────────────────────────
KEV matches found:        3

  CVE-2024-3094  │ xz-utils  │ CVSS 10.0 │ EPSS 78%  │ KEV ✓
  CVE-2021-44228 │ log4j     │ CVSS 10.0 │ EPSS 97%  │ KEV ✓
  CVE-2023-44487 │ nghttp2   │ CVSS 7.5  │ EPSS 62%  │ KEV ✓

→ Action: Fix these 3 within 24 hours

Remaining:               197 CVEs

PASS 2: EPSS > 10% filter
─────────────────────────────────────────────────
High EPSS matches:        8

  CVE-2024-2961  │ glibc     │ CVSS 8.8  │ EPSS 44%  │
  CVE-2024-6387  │ openssh   │ CVSS 8.1  │ EPSS 31%  │
  CVE-2023-36664 │ ghostscript│ CVSS 9.8 │ EPSS 21%  │
  + 5 more in 10–20% EPSS range

→ Action: Fix these 8 this week

Remaining:               189 CVEs

PASS 3: CVSS ≥ 7.0 filter (for sprint planning)
─────────────────────────────────────────────────
High-severity, low-exploitation: 25

→ Action: Plan for next sprint

Remaining:               164 CVEs

PASS 4: The long tail
─────────────────────────────────────────────────
Low CVSS, low EPSS, not KEV:  164

→ Action: Log and monitor (re-check in 30 days)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESULT: 200 CVEs → 3 fix now | 8 fix this week |
        25 plan next sprint | 164 log & monitor

Notice the 25 high-CVSS / low-EPSS CVEs in "plan next sprint." These are the ones CVSS-only triage would have you patching first, urgently. With EPSS context you know they're low exploitation probability — real risk, but not imminent. You schedule them; you don't scramble.

The 3-Signal method doesn't eliminate your backlog. It sequences it correctly.

The EPSS × CVSS priority matrix helps visualize where each vulnerability falls:

High EPSS + High CVSS = Patch Now (top-right quadrant). Low EPSS + Low CVSS = Low Priority (bottom-left). The upper-left (High CVSS, Low EPSS) is where most CVSS-only triages go wrong — treating theoretical severity as imminent risk.

Automating Triage with GeekWala

Running the 3-Signal Method manually — looking up KEV status, fetching EPSS API scores, cross-referencing CVSS — takes hours for a 200-CVE scan. For a team running scans across multiple projects, it doesn't scale.

GeekWala pre-applies the 3-Signal filter automatically:

1. Upload your dependency manifest. Paste your package.json, requirements.txt, pom.xml, Cargo.toml, or any supported lock file. No account required for the first scan. Jump directly to your ecosystem: npm scanner · PyPI scanner · or upload any manifest →

2. Results are sorted by exploitation probability, not CVSS. KEV matches surface at the top with an orange "Actively Exploited" badge. High-EPSS CVEs follow. CVSS 9.8 vulnerabilities with no exploitation signal drop to the bottom where they belong.

3. Each CVE shows all three signals. CVSS score, EPSS percentage, KEV status, and CVSS vector string are displayed inline. You can see at a glance why a finding is prioritized.

4. The "fix now" list is pre-built. GeekWala computes your action tiers automatically — you don't manually bucket CVEs. The dashboard shows your Patch Now, Fix This Week, and Monitor lists without any configuration.

The free tier covers unlimited scans with full 3-Signal enrichment. You don't need a Pro subscription to get past CVSS-only prioritization.

Scan your dependencies now →

What to Tell Your Manager When They Ask "Why Aren't All Vulnerabilities Fixed?"

The 3-Signal Method is also a communication framework. When a non-technical manager sees a dashboard with 200 open CVEs and asks why nothing is getting fixed, you need a response that doesn't sound like an excuse.

Here's a template:

"We currently have 200 CVEs in our dependency scan results. Using exploitation data from CISA and FIRST.org, we've triaged these into action tiers:

3 CVEs are being patched today — these have confirmed active exploitation by threat actors.

8 CVEs are scheduled for this sprint — elevated exploitation probability in the next 30 days based on threat intelligence data.

25 CVEs are in our sprint backlog — high theoretical severity but no current exploitation signal, scheduled for regular maintenance.

164 CVEs are being monitored — low severity and low exploitation probability; they'll be reviewed monthly.

Our patching focus is on actual risk, not on reducing the headline CVE count. Patching the 164 low-risk CVEs would consume two full sprints with no measurable improvement to our security posture."

This reframes the conversation from "we have 200 unfixed vulnerabilities" to "we have a risk-based remediation program." The numbers are the same; the framing is accurate.

Conversational Questions from Reddit and HN

Security engineers ask these in r/devops, r/netsec, and Hacker News threads almost daily. Here are direct answers.

"We have 400 open CVEs and management wants them all closed in 30 days — is that even realistic?"

Closing 400 CVEs in 30 days is almost certainly the wrong goal. Patching every CVE regardless of risk burns sprint capacity on vulnerabilities that no attacker will ever touch. The right conversation with management is: of those 400, how many are in CISA KEV (actively exploited today)? How many have EPSS above 10%? In a typical 400-CVE scan, those numbers are usually under 30 combined. Closing those 30 in 30 days is realistic and actually reduces your risk. Closing the other 370 "on schedule" reduces it by almost nothing.

"My CISO says anything CVSS ≥ 7.0 must be patched within 30 days — does EPSS override that policy?"

EPSS doesn't override your policy — it helps you prioritize within it. If you have 80 CVEs above CVSS 7.0 and 30 days, EPSS tells you which of those 80 to patch on day 1 versus day 29. CVEs that are CVSS 7.0+ and EPSS > 30% get patched immediately; the ones that are CVSS 7.0 and EPSS 0.8% get patched on day 28. You're meeting the compliance window either way; EPSS prevents you from treating them identically.

"We're a two-person team with no dedicated security person — what's the minimum viable triage setup?"

Three steps: (1) run a free GeekWala scan on your main repo weekly, (2) fix anything flagged KEV before your next standup, (3) fix anything above EPSS 10% in your next sprint. That's it. Don't build a spreadsheet, don't triage all 200 CVEs manually. The 3-Signal method exists to make this survivable for teams without security headcount.

"Dependabot flags everything as 'High' or 'Critical' — half our PRs are just dependency bumps. How do we stop the noise?"

Dependabot uses CVSS to classify severity, which is why almost everything looks high — CVSS was never designed as an "alert or not" signal. Run the flagged CVEs through EPSS (GeekWala does this automatically). In our experience, about 80–85% of Dependabot "High/Critical" alerts have EPSS under 5%, meaning no meaningful exploitation activity. Merge those in your monthly maintenance window rather than treating them as emergencies. The 15–20% with real EPSS signal are the ones that deserve a PR this week.

"A CVE we deprioritized as low-EPSS just turned up in a breach report. How do we defend that decision?"

This happens and it's legitimate. EPSS is probabilistic: a 3% EPSS CVE can still be exploited — that's the nature of 3% probability. What you can show is: at the time of your scan, the CVE had low exploitation signal, and your triage process correctly identified higher-signal findings for immediate remediation. Document your triage logic and rescan cadence. If EPSS is fetched fresh on every scan (as GeekWala does), you can show that your next scheduled scan would have caught a significant EPSS spike before it became a breach — and that's the process improvement to focus on, not the original deprioritization.

Do I have to fix every vulnerability?

No — and trying to is the exact behaviour that breaks teams. Research from FIRST, VulnCheck, and Kenna/Cyentia all finds that the large majority of published CVEs are never observed being exploited in the wild — at least 94% on the most generous estimate (FIRST's EPSS research), and 98% or more by Kenna's and VulnCheck's stricter telemetry. Fixing every reported vulnerability treats that ~94% false-positive rate as acceptable and burns the capacity you need for the ~6% that will actually be used against you. Patch the exploited and likely-to-be-exploited findings on a short SLA; everything else goes in normal patch cadence with the rest of your housekeeping work.

Which vulnerabilities can I safely defer?

Anything outside CISA KEV with EPSS below ~0.1 and no reachable attack path in your codebase — those can go in the normal patch cycle alongside regular dependency bumps. That usually covers the vast majority of a 200-CVE list. Do keep rescanning on a daily cadence so a deferred finding that suddenly spikes (PoC drops, malware adopts it) gets promoted automatically. Deferred is not the same as ignored; it just means it doesn't get emergency treatment today.

How do I convince my team not to panic?

Reframe the list in front of them — start from the 200 number and apply the filters on screen: KEV (usually 1–3 items), then EPSS ≥ 0.1 (usually 5–15 items), then everything else. When a team sees the queue drop from 200 red boxes to a 10-item ordered list, the panic dissolves because the work is now finite and prioritized. Back it with the at-least-94% data point, show the alert-fatigue funnel chart on screen, and close the loop with a written SLA per tier so the next scan doesn't re-trigger the panic cycle.

How do I know which CVEs to fix first?

Apply the 3-Signal Method in order: (1) Check CISA KEV — anything on the list gets patched within 24 hours. (2) Sort by EPSS — CVEs above 10% get patched this week. (3) Use CVSS as a tiebreaker for similarly-scored EPSS items. This three-step sequence converts any CVE list into a prioritized action plan.

Is at least 94% of CVEs really never exploited?

Yes — and if anything it understates the case. FIRST.org's EPSS research puts the never-exploited share around 94%, which is the lowest of the credible estimates. Kenna/Cyentia's enterprise telemetry implies closer to 98%, and VulnCheck's public-exploitation tracking closer to 99%. The studies differ because they measure different things — exploitation seen on enterprise networks, evidenced publicly anywhere, or confirmed by a government body — so treat 94% as a conservative floor rather than a consensus point estimate. Either way the conclusion is the same: the vast majority of CVEs are theoretical risks that never materialize into actual attacks.

What if a low-EPSS CVE gets exploited?

EPSS is a probability, not a guarantee. A CVE with 2% EPSS can still be exploited — that's the nature of probabilistic models. The key is re-scanning frequently (daily or weekly) so that EPSS changes get caught quickly. If a CVE's EPSS spikes from 0.02 to 0.6 overnight (which happens when public exploit code drops), your next scan will surface it in the high-priority tier.

What's alert fatigue and how does the 3-Signal Method fix it?

Alert fatigue is when developers stop acting on security notifications because the volume of alerts exceeds the team's capacity to respond. The 3-Signal Method fixes it by collapsing 200 alerts into a 3-item "fix today" list. Instead of overwhelming the team with undifferentiated noise, it surfaces only the alerts that represent real, imminent risk — making it possible to act on every high-priority finding.

Do I need to check three different websites manually?

No. Checking KEV manually (CISA website), EPSS manually (api.first.org), and CVSS manually (NVD) for 200 CVEs would take hours. Tools like GeekWala automate all three lookups and apply the triage logic in seconds. The 3-Signal Method is a framework — the automation is what makes it practical at scale.

Does this approach satisfy compliance requirements like SOC 2 or PCI DSS?

The 3-Signal Method helps you prioritize within compliance requirements, not bypass them. If your compliance framework requires patching all CVSS 7.0+ findings within 30 days, you still do that. The 3-Signal Method tells you which of those findings to patch on day 1 (KEV or high-EPSS) versus day 29 (low-EPSS, no KEV). Compliance sets the floor; risk-based triage sets the priority order.

How is EPSS different from CVSS?

CVSS measures the theoretical characteristics of a vulnerability — attack complexity, privileges required, potential impact. It doesn't use any real-world exploitation data. EPSS is trained on actual exploitation telemetry — observed exploitation in honeypots, threat intel feeds, and exploit databases. CVSS answers "how bad could this be?" EPSS answers "is anyone actually exploiting this?" Both are useful; they measure different things. See our full CVSS vs EPSS comparison for a deeper breakdown.

What's the difference between EPSS and CISA KEV?

EPSS is predictive — it estimates the probability of exploitation in the next 30 days based on observed signals. CISA KEV is confirmatory — it lists CVEs where exploitation has already been confirmed in real-world attacks. KEV is a subset of high-EPSS CVEs, but not all KEV entries have high EPSS (some are older, slower-moving threats), and not all high-EPSS CVEs are on KEV (some are widely exploited but haven't met CISA's formal addition criteria). Both signals are complementary, which is why the 3-Signal Method uses both. Learn more about how CISA KEV works.

Ready to apply the 3-Signal Method to your own dependencies? Run a free scan on GeekWala → — no account required, full EPSS + KEV enrichment included.

For the complete framework with scoring tables and ecosystem-specific examples, see the Vulnerability Prioritization Guide. For a step-by-step remediation workflow after you've triaged your list, see the Vulnerability Remediation Workflow.