Why automated updates are a supply-chain blind spot
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 that together see more than 2 billion downloads a week. The poisoned code rewrote cryptocurrency wallet addresses inside any browser app that loaded it. The malicious versions stayed live for about two hours before the community flagged them and npm removed them.
That two-hour window is exactly the kind of fast response that matters—but it is also plenty of time for an automated update tool to spot a new release, open a pull request, and surface it to your team. Version update tooling is designed to grab the newest version the moment it lands, and that behavior places it squarely in the path of a growing share of supply chain attacks where bad code ships in a brand-new release and gets pulled into builds before any human or scanner has seen it.
The cooldown response
Dependabot's answer is a cooldown. For non-security version bumps, it now waits at least three days after a release is published before opening a pull request. That delay gives maintainers, security researchers, and automated scanners time to catch a malicious release and get it pulled from the registry before it ever reaches your pull requests.
The behavior is controlled by the cooldown configuration option in the dependabot.yml file, so you can tune the window to something other than the three-day default if it better fits your project.
How long malicious releases live
Malicious releases in high-profile incidents rarely survive long. Compromised versions of Solana web3.js, Axios, and ua-parser-js were each caught within hours of publication. A review of 21 widely reported supply chain incidents between 2018 and 2026 found the same pattern recurring repeatedly. The push toward automated, immediate adoption is a mismatch with real-world attack lifecycles.
GitHub's own data tells the same story. Through the GitHub Advisory Database, which catalogs open source security advisories across ecosystems, the company published more than 6,500 npm malware advisories in the year ending May 2026—up from roughly 6,200 the year before. That works out to about 18 newly cataloged malicious npm packages every day. A cooldown keeps your workflows out of that opening window and lets a release build up some scrutiny before it's candidate for merge.
Why three days is the default
The three-day default is a balance. Most of the short-lived malicious publishes documented in those incident reviews were pulled from registries within hours; waiting three days filters the majority of them out before they reach your pull requests. At the same time, the delay is short enough not to hold back your legitimate dependency updates unnecessarily.
Some community-driven tools have independently settled on a similar three-day delay, and a few go longer. Making three days the Dependabot default keeps behavior consistent across the ecosystem when developers move between tools. And because cooldown is configurable, you can extend or shorten that window as your risk tolerance requires.
What a cooldown can't do
A cooldown is targeted at one specific pattern: a malicious version that ships, spreads, and gets caught quickly. It will not help against longer-lived attacks. Backdoors planted in a release and left dormant, maintainer sabotage, or a compromise of the build system itself can persist long after any practical cooldown expires.
The default exists to remove a common, time-sensitive attack path—not to replace the rest of your security posture. It works best as one layer among several. Practical additions include pinning dependencies with lockfiles, disabling install scripts in CI where feasible, scoping build-pipeline tokens tightly, and reviewing every update before you merge.
The full set of what you can tune with the cooldown parameter is documented in the Dependabot configuration options reference, and examples of adjusting cooldowns for trusted internal packages versus public registries appear in the documentation on configuring Dependabot.
The behavior is enabled by default, so no configuration is required to start receiving protection. Feedback on how the cooldown performs is being collected in the Dependabot community discussions.
