Dependabot's new cooldown is not a dramatic security feature. That is why it is interesting. GitHub has added a default three-day wait before Dependabot opens version-update pull requests, turning a small pause into a supply-chain control.

The GitHub Blog framed the change around a familiar failure mode: a popular package gets compromised, a malicious version is published, automated tooling notices the shiny new release immediately, and the update reaches projects before maintainers, researchers, registries, and scanners have finished reacting. Dependabot's version-update path is now slower by default on purpose.

new upstream release
  -> wait through cooldown window
  -> let registry/advisory/scanner signals arrive
  -> open version-update pull request
  -> review, test, merge
The delay does not prove a release is safe. It reduces the chance that automation is the first wave of adoption.

Speed Is A Trust Boundary

Dependency automation has usually been sold as speed hygiene. Keep packages current. Avoid stale libraries. Make the pull request small enough that the team will actually review it. That is still true, but the supply-chain environment has changed around the workflow.

A fresh release is no longer automatically the safest thing to consume. Sometimes it is the riskiest artifact in the system because nobody outside the publisher has had time to inspect it yet. If the maintainer account was phished, the build workflow was poisoned, or an attacker briefly gained publish rights, the newest version can be the blast wave.

The fastest update bot can accidentally become the best distribution channel for the newest bad release.

GitHub points to short-lived malicious package events where the poisoned version existed for only hours. That is a fast ecosystem response, but it is not fast enough if update automation opens a pull request within minutes and a team merges through a green CI run. The cooldown tries to move Dependabot out of that first dangerous window.

Version Updates Are Different

The important distinction is between Dependabot security updates and Dependabot version updates. Security updates respond to a known vulnerability. If an advisory says the version you are running is vulnerable and a patched version exists, the correct default is urgency. Waiting three days would keep the bad version in place after the fix is public.

Version updates are different. They keep dependencies current even when the current version is not known to be vulnerable. That work matters, but it is not usually an emergency. For those routine bumps, GitHub now makes Dependabot wait at least three days after a release is published before opening the pull request.

That is the right place to spend time. Security fixes still move quickly. Ordinary freshness gets a short quarantine period. The result is not slower security response. It is more context before adopting unproven releases.

The Three-Day Shape

Three days is a compromise, not a theorem. GitHub's post says many malicious releases targeting popular packages are caught quickly, often within hours. It also says the GitHub Advisory Database published more than 6,500 npm malware advisories in the year ending May 2026, roughly 18 newly cataloged malicious npm packages per day. That volume makes the opening window matter.

A one-day delay might dodge some obvious fires. A week would provide more time but could make dependency maintenance feel stale for teams that rely on frequent update PRs. Three days is a practical default: long enough for many bad releases to be noticed, short enough that normal version maintenance does not turn into archaeology.

The better lesson is that update timing has become configurable policy. A public registry dependency, an internal package, a major version bump, and a patch release do not all need the same appetite for immediacy. Dependabot's cooldown option lets teams express that difference instead of treating every release as equally ready the moment it appears.

The Config Is The Policy

GitHub Docs now describe cooldown controls directly in dependabot.yml. Teams can set a default delay, tune major, minor, or patch releases for ecosystems that support semantic versioning, and include or exclude specific dependencies.

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: daily
    cooldown:
      default-days: 3
      semver-major-days: 7
      semver-patch-days: 1
The useful part is not this exact YAML. It is that update delay becomes reviewable infrastructure.

That matters operationally. A team can decide that internal packages with a trusted publisher and tight release process should move quickly. It can also decide that public major updates should sit longer, or that a sensitive production service should not be the first consumer of anything from a noisy ecosystem. The policy lives in source control where it can be reviewed like any other delivery rule.

What It Does Not Solve

A cooldown is deliberately narrow. It helps with fast-moving malicious releases that get published, noticed, and removed quickly. It does not solve dormant backdoors, maintainer sabotage, compromised build systems that keep producing plausible releases, or a project that merges every dependency PR without reading it.

So the old layers still matter: lockfiles, dependency review, scoped registry tokens, install-script restrictions in CI where practical, release provenance, and human review for updates that touch important runtime paths. The cooldown is not a replacement for those controls. It is a timing layer that makes the rest of the system less likely to start from the worst possible moment.

  • Keep security updates fast because known vulnerable versions should not linger.
  • Slow routine version updates where a fresh release has not accumulated public signals yet.
  • Tune by ecosystem and dependency instead of using one risk appetite everywhere.
  • Review the PR anyway because waiting is not validation.

The Takeaway

Dependabot's cooldown is a useful correction to a habit the industry taught itself: newer is always better, and automated freshness is always safer. In a healthy ecosystem that is often close enough. In a hostile registry, it can be exactly backwards for the first few hours of a release.

The good version of dependency automation is not maximum speed. It is paced trust. Let automation do the boring work, but give the ecosystem enough time to cough when something is poisoned. A three-day brake will not stop every supply-chain attack. It will stop some teams from being early adopters of the wrong release, and that is a very practical kind of progress.

Sources