Prioritizing Dependabot Alerts Without the Noise
Dependabot does its job well: it surfaces vulnerabilities in your dependency tree, plenty of them. The hard part is figuring out which alerts actually deserve your attention, and which can wait. Careless triage means burning hours on low-impact findings while real risks sit unpatched.
The gap between "critical" and "exploited" is wider than many teams assume. Pairing the Exploit Prediction Scoring System (EPSS) with repository context gives you a practical way to rank alerts, automate the obvious ones, and focus human effort where it counts.
Why severity scores alone mislead
Open source now powers 96% of modern applications, making the supply chain an attractive target for attackers. Thousands of Common Vulnerabilities and Exposures (CVEs) surface each year, and each one arrives with a severity rating. Yet severity is only half the story.
CVSS describes how damaging an exploit could be. EPSS describes the probability that a vulnerability will actually be exploited in the wild within the next 30 days. A severe vulnerability that nobody is actively exploiting is a different problem from one that attackers are already probing. Both numbers matter, but only one tells you what is likely to happen next.
A two-factor approach to triage
Start by reading EPSS and CVSS together, not in isolation. A vulnerability with an EPSS of 85% and a CVSS of 9.8 should take clear priority over one with an EPSS of 0.5% and a CVSS of 9.0. In both cases the CVSS is screaming "critical," but the second one isn't showing up in real-world attack patterns.
Vulnerability likelihood and impact are only part of the equation. Repository context matters just as much. Your public-facing payment processing service is not the same risk profile as an internal test utility. To codify that distinction, use custom repository properties within GitHub. These let you tag repos with metadata like compliance frameworks, data sensitivity, or project purpose. Once that classification exists, you can consistently separate production code that feeds real users and sensitive data from lower-stakes repos that don't warrant the same urgency.
Define response SLAs by risk level
Once you have likelihood, impact, and repository context, set concrete response timelines.
| EPSS ↓ / CVSS → | Low | Medium | High |
|---|---|---|---|
| Low | ✅ When convenient | ⏳ Next sprint | ⚠️ Fix Soon |
| Medium | ⏳ Next sprint | ⚠️ Fix soon | 🔥 Fix soon |
| High | ⚠️ Fix Soon | 🔥 Fix soon | 🚨 Fix first |
A high-EPSS, high-CVSS alert in a payment library demands immediate mitigation. A low-EPSS, low-CVSS finding in an unused testing utility can wait weeks. Applying identical urgency to every alert creates alert fatigue and pulls developers off meaningful work. A clear matrix gives teams a defensible reason to act — or to defer.
Scaling triage with auto-triage rules
For larger organizations, auto-triage rules in Dependabot let you automate consistent decisions across teams and repositories. Rules can key off severity, EPSS, scope, package name, CVE, ecosystem, and manifest location to auto-dismiss or reopen alerts. This is useful for filtering known false positives, snoozing alerts until a patch exists, and giving developers visibility into why an alert was dismissed.
The presets that come with auto-triage rules (auto-dismissal of likely false positives) are free for all repositories. Custom rules are free on public repos and available to private repos that have GitHub Advanced Security.
Rules apply to existing and future alerts alike, which means the automation compounds over time. Fewer irrelevant alerts reach developers, and the ones that do arrive with more signal.
The payoff of better prioritization
The numbers back up a probability-driven workflow. The Cyentia EPSS study shows that teams can cover 87% of actively exploited vulnerabilities by focusing on just 10% of them. That’s an 83% reduction in remediation effort versus a traditional CVSS-only queue.
There's a collaboration benefit as well. When security teams can articulate why an alert is urgent — or not — developers start to trust the process. Clear reasoning reduces friction between security and engineering, and turns alert triage into a shared workflow rather than a source of constant interruption.
Where to start
- Enable Dependabot alerts and security updates in your repository settings. It’s the baseline data feed for everything else.
- Set up auto-triage rules. Pair curated presets like false-positive dismissal with custom rules based on severity, scope, package name, and other filtering criteria.
- Define prioritization criteria for your projects. Combinations of EPSS, CVSS, and custom repository properties will feed a risk matrix specific to your environment.
- Check your remediation process before acting on high-priority alerts. Verify the issue is real and know who to bring in for mitigation.
The point of this system is simpler than it sounds: treat alerts with exploitation likelihood and real-world impact as urgent, automate the rest, and stop letting generic severity scores dictate your roadmap.



