EPSS Score Distribution across ~230,000 CVEs. About 85% score below 0.1 — the noise floor that makes EPSS-based triage possible.
The average active GitHub repository has 67 open Dependabot alerts. Most developers either ignore them all or waste time on low-risk CVEs. The 3-Signal Triage Method — combining CVSS severity with EPSS exploitation probability and CISA KEV status — cuts your actionable list from hundreds to single digits.
Here's how to apply it to your Dependabot backlog today.
The Dependabot Problem
Dependabot does three things well: it detects known CVEs in your dependency tree, it opens pull requests to bump affected packages, and — since February 2025 — it shows an EPSS score on every alert and lets you build auto-triage rules that act on it. What it still doesn't do is tell you which of those CVEs are being actively exploited right now (no CISA KEV signal, anywhere in the product) or give you one ranked list across every repo and ecosystem you own.
By default, Dependabot still ranks alerts by CVSS severity in the security tab — Critical, High, Medium, Low — and EPSS shows up as a column and a rule-builder criterion, not the default sort. CVSS measures theoretical worst-case impact. It asks "how bad could this be?" but never "is anyone actually exploiting this?" EPSS answers that second question per-CVE; it still doesn't tell you which alerts are confirmed under active attack (that's KEV's job), and on its own it can't compare a Critical Node.js alert in one repo against a Medium Python alert in another.
The result is predictable if you haven't wired up EPSS sorting and KEV cross-referencing yourself. Your alert list looks like a wall of red and orange. Everything appears urgent. So you either:
- Patch everything — burning sprints on version bumps that don't reduce real risk
- Ignore everything — because if everything is critical, nothing is
- Cherry-pick randomly — fixing whatever's at the top of the list
None of these approaches make you safer. Here's what does: layering the KEV signal Dependabot doesn't have on top of the EPSS signal it now does, and doing it across every repo at once.
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 94% of your Dependabot alerts are noise — real CVEs, technically valid, but never weaponized by attackers. The challenge is figuring out which few percent to care about.
What Dependabot's Native EPSS Auto-Triage Does
GitHub GA'd EPSS scores inside Dependabot alerts on February 19, 2025. Every alert in the security tab now shows an EPSS percentage and percentile alongside CVSS, and you can filter the alert list by EPSS the same way you'd filter by severity.
On top of that, Dependabot auto-triage rules let you write custom rules against EPSS Score as one of the match criteria — alongside CVE ID, CWE, ecosystem, package name, dependency scope, and severity. That means you can build a rule that mirrors this article's own threshold — dismiss or snooze low-EPSS alerts, or flag anything at EPSS ≥ 0.1 for review — directly in GitHub. Organization owners can define a rule once and enforce it across every public and private repo in the org. For public repos, custom rules are free; for private or internal repos, they require GitHub Code Security.
In short: if you've enabled Dependabot and haven't touched auto-triage, you already have the EPSS number GitHub is showing you. That's a real capability, and it's the reason the rest of this guide is a layer on top of Dependabot, not a replacement for it.
What It Still Doesn't Do
Four gaps remain once you've turned on native EPSS and built a rule or two:
- No CISA KEV cross-reference. Neither the Dependabot alert view, the auto-triage rule criteria, nor the changelog entry for the EPSS launch mention CISA's Known Exploited Vulnerabilities catalog anywhere. EPSS is a prediction of exploitation probability; KEV is confirmation that a CVE is under active attack right now. Dependabot's EPSS column tells you a CVE is likely to be exploited — it can't tell you a CVE already has been. A rule built only on EPSS will still miss a lower-EPSS CVE that KEV has confirmed is being actively weaponized, because there's no KEV field to match against.
- No cross-repo, cross-ecosystem ranked view. Org-level auto-triage rules apply the same rule to every repo in the org — that's useful for consistency, but it's not a consolidated list. Each repo's Dependabot alerts still live in that repo's own Security tab. If you own 40 repos across npm, PyPI, and Go, there's no single Dependabot view that ranks "CVE-2025-XXXX in repo A" against "CVE-2025-YYYY in repo B" by EPSS or KEV — you're still opening 40 tabs.
- Custom rules are gated on GitHub Code Security for private repos. The EPSS score is visible on any Dependabot alert, but building the EPSS-threshold rule that acts on it — the thing that actually cuts your list down automatically — requires a paid plan the moment your repos aren't public.
- Direct EPSS API access still hits FIRST.org's rate limit. Dependabot's own alert view and REST API no longer need it — the score is already attached to each alert. But the moment you need EPSS for something Dependabot doesn't cover (a CVE outside GitHub's advisory database, a non-GitHub-hosted repo, or a CI gate that checks hundreds of dependencies per run across a whole portfolio), you're back to calling the FIRST.org EPSS API directly, which caps unauthenticated requests at 1,000/minute before returning
429 Too many requests(see FIRST's API rate-limit docs). Fine for a handful of lookups; it starts to bite in a CI matrix running that query per-build across many repos.
These are the gaps GeekWala fills — not "Dependabot has no EPSS," which stopped being true in February 2025. See the full Dependabot vs. GeekWala comparison for a feature-by-feature breakdown.
Updated Triage Strategy: Layer GeekWala on Top of Native Dependabot EPSS
The 3-Signal Triage Method below still applies — it's just that Step 2 (EPSS) is now something Dependabot can partially do for you. Use Dependabot's native EPSS column and auto-triage rules for the first pass inside a single repo; use GeekWala for the KEV cross-reference and the cross-repo rollup Dependabot doesn't have. Concretely:
- Turn on Dependabot's EPSS column and, if you're on GitHub Code Security, build an auto-triage rule that snoozes anything below your EPSS floor per repo.
- Import the same repos into GeekWala (or paste manifests directly) to get every remaining alert cross-referenced against CISA KEV and rolled up into one list across every repo and ecosystem.
- Work the combined list: KEV matches first, then EPSS ≥ 0.1, then the rest — exactly the 3-Signal Triage Method below, now applied across your whole portfolio instead of one repo at a time.
The 3-Signal Triage Method Applied to Dependabot Alerts
The 3-Signal Triage Method was designed for exactly this problem. Instead of relying on CVSS alone, it layers three orthogonal data sources:
Step 1: Filter by CISA KEV First
CISA's Known Exploited Vulnerabilities catalog is a government-curated list of CVEs with confirmed, active exploitation. If a vulnerability is on KEV, attackers are using it right now against real systems.
Rule: If it's on KEV, fix it today. No discussion, no risk assessment, no sprint planning. These are confirmed threats.
Check your Dependabot alerts against the KEV catalog. In most repositories, you'll find 0-2 KEV matches. Those are your highest-priority items — our 12-month audit of KEV against open-source dependencies found only 0.19% of newly published CVEs across 8 ecosystems reach KEV at all, so a handful of matches in a 200-alert repo is the expected shape, not a sign you missed something.
Step 2: Check EPSS Probability
EPSS (Exploit Prediction Scoring System) is a machine learning model that predicts the probability a CVE will be exploited in the next 30 days. It outputs a score from 0% to 100%.
For your remaining Dependabot alerts (the non-KEV ones), apply these thresholds:
- EPSS > 10%: High priority — this CVE has strong exploitation signals. Fix this week.
- EPSS 1-10%: Medium priority — schedule for your next maintenance cycle.
- EPSS < 1%: Low priority — deprioritize. This CVE is unlikely to be weaponized.
This is where most of the noise disappears. The majority of "Critical" CVSS alerts in Dependabot have EPSS scores below 1%.
Step 3: Use CVSS as a Tiebreaker
Within each EPSS tier, use CVSS to break ties. Between two CVEs with similar EPSS scores, patch the higher-CVSS one first — if it does get exploited, the blast radius is larger.
But CVSS never overrides EPSS or KEV. A CVSS 9.8 with 0.1% EPSS is less urgent than a CVSS 5.0 with 15% EPSS.
The 3-Signal Triage Decision Flow
200 Dependabot Alerts
│
▼
┌─────────────────┐
│ On CISA KEV? │──── YES ──→ FIX TODAY (0-2 alerts)
└────────┬────────┘
│ NO
▼
┌─────────────────┐
│ EPSS > 10%? │──── YES ──→ FIX THIS WEEK (1-5 alerts)
└────────┬────────┘
│ NO
▼
┌─────────────────┐
│ EPSS 1-10%? │──── YES ──→ SCHEDULE FOR NEXT CYCLE (~10-20 alerts)
└────────┬────────┘
│ NO
▼
EPSS < 1%
DEPRIORITIZE (~170+ alerts)
Review monthly or when EPSS changes
Worked Example: 200 Alerts to 3 Patches
Let's walk through a realistic scenario. You open your GitHub repository and see 200 Dependabot alerts:
Alert Breakdown by CVSS Severity
─────────────────────────────────
Critical (9.0-10.0): 18 alerts
High (7.0-8.9): 54 alerts
Medium (4.0-6.9): 89 alerts
Low (0.1-3.9): 39 alerts
─────────────────────────────────
Total: 200 alerts
Dependabot says you have 72 Critical or High alerts. Conventional wisdom says: fix those first. The 3-Signal Triage Method says: check the data.
Step 1 — KEV filter: Cross-reference all 200 alerts against the CISA KEV catalog. Result: 1 match — a medium-severity prototype pollution CVE in a transitive dependency. CVSS 6.1, but it's on KEV because attackers are actively using it in supply chain attacks.
- Alert #1: CVE-2025-XXXX — lodash prototype pollution (CVSS 6.1, EPSS 67%, KEV: YES) → Fix today
Step 2 — EPSS filter: For the remaining 199 alerts, check EPSS scores. Of the 18 "Critical" CVSS alerts, 15 have EPSS scores below 0.5%. They're theoretically severe but nobody is exploiting them.
Two alerts have elevated EPSS:
- Alert #2: CVE-2025-YYYY — express path traversal (CVSS 8.1, EPSS 23%) → Fix this week
- Alert #3: CVE-2025-ZZZZ — axios SSRF in redirect handling (CVSS 7.5, EPSS 12%) → Fix this week
Result: From 200 alerts, 3 need immediate action. The other 197 can wait for your regular maintenance cycle or be deprioritized entirely.
Those 15 "Critical" CVSS alerts that Dependabot flagged red? EPSS says they're below 0.5% exploitation probability. They're not emergencies — they're noise.
How GeekWala Automates This
You can now get EPSS scores per-alert from Dependabot itself, or build an auto-triage rule against them. What you can't get from GitHub is a KEV cross-reference or a single ranked list spanning every repo you own. Wiring that up manually — looking up each CVE in the KEV catalog and reconciling scores across dozens of repos — takes hours.
GeekWala does it in seconds. Import your GitHub repository — or paste your package.json, requirements.txt, or any other dependency manifest — and GeekWala enriches every finding with:
- EPSS scores refreshed daily server-side, so your CI never calls the FIRST.org API directly or trips its rate limit
- CISA KEV status flagging any actively exploited vulnerabilities — the signal Dependabot's native EPSS still doesn't carry
- CVSS severity as context, not as the primary sort order
All of it rolled up into one list across every repo and ecosystem you scan, sorted by exploitation probability by default, not CVSS severity. The vulnerabilities that attackers are actually targeting float to the top. The theoretical risks drop to the bottom.
No more staring at a wall of red alerts wondering which ones matter.
Scan your dependencies now — free, no account required →
Can I filter Dependabot alerts by EPSS directly?
Yes, as of the February 2025 GA — the security tab shows an EPSS score and percentile on every alert (and it's in the REST API too, no separate lookup needed), and you can filter by it. You can also build an auto-triage rule that matches on EPSS Score to auto-dismiss or snooze alerts below your threshold — free on public repos, gated behind GitHub Code Security on private ones. What that filter still can't do: cross-reference CISA KEV, or show you alerts from more than one repo at a time. For KEV, cross-reference each CVE against the catalog yourself; for a cross-repo view, you'd need to pull each repo's alerts from the Dependabot REST API and aggregate them yourself; and for EPSS on a CVE outside GitHub's advisory database entirely, you're back to calling the FIRST.org EPSS API directly. Or use a scanner that rolls all three up across your whole portfolio automatically.
What EPSS threshold should I use for auto-merge?
Use two thresholds, not one. For auto-merge, only green-light Dependabot PRs when EPSS < 0.01 (bottom percentile, effectively noise) AND tests pass AND the change is patch-level, not major. For gated auto-merge with a reviewer ping, extend to EPSS < 0.1 with passing tests. Anything EPSS ≥ 0.1 — and definitely anything in CISA KEV — should go to a human review queue regardless of test status, because those are the alerts where a botched version bump would be expensive and a delayed merge is expensive too. Tune the thresholds from there based on observed false-positive rate in your repo.
How does this compare with GitHub's own prioritization?
GitHub's default sort is still CVSS-based — Critical > High > Medium > Low — but since February 2025 every alert also carries an EPSS score, and auto-triage rules can act on that EPSS score directly. The gap that's left is CVSS-and-EPSS still mis-order the queue against confirmed exploitation: a GitHub "Critical" with middling EPSS and no KEV match can outrank a "Medium" that CISA has confirmed is under active attack, because Dependabot has no KEV field to sort or filter on. It's also still one repo at a time — there's no native view that ranks alerts across your whole GitHub org. The full prioritization pillar walks through the 3-Signal method that adds both of those signals back in, beyond Dependabot.
Can I use EPSS with Dependabot directly?
Yes — natively, since February 2025. Every Dependabot alert shows an EPSS score, and the REST API returns it in the security_advisory.epss field, so you can pull it into your own tooling without calling the FIRST.org API separately. What Dependabot's EPSS still won't give you is a CISA KEV match or a rollup across repos — GeekWala adds both, and enriches every vulnerability with EPSS and KEV data automatically whether or not you've turned on GitHub's native EPSS.
Should I disable Dependabot if I use GeekWala?
No. Keep Dependabot enabled. It provides automated pull requests for version bumps, which is valuable regardless of prioritization. Use Dependabot for the remediation (automated PRs) and GeekWala for the prioritization (which PRs to merge first) — see why teams run both together instead of picking one. They complement each other.
How often does EPSS data update?
EPSS scores are recalculated daily by the FIRST.org EPSS SIG. A CVE with low EPSS today can spike tomorrow if exploit code is published or attackers begin targeting it. GeekWala refreshes EPSS data daily so your prioritization stays current. Learn more in our EPSS deep dive.
Dealing with more than just Dependabot? See What to Do When Your Scanner Finds 200 CVEs for the full 3-Signal triage playbook applied to any scanner output.
