Dependabot security cooldown: a deliberate brake on poisoned package attacks
The Dependabot security cooldown is a time-based delay that forces automated dependency updates to wait several days before opening pull requests, giving the ecosystem a chance to discover and remove poisoned package attacks before they silently land in production code. Instead of upgrading the moment a new release appears, Dependabot now treats speed as a risk surface and inserts a controlled pause so that short-lived malicious versions are filtered out by community scrutiny and advisory databases, while still allowing teams to move quickly when a genuine vulnerability fix is published.
This change exists because automation has started working against us. In a widely discussed incident, an attacker phished an npm maintainer and shipped poisoned versions of chalk, debug, and about a dozen other packages. Those packages see more than 2 billion downloads a week, and the injected code rewrote cryptocurrency wallet addresses inside browser applications that loaded it. The bad builds lived for roughly two hours before being caught and removed, yet that window was long enough for automated tools to open pull requests and put malware directly in front of reviewers. The cooldown tackles that narrow but dangerous window in which a supply chain vulnerability exists and automated updaters amplify its impact.
How the three-day delay works—and why security fixes stay fast
GitHub’s decision is blunt: for routine version updates, Dependabot now waits at least three days after a release is published before opening a pull request. This Dependabot security cooldown applies only to the "keep me current" class of updates—those that follow new releases in registries—and is configured through the cooldown option in dependabot.yml, letting projects dial the window up or down to fit their risk appetite. In effect, GitHub is saying that freshness is good, but freshness within hours of release is a liability when poisoned package attacks frequently burn out in that same short interval.
Security patches are treated very differently, and rightly so. Dependabot has a second job: responding when an advisory lands for a package you already use. In that case, the three-day delay is not applied. Security updates still open the moment an advisory drops, and Dependabot alerts you and files a pull request to move to the patched version. Holding back a known fix would mean sitting on a flaw that is already public knowledge, which is unacceptable. GitHub arrived at three days as its default, calling it a goldilocks duration that "pushes you past the window where most of these attacks live" without keeping dependencies behind longer than necessary.
Short-lived malware and the new reality of automated supply chain risk
The cooldown is a response to a clear pattern: poisoned builds of popular packages tend to have short lives. They publish, spread quickly to whatever installs them, and are usually caught within a few hours. Compromised versions of widely used libraries like Solana web3.js, Axios, and ua-parser-js followed that arc, and GitHub’s Advisory Database logged more than 6,500 npm malware advisories in the year ending May 2026, which works out to about 18 newly cataloged malicious npm packages per day. In this environment, any tool that reacts instantly to new versions is a force multiplier for attackers exploiting supply chain vulnerability rather than a safety feature.
A review of 21 widely reported supply chain incidents over recent years found the same rhythm every time: a malicious version appears, spreads, and is pulled within hours. According to that analysis, a short waiting period would have filtered most of those releases before many downstream projects installed them. GitHub’s time-based defense aims squarely at this pattern: "a malicious version that ships, spreads, and gets caught quickly." Other ecosystems are coming to similar conclusions, with cooldown controls added to tools around Microsoft Visual Studio Code, Ruby, Bun, npm, pnpm, and Yarn, and Python’s package index planning to block new files from being added after 14 days to protect older trusted releases.
What the cooldown cannot fix—and how to use it without losing control
The Dependabot security cooldown is not a magic shield. GitHub is explicit: it does little against slow-burning attacks that plant backdoors and leave them dormant, maintainer sabotage, or compromised build systems. Those threats require different answers. But as one layer among several, the delay removes a fast, common path for malware to reach your CI and production machines. GitHub’s own stance is refreshingly clear-eyed: this is a targeted control against a specific pattern of poisoned package attacks, not a reason to relax elsewhere.
Developers still keep agency. The cooldown option in dependabot.yml lets you override the default, tuning the delay window or setting different values for trusted internal packages and public registries. During that window, advisories and ecosystem scrutiny have time to surface problems before Dependabot ever proposes the update. The message to teams is straightforward: pin dependencies with lockfiles, turn off install scripts in CI where possible, scope tokens in build pipelines, and review updates before they merge. Used this way, the cooldown reduces blast radius without turning your dependency management into a black box.
Action plan: adopt the cooldown as part of a broader supply chain defense
Teams that care about supply chain vulnerability should embrace the Dependabot cooldown as a sensible default and then harden around it. First, keep the three-day delay for public registries unless you have a clear, risk-based reason to shorten it. It is short enough that you are not stuck on stale dependencies for long, yet long enough to miss most fast-moving malware. Second, leave security updates untouched so urgent patches continue to arrive immediately; delaying known fixes undercuts the entire point of vulnerability advisories.
Finally, treat the cooldown as only one guardrail. Configure lockfiles to pin exact versions, disable install scripts in CI where you can, scope tokens tightly in your pipelines, and insist on human review before merging any dependency change. The real lesson from two-hour npm compromises and thousands of malware advisories per year is not that automation is bad, but that uncritical automation is dangerous. A small, deliberate delay—paired with disciplined review—is a pragmatic way to keep the speed of your tooling while denying attackers the instant blast radius they rely on.
