For a decade, dependency automation has been sold on one promise: the moment a new version ships, a bot opens the pull request. GitHub just decided that promise was the problem. As of this week, Dependabot waits at least three days after a release is published before opening a non-security version-update pull request — by default, for everyone, with no configuration change required.
It is a rare case of a major platform deliberately making its tooling slower, and the reasoning is a small case study in how supply chain attacks actually play out on the modern package registry.
The two-hour window that changed the default
GitHub’s announcement leads with the incident that made the argument for it. In September 2025, an attacker phished the credentials of a single npm maintainer and published booby-trapped versions of chalk, debug, and roughly a dozen other packages — a set of libraries that together are downloaded more than two billion times a week. The injected code rewrote cryptocurrency wallet addresses inside any browser app that loaded it. The community caught it and npm pulled the poisoned versions in about two hours; security firm Aikido, which helped flag the compromise, published a minute-by-minute account of the attack the same day.
Two hours is, by incident-response standards, excellent. It is also more than enough time for an automated updater to notice the new version, open a pull request, and put malicious code in front of a busy team whose review habit for patch bumps is a glance and a merge. The tooling was working exactly as designed — and the design was the vulnerability.
That shape repeats across the best-known registry compromises. GitHub’s own review of 21 widely reported supply chain incidents between 2018 and 2026 found that malicious versions of axios, Solana web3.js, ua-parser-js, and Ledger Connect Kit were each pulled within hours of publication. The attack pattern depends on speed: publish a poisoned release, let automated pipelines ingest it within minutes, and cash out before anyone looks. A cooldown attacks the pattern at its weakest point — the poisoned release usually doesn’t survive long enough to outlast a waiting period.
What exactly changed (and what didn’t)
Dependabot does two distinct jobs, and the cooldown applies to only one of them.
Security updates respond to published advisories: when a vulnerability is disclosed in a package you use, Dependabot alerts you and opens a PR to move you to the patched version. These still fire immediately — delaying a fix for a publicly known flaw would be actively harmful.
Version updates keep dependencies current regardless of whether anything is wrong with your pinned version. This is the job that now waits. Fresh releases must age three days before Dependabot will propose them.
The distinction matters because it neutralizes the obvious objection. Nobody’s zero-day patch is being held in a queue; the only thing that slows down is the routine churn of staying current — and staying current by minutes was never a security benefit in the first place.
The behavior is controlled by the existing cooldown configuration block in dependabot.yml, documented in the Dependabot options reference. Teams that were already setting a cooldown keep their value; teams that never touched it inherit the three-day default. You can shorten it, lengthen it, or scope different windows to different dependency groups — a practical pattern is a near-zero cooldown for highly trusted internal packages and a longer one for public-registry dependencies.
In practice that looks like a cooldown block under the relevant updates entry: set default-days for the blanket window, then carve out exceptions with include and exclude lists for specific packages or patterns. A team consuming its own scoped internal packages alongside the public npm registry, for example, can exclude the internal scope from the cooldown entirely while holding third-party packages to seven days — the configuration is per-ecosystem, so npm, pip, and GitHub Actions can each get their own policy.
Why three days, specifically
The number is a compromise between two curves. On one side: how long poisoned releases survive. GitHub’s Advisory Database cataloged more than 6,500 npm malware advisories in the year ending May 2026 (up from roughly 6,200 the prior year — about 18 newly cataloged malicious npm packages per day), and the high-profile compromises consistently died within hours. Three days clears that window with margin.
On the other side: how stale you can afford to be. Every day of cooldown is a day you run behind upstream bug fixes and improvements. GitHub’s judgment is that three days buys most of the available protection while costing little in practice — and it notes that several community tools independently converged on the same three-day figure, so the default also keeps behavior consistent as developers move between updaters.
There is a subtler benefit for maintainers of noisy repositories: a cooldown coalesces rapid-fire release sequences. A package that ships v2.1.0, v2.1.1, and v2.1.2 in the same week produces one Dependabot PR at the end of the cooldown instead of three, which is less review fatigue for exactly the class of update people rubber-stamp.
What a cooldown cannot do
GitHub is unusually direct about the limits. The cooldown is built for one attack shape: a malicious version that ships, spreads, and gets caught quickly. It does nothing against a backdoor planted in a release and left dormant past the waiting period, a maintainer who turns malicious, or a compromised build system signing “legitimate” artifacts. An attacker who knows the ecosystem now defaults to three-day cooldowns can, in principle, simply wait — though doing so extends their exposure to scanners and researchers, which is precisely the trade the default is designed to force.
So the cooldown slots in as one layer, and the announcement pairs it with the rest of the standard defense-in-depth list: pin dependencies with lockfiles, disable install scripts in CI where possible, scope the tokens available to build pipelines, and actually review updates before merging. None of that is new advice. What is new is the platform default doing some of the work for teams that never got around to configuring it.
The bigger signal: velocity is no longer the metric
The interesting part of this change is less the three days than the philosophy shift it represents. Dependency automation grew up in an era when the threat model was staleness — unpatched, years-old libraries with known CVEs. The tooling optimized accordingly: faster ingestion, instant PRs, merge-on-green. The registry-compromise era inverts the risk at the freshest end of the curve. The most dangerous version of a package, statistically, is the one published two hours ago.
GitHub turning that observation into a default — rather than a blog-post recommendation — matters because defaults are where security actually happens. The teams most exposed to fast-moving npm malware were never the ones with carefully tuned dependabot.yml files. As of this change, they’re covered without knowing it.
For teams who want to go further, the tuning knobs are all in the options reference: per-ecosystem cooldowns, per-dependency-group overrides, and longer windows for the paranoid. GitHub is collecting feedback on the default in its Dependabot community discussions — but the direction of travel is clear. In 2026, the fastest update is no longer the safest one.
