GitHub adds a default three-day cooldown to Dependabot version updates

GitHub has turned on a new default waiting period for Dependabot version updates, adding a three-day cooldown before the service opens pull requests for newly published package releases. The change, announced July 23, is aimed at a narrow but damaging class of software supply chain attacks: malicious packages that are published, spread quickly through automated update workflows, and are removed after researchers or maintainers notice the compromise.

The policy applies to Dependabot version updates, the routine pull requests that keep dependencies current. GitHub says Dependabot security updates will still open immediately when a public advisory identifies a vulnerable dependency and a patched version is available. That distinction matters because delaying a security fix would create a different risk, while delaying ordinary version bumps can give the ecosystem more time to spot a poisoned release.

Why GitHub Is Slowing Some Updates

GitHub framed the default as a response to incidents where attackers compromised maintainers or package publishing paths, pushed malicious releases to public registries, and relied on automated update tools to carry those releases into downstream projects. The company cited the September 2025 compromise involving packages such as chalk and debug, saying the poisoned versions were live for roughly two hours and affected packages with more than 2 billion weekly downloads in aggregate.

The new default is meant to keep projects out of that first high-risk window. GitHub also pointed to its Advisory Database, saying it 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 per day, a scale that makes automated dependency hygiene both useful and potentially risky when it reacts instantly to every fresh release.

What Maintainers Can Change

The three-day delay is now enabled by default for version updates, but teams can adjust it through Dependabot's cooldown configuration in dependabot.yml. Projects with tightly controlled internal packages may choose a shorter window, while projects exposed to busy public registries may prefer a longer one.

GitHub also cautioned that cooldowns are only one layer of defense. They are designed for fast-moving malicious releases that are discovered quickly, not for dormant backdoors, maintainer sabotage, or compromised build systems. Maintainers still need review practices, lockfiles, scoped automation tokens, and limits on risky install scripts in continuous integration environments.

Sources

• github.blog

Cover photo by Rafael Minguet Delgado on Pexels, used under the Pexels License.