Q: How does this compare with GitHub's own prioritization?

GitHub's default prioritization is CVSS-based — Critical > High > Medium > Low — with some additional signals layered in over time (GitHub has experimented with exploit-path hints and repository-relevance cues, so check their current docs before locking in a workflow). The gap is that CVSS alone mis-orders the queue on real exploitation probability: a GitHub "Critical" without active exploitation often ranks above a "High" with a public PoC. EPSS-based prioritization flips that — the Dependabot UI continues to group by severity, but your team works the list EPSS-first. The full prioritization pillar walks through the 3-Signal method that generalises this beyond Dependabot.

Question 1

Can I filter Dependabot alerts by EPSS directly?

Accepted Answer

Not inside GitHub's UI — Dependabot ranks alerts by CVSS severity and the security tab does not expose EPSS as a filter or sort key. You have three practical options: cross-reference each CVE against the FIRST.org EPSS API manually (feasible for small repos), script a nightly enrichment that decorates each open alert with its current EPSS score, or use a scanner that layers EPSS on top of your GitHub feed automatically. Whichever path you pick, the sort order stops being "severity" and starts being "probability × severity", which is the actual risk signal.

Question 2

What EPSS threshold should I use for auto-merge?

Accepted Answer

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.

Question 3

How does this compare with GitHub's own prioritization?

Accepted Answer

GitHub's default prioritization is CVSS-based — Critical > High > Medium > Low — with some additional signals layered in over time (GitHub has experimented with exploit-path hints and repository-relevance cues, so check their current docs before locking in a workflow). The gap is that CVSS alone mis-orders the queue on real exploitation probability: a GitHub "Critical" without active exploitation often ranks above a "High" with a public PoC. EPSS-based prioritization flips that — the Dependabot UI continues to group by severity, but your team works the list EPSS-first. The full prioritization pillar walks through the 3-Signal method that generalises this beyond Dependabot.

Question 4

Can I use EPSS with Dependabot directly?

Accepted Answer

Not natively. Dependabot doesn't support EPSS scores in its alert interface or API. You'd need to cross-reference each CVE manually using the EPSS API. GeekWala automates this — import your GitHub repository and every vulnerability is enriched with EPSS and KEV data automatically.

Question 5

Should I disable Dependabot if I use GeekWala?

Accepted Answer

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). They complement each other.

Question 6

How often does EPSS data update?

Accepted Answer

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.