Dependabot SLA

The Ultimate Guide to Managing Dependabot Alerts at Scale

The Ultimate Guide to Managing Dependabot Alerts at Scale Open-source dependencies are the building blocks of modern software. A typical enterprise applicati...

By InstaSLA Superadmin · Published · 11 min read

Dependabot SLAAlert ownershipGitHub security
The Ultimate Guide to Managing Dependabot Alerts at Scale

The Ultimate Guide to Managing Dependabot Alerts at Scale

Open-source dependencies are the building blocks of modern software. A typical enterprise application might directly import a few dozen libraries, but once transitive dependencies are counted, that number balloons — Black Duck's 2025 Open Source Security and Risk Analysis found the average commercial codebase now contains 911 open source components, and Endor Labs has reported that roughly 95% of known vulnerabilities in a typical application live in transitive dependencies rather than the ones a team chose directly. That reach is exactly what makes open source so productive, and exactly what makes it such a large attack surface.

For teams on GitHub, Dependabot is usually the first line of defense: it scans repositories, flags outdated or vulnerable dependencies, and opens pull requests to patch them. For a small team with a handful of repos, that's often enough. For an organization running hundreds or thousands of repositories, Dependabot's default behavior can turn into a firehose — and without a deliberate strategy, the tool built to keep you secure ends up training developers to ignore it.

This guide covers why that happens, current data on how bad the underlying problem has gotten, and the concrete configuration and process changes that keep Dependabot useful at scale.

Why Dependabot Alone Breaks Down at Scale

1. Alert fatigue is a measurable, not just anecdotal, problem

Dependabot works at the package level: it flags any dependency with a known CVE, regardless of whether your application actually executes the vulnerable code path. Independent reachability-analysis vendors have measured just how much of that flagged risk is real. Coana has reported that in most projects, more than 80% of flagged vulnerabilities are not actually reachable from the application's entry points, and Semgrep's research has found that in some codebases upwards of 90% of findings can be marked unreachable once function-level analysis is applied. That doesn't mean those alerts are worthless — reachability tools themselves note that "no path found" isn't the same as "not exploitable," since dynamic behavior and unanalyzed edge cases can hide real risk. But it does mean that treating every package-level alert as equally urgent guarantees fatigue.

The cost of getting this wrong is rising. The 2025 Verizon Data Breach Investigations Report found vulnerability exploitation grew 34% year over year, and VulnCheck's 1H-2025 Exploit Intelligence Report found that roughly a third of exploits now appear before or on the same day a CVE is publicly disclosed. Attackers are moving faster; teams buried in low-value alerts have less room to notice the ones that matter.

2. The "Dependabot graveyard" of abandoned PRs

Automation only works if it drives action. Large orgs commonly end up with repositories full of stale, unmerged Dependabot PRs, for reasons that are individually rational: fear that a minor bump breaks something in production, lack of context about why a specific CVE matters, and feature deadlines that simply outrank invisible maintenance work. Left open long enough, these PRs drift out of sync with the base branch and start generating merge conflicts, which further discourages anyone from touching them.

3. Misaligned prioritization from CVSS alone

By default, Dependabot severity is driven by CVSS, which measures theoretical technical severity, not real-world exploitation likelihood. That gap is well documented: FIRST's Exploit Prediction Scoring System (EPSS), now on version 4 (released March 2025), models the probability a given CVE will actually be exploited in the next 30 days, and its authors have shown that patching every CVSS 7+ finding means patching roughly half of all known CVEs to catch about 75% of real exploitation — for a 6% efficiency rate. EPSS reaches comparable exploit coverage by prioritizing a much smaller slice of CVEs, closer to 47% efficiency. Security researchers have documented concrete cases of the mismatch: a Linux kernel CVE rated "High" (CVSS 7.0) with an EPSS score near 0.04% because exploitation requires local access and unusual conditions, versus a critical PHP CVE that reached roughly 94% EPSS days before NVD had even published a CVSS score for it. Sonatype's 2026 State of the Software Supply Chain report adds another wrinkle: two-thirds of open-source CVEs in 2025 weren't assigned a CVSS score by NVD at all, so CVSS-only triage silently drops a large share of known vulnerabilities.

The State of the Threat, in Current Numbers

It's worth grounding "why does this matter" in current data rather than general anxiety:

  • Sonatype identified more than 454,600 new malicious open-source packages in 2025 alone, bringing the cumulative total it has catalogued across npm, PyPI, Maven Central, NuGet, and Hugging Face to over 1.2 million. Over 99% of that malware showed up on npm.
  • September 2025's Shai-Hulud campaign was the first documented self-replicating npm malware — a worm that used stolen maintainer credentials to publish poisoned updates and compromised more than 500 packages within days, spreading autonomously rather than through one-off malicious uploads.
  • Widely-used npm packages have been directly targeted: a hijack campaign in 2025 compromised chalk and debug, packages with a combined 2 billion+ weekly downloads, by compromising legitimate maintainer accounts rather than typosquatting.
  • Black Duck's 2025 OSSRA report found 86% of commercial codebases contain at least one open-source vulnerability, 81% have at least one high- or critical-severity finding, and 90% of codebases include components more than four years out of date.
  • IBM's 2025 Cost of a Data Breach Report put the global average breach cost at $4.44 million, and separately, breaches with a supply-chain component take meaningfully longer to identify and contain than the average incident, which drives cost higher still.

None of this means every team needs to panic-patch everything. It means the noise Dependabot generates is sitting on top of a genuinely expanding attack surface, which is exactly why triage strategy matters more than raw alert volume.

Core Principles for Managing This at Scale

Classify repositories by actual exposure, not just existence. Not every repo carries the same risk. A workable starting tier system:

  • Tier 1 — internet-facing, handles sensitive data, high compliance burden
  • Tier 2 — internal services with limited exposure
  • Tier 3 — deprecated code, sandboxes, experiments

Apply strict Dependabot SLAs to Tier 1 and much looser (or disabled) policies to Tier 3. Without this split, teams spend real time patching CVSS-critical bugs in a Jest config that nothing depends on, while a medium-severity finding in an internet-facing auth service sits untouched.

Assign clear ownership and write real SLAs. An alert with no named owner doesn't get fixed. Decide explicitly whether triage belongs to the product squad, a centralized platform team, or AppSec, and set internal targets by severity — for example, triage critical findings within 24 hours and ship a fix within days, while medium/low findings roll into normal sprint planning. GitHub's own tooling can help enforce this once ownership is defined (see auto-triage rules below).

Invest in CI/CD confidence before you invest in automation. If every Dependabot PR requires a human to manually re-verify the whole application, the process scales linearly with headcount — which is to say, it doesn't scale. Strong test coverage and CI pipelines are what let you safely auto-merge low-risk updates instead of just generating more review backlog.

Dependabot Configuration: What's Actually Available Today

Tune dependabot.yml

  • open-pull-requests-limit caps how many PRs Dependabot keeps open at once (default is 5) — lowering it on noisy repos forces the existing queue to get addressed before new PRs pile on.
  • schedule.interval controls scan cadence per ecosystem; matching this to your team's actual review rhythm (daily for security, weekly/monthly for routine version bumps) cuts disruption.
  • allow / ignore directives let you exclude specific packages — for example, ignoring major-version bumps for a framework that needs coordinated manual testing, while still letting Dependabot handle its patch-level security fixes.

Grouped security updates (generally available)

GitHub's grouped security updates feature is fully generally available, not experimental. When enabled at the repo or organization level, Dependabot collects all available security fixes for a given package ecosystem and tries to raise a single pull request covering as many of them as possible, instead of one PR per vulnerable package. It requires the dependency graph, Dependabot alerts, and Dependabot security updates to all be turned on first. You can also define custom groups in dependabot.yml — by package name pattern, dependency type, or SemVer level — for finer control than the org-wide default. Real-world numbers back up the impact: one documented case of a Node.js monorepo with ~180 npm packages went from 30+ Dependabot PRs a week to roughly 3–6 grouped PRs weekly after enabling grouping and auto-merge on passing CI.

Auto-triage rules

GitHub now offers Dependabot auto-triage rules (in public preview at the time of writing), which let admins automatically dismiss, snooze, or selectively open PRs for alerts based on metadata like severity, package name, or CWE — evaluated before notifications go out, which directly reduces noise rather than just hiding it after the fact. GitHub ships a preset rule that auto-dismisses low-impact findings in npm packages scoped to development only, and organizations can layer enforced org-level rules on top of repo-level ones. This is the closest built-in equivalent to the reachability-based triage described above, though it works on static metadata rather than actual code-path analysis.

Dependency Review in pull requests

The native "Dependency Review" GitHub Action scans incoming PRs for dependency changes and can block a merge that would introduce a known-vulnerable version. This stops new debt from entering the codebase in the first place, so Dependabot's ongoing scans can focus on legacy issues and newly-disclosed CVEs rather than re-litigating things a PR check could have caught.

Blend CVSS with EPSS and reachability where you can

Since CVSS alone both over- and under-prioritizes (see above), pairing it with an EPSS score and, where available, a reachability signal from an SCA tool gives a materially better picture of what's actually urgent. None of this needs to be exotic — even manually cross-checking your highest-CVSS open alerts against the public EPSS score (FIRST publishes daily updated scores via a free API) catches cases where a "Critical" CVSS finding has near-zero real-world exploitation probability, or conversely where a "Medium" finding is being actively exploited in the wild.

Handling Organization-Wide Incidents (the "Fix Campaign" Problem)

The pattern above works well repo by repo. It breaks down at true incident scale — a critical zero-day in a widely-used library like Log4j or a heavily-imported npm package like Express. Dependabot operates per-repository, so if 500 microservices depend on the affected package, Dependabot dutifully opens 500 separate PRs, and now dozens of developers across time zones are each independently expected to notice, review, and merge one.

That gap is why a growing category of tooling — application security posture management (ASPM) platforms and vulnerability management layers that sit on top of Dependabot and similar scanners — has emerged specifically to group alerts by vulnerability rather than by repository. Rather than tracking 500 discrete PRs, a security or platform team gets a single view of every repository affected by a given CVE, can push bulk PR generation or synchronized merges where CI is green, and can track a single Mean Time to Remediate (MTTR) figure against a compliance deadline instead of chasing status updates in Slack. If you're evaluating tools in this space, look for three specific capabilities: cross-repository grouping by CVE (not just by repo), automated SLA/MTTR tracking with escalation, and the ability to scope a remediation push by business unit or asset tier rather than treating every affected repo identically. This is a real and increasingly common operational pattern — it isn't tied to any single vendor, and several ASPM and SCA platforms (Endor Labs, Snyk, Black Duck, and others among them) offer some version of it, so it's worth comparing based on which reachability/exploitability signals they use and whether they integrate cleanly with your existing Dependabot configuration rather than replacing it outright.

Metrics That Actually Tell You Whether This Is Working

  • Mean Time to Remediate (MTTR), segmented by severity — critical MTTR and low MTTR are different problems and should be tracked separately.
  • PR merge rate vs. closure/ignore rate — a persistently low merge rate is usually a sign of alert fatigue, misaligned severity, or CI/CD that developers don't trust enough to auto-merge against.
  • SLA breach rate — how often vulnerabilities stay open past your internal deadlines; this is the number that turns into executive-level risk visibility.
  • Dismissal / false-positive rate — if developers are frequently hand-dismissing alerts as not applicable, that's a signal to tighten auto-triage rules and repository tier classifications rather than to keep asking developers to do it manually every time.

Treating these with the same rigor as uptime or latency metrics is what turns "we run Dependabot" into an actual vulnerability management program.

The Bottom Line

Left on autopilot, Dependabot's default settings scale linearly with the number of repositories you have — which, for any organization past a few dozen repos, means it scales into unmanageable noise. The fix isn't turning it off; it's layering real configuration (grouping, auto-triage, dependency review), risk-aware prioritization (CVSS plus EPSS plus reachability where available), clear ownership and SLAs, and — for organization-wide incidents — some form of cross-repository campaign tracking on top of it. None of that eliminates the underlying growth in supply-chain risk the 2025–2026 data shows, but it's what determines whether your team is actually addressing that risk or just generating pull requests nobody reads.

Sources

Related articles