Dependabot Cooldown: A Safety Brake on Automatic Updates
GitHub’s Dependabot cooldown is a time-based delay that holds routine dependency version updates for at least three days after a new release appears, keeping automated pull requests from instantly adopting potentially poisoned packages while still allowing urgent security fixes to flow without interruption. This is a rare example of a tool deliberately becoming slower to make developers safer. For non-security upgrades, Dependabot now waits three days before filing a pull request, giving the security community time to detect short-lived malware in popular packages before it lands in your repository. Security updates, however, bypass the cooldown: when an advisory is published, Dependabot opens a pull request right away so known vulnerabilities are patched as soon as possible. In other words, GitHub is saying speed is good—until speed turns into a delivery mechanism for attacks.
The Threat: Automated Tools Feeding on Poisoned Packages
The cooldown exists because modern automation was starting to help attackers. In one incident, an attacker phished an npm maintainer’s credentials and shipped poisoned versions of chalk, debug, and about a dozen other packages. Together, these packages are downloaded more than 2 billion times a week, and the injected code rewrote cryptocurrency wallet addresses inside any browser app that loaded it. The bad versions were live for about two hours before the community caught them and the registry pulled them. Two hours is more than enough for Dependabot and similar tools to see the new release and open a pull request, quietly placing poisoned code in front of reviewers. These trojanized packages are short-lived, but the period in which they remain accessible is enough to expand the blast radius of a supply chain attack. When automation chases the latest version by design, attackers can weaponize that speed.
Why Three Days Is the “Goldilocks” Delay
GitHub did not pick three days at random. A poisoned build of a popular package tends to have a short life: it publishes, spreads to whatever installs it, and gets caught, usually within a few hours. A review of 21 widely reported supply chain incidents showed the same rhythm every time, and a short waiting period would have filtered most malicious publishes before anyone installed them. A cooldown keeps you out of that opening window and lets a release collect some scrutiny before it reaches you. According to GitHub, “Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn’t hold your dependencies back longer than necessary.” Other ecosystem tools have settled on similar time-based defenses, which keeps behavior consistent for developers and normalizes the idea that instant upgrades are not always the smartest form of GitHub package security.
What the Cooldown Does—and What It Cannot Do
The Dependabot cooldown is narrowly aimed at a specific attack pattern: malicious versions that ship, spread fast through automated tooling, and then get caught and removed. It removes one fast, common path onto your machines, but the rest of the supply chain still needs watching. GitHub’s Advisory Database logged more than 6,500 npm malware advisories in the year ending May 2026, which works out to about 18 freshly cataloged malicious npm packages a day. A three-day pause gives researchers time to detect these issues and register poisoned package detection before your bots touch them. However, as product manager Carlin Cherry notes, the cooldown does little against attacks that play a longer game, including backdoors planted in releases and left dormant, maintainer sabotage, or a compromised build system. If developers treat the delay as a full solution, they will miss the slower, more subtle compromises that define modern supply chain protection.
How Developers Should Respond: Tune the Delay, Strengthen the Chain
Developers should treat the Dependabot cooldown malware control as a sensible default—not a reason to relax. The delay is on by default, and teams can tune the window in dependabot.yml or set different delays for trusted internal packages and public registries. With this update, developers benefit from researcher-led vetting during the cooldown window without sacrificing urgent security updates, which still ship immediately. But GitHub is explicit: the control should be one layer of defense among several others, including pinning dependencies with lockfiles, disabling install scripts in CI where possible, scoping the tokens in build pipelines, and reviewing updates before they merge. A cooldown keeps your automation from amplifying short-lived attacks, while traditional hygiene and code review guard against long-term backdoors. The takeaway is clear: do not turn off automation—slow it where it is most dangerous, and surround it with human judgment and basic GitHub package security practices.
