# GitHub's Dependabot Now Waits Three Days Before Pulling New Packages — And That's the Point
When a poisoned npm package lands in a registry, the clock starts. Attackers know it. The package gets pulled in minutes or hours once someone catches it, but in that window, automated tooling like Dependabot can already have it queued in a PR — maybe even merged. GitHub just started fighting that clock with a clock of its own.
On July 27, GitHub announced a default three-day cooldown for Dependabot version updates. Before the tool opens a pull request proposing a dependency bump, it now waits 72 hours after a package release hits the registry. Security updates — actual CVE patches — still land immediately. But routine "keep your dependencies current" churn now has a built-in pause baked in.
It sounds like a small operational tweak. It's actually a meaningful architectural shift in how the industry thinks about automated dependency management.
## The Attack It's Designed to Stop
The threat model here is narrow and specific, and GitHub says so plainly: "A cooldown is built for a specific pattern: a malicious version that ships, spreads, and gets caught quickly."
Think about how these attacks work in practice. A threat actor compromises a maintainer account or a publishing token. They push a trojanized release — version 2.4.1 of some popular utility package. For the next few hours or days, that version sits on npm or PyPI or wherever, looking legitimate. Dependabot, running on schedule, sees a new version and helpfully opens PRs across thousands of downstream repos. Some of those PRs get auto-merged. Some get reviewed and merged by developers who glance at the diff, see a version bump, and approve. By the time the registry yanks the malicious release, it's in production pipelines that haven't rotated it out yet.
Three days doesn't close that window completely, but it dramatically narrows it. Most poisoned-package campaigns are caught and pulled within hours. The malicious version of a package rarely survives 72 hours without someone flagging it. GitHub is essentially saying: let the ecosystem do its job first, then send the PR.
The configurable floor matters here. Teams can extend the cooldown beyond three days if they run particularly conservative change windows, or shorten it if they have strong internal review processes. The default is an opinionated recommendation, not a mandate.
## What the Cooldown Won't Save You From
Give GitHub credit for being direct about the limits. The company explicitly names three attack patterns this doesn't touch:
Long-game backdoors. XZ Utils (2024) is the canonical case. Jia Tan spent nearly two years building trust as a maintainer before slipping a backdoor into the compression library. A three-day cooldown wouldn't have changed anything. The malicious code was in an official release with a legitimate version number. It would have sailed right past the timer.
Maintainer sabotage. The Faker.js and Colors incidents — where a legitimate maintainer deliberately broke their own widely-used packages — are similar. Once the maintainer account is the attacker, time doesn't help.
Compromised build systems. If an attacker gets into the CI pipeline that *produces* the release, the resulting artifact looks completely clean to any downstream tooling, including Dependabot's cooldown logic.
GitHub's honest accounting of these limits makes the announcement more credible, not less. They're describing a specific control for a specific threat class. That's how security tooling should be documented.
## An Industry Converging on Time as a Control
What's actually worth noticing is that GitHub isn't alone. This three-day default lands in the middle of a broader industry move toward time-based friction as a supply chain defense.
Microsoft's VS Code extensions now have similar controls. npm, pnpm, and Yarn have cooldown features. Ruby's gem ecosystem has experimented with publication delays. Bun's package management added equivalent logic. And this week, PyPI announced it will block maintainers from adding new files to existing releases after 14 days — explicitly to prevent attackers from poisoning old, trusted releases after compromising a token.
The pattern is consistent: every major package ecosystem is adding time as a circuit breaker between publication and adoption. This is a coordinated (if informal) shift in the industry's mental model. Speed used to be an unqualified virtue in package management. Now there's recognition that frictionless, instant propagation is itself a security risk.
## What Defenders Should Actually Do
The cooldown is one layer, not a strategy. GitHub lists the others:
preinstall, postinstall) in npm packages can execute arbitrary code during installation. If you're not running with --ignore-scripts, you're trusting every maintainer in your dependency tree implicitly.The cooldown helps with the automated propagation problem. The rest of the list is about containing what happens if something still gets through.
---
## HackWire Analysis
There's a framing buried in GitHub's announcement that deserves more attention than it's getting: the explicit acknowledgment that time-based defenses don't work against attacks that "play a longer game."
The XZ Utils attack has fundamentally changed how the security community evaluates supply chain risk. Before that incident, the dominant threat model was opportunistic: a compromised account, a quickly-pushed malicious version, fast propagation. Controls like cooldowns and publication delays are built for exactly that. After XZ Utils, we know sophisticated nation-state actors are willing to invest years in establishing legitimate-looking maintainer personas. Those actors don't care about a three-day window.
What's concerning is that the industry's current wave of countermeasures — and this Dependabot cooldown is one of the better ones — is almost entirely oriented toward the fast-and-opportunistic threat class. The slow-and-patient threat class, which is the one capable of embedding backdoors in cryptographic libraries used by major Linux distributions, is still largely unaddressed by tooling.
This isn't a reason to dismiss GitHub's improvement. It addresses a real and common attack pattern. But organizations running critical infrastructure, financial systems, or anything that attracts nation-state interest should not look at the three-day cooldown and feel the supply chain problem is solved. The next XZ-class event is not going to be stopped by a timer.
Defenders in high-value targets need to think beyond point-in-time package review: behavioral analysis of packages at install time, monitoring for unexpected network calls from build pipelines, and treating their dependency graph as an ongoing audit surface rather than something you check once and forget. The package ecosystems are adding friction. That helps. It's not the same thing as security.
— HackWire Editorial
---
## Related Coverage