GitHub Adds 3-Day Dependabot Cooldown to Block Poisoned Packages

GitHub has rolled out a new cooldown mechanism in Dependabot that forces the automated dependency-management tool to wait at least three days after a package release is published before opening a version-update pull request. Configured via the `cooldown` option in `dependabot.yml`, the default applies only to standard version updates designed to keep dependencies current, while security updates continue to be pushed immediately so Dependabot can alert maintainers and generate a fix-pull-request against patched releases without delay.

The rationale centers on the poisoned-package attack pattern, in which a threat actor publishes a trojanized release of a widely used library that downstream projects pull and merge before the malicious version is identified and yanked from the registry. Although these tampered packages typically live only hours in the wild, the brief window is often enough to widen the blast radius of a software supply chain attack considerably. GitHub stated it chose three days as the "goldilocks zone," long enough to outlast the active lifespan of most malicious releases yet short enough not to delay legitimate dependency upgrades. Developers can tune the cooldown higher or lower per repository.

GitHub cautioned that cooldown is only one layer of defense and recommended pairing it with pinned dependencies and lockfiles, disabled install scripts in CI pipelines, tightly scoped tokens, and mandatory human review of automated updates. The platform acknowledged the feature targets a narrow pattern, malicious versions that ship, spread, and get caught quickly, and does little against longer-game threats such as dormant backdoors, maintainer-account takeover, or compromised build infrastructure. Similar time-based controls have already shipped across VS Code, RubyGems, Bun, npm, pnpm, and Yarn. Around the same time, PyPI maintainers announced plans to block file additions to a release 14 days after publication, another measure aimed at preventing attackers who steal publishing tokens or hijack workflows from retroactively poisoning trusted packages.

For security teams auditing their own build pipelines, validating that dependency-update traffic and artifact repositories are served over hardened channels is essential, and an SSL/TLS checker can quickly confirm whether package registries and CI endpoints enforce strong encryption. Reviewing the scope and storage of CI secrets with a password checker helps catch weak or leaked tokens that could be abused to inject poisoned releases, while running an port scanner against build infrastructure surfaces unintended exposed services that threat actors could pivot through during a supply chain compromise.