Dependabot's Three-Day Cooldown Is Incomplete

GitHub just flipped a long-available Dependabot knob into a default. Dependabot version updates now wait until a release has sat on its registry for at least three days before opening a pull request. No config required. Security updates still fire immediately.

That is a real improvement for teams that never touched cooldown. It is also easy to overread. A three-day gate on the bot path is not a three-day gate on every way a package lands in a lockfile or a CI job. Treat the change as one control point, not a supply-chain policy.

What changed and what did not

Previously, cooldown was opt-in. Security-conscious teams had to know the option existed, put it in .github/dependabot.yml, and keep it consistent across ecosystems. As of the changelog entry, a three-day wait is the baseline for version updates on github.com, with the same behavior planned for GitHub Enterprise Server 3.23.

The important split stays in place:

• Version updates wait (three days by default).
• Security updates open immediately, so critical fixes are not held back by the new default.

You still own the policy. The cooldown block can lengthen or shorten the window, set different waits by SemVer level, include or exclude named packages, or turn the delay off. Documented windows run from one to 90 days. Exclude lists beat include lists: if a dependency appears in both, it skips cooldown and can update right away.

A short wait is not a provenance check. Three days of public existence gives maintainers, scanners, and the community a chance to flag a bad release. It does not prove who built the package, whether the publish was legitimate, or whether the code is safe at runtime.

Why a delay helps, and where it stops

GitHub’s own framing is straightforward: new releases are a common entry point for supply chain attacks, and a short delay reduces the odds of merging a compromised or broken version the moment it ships. That timing argument matches how many recent compromise waves have played out. Malicious or hijacked versions often surface in the first day or two, when automated bots are most eager and human review is thinnest.

Some vendors already treat package age as a separate gate. StepSecurity’s npm Package Cooldown check, for example, fails a PR that introduces a version published inside a short window (they default that check to two days). That is a merge-time control on what is already in a PR. Dependabot’s cooldown is upstream of that: it decides whether the version-update PR exists yet. Used together, one throttles proposal volume and the other blocks still-too-fresh artifacts. Used alone, Dependabot’s default only covers the bot.

The install-layer gap

Dependabot proposes changes. Package managers resolve and install them. Those are different layers, and the new default only moves the first one.

A developer who adds a dependency by hand, a CI job that regenerates a lockfile, a npm update / pnpm up / yarn up run, or another automation service can still pull a day-zero release. None of those paths inherit Dependabot’s three-day wait. If your threat model is “do not adopt brand-new registry versions,” you need matching policy at resolve/install time, not only in dependabot.yml.

Package managers have started to grow their own age controls, but defaults and units differ, and they are not wired to Dependabot. npm documents a min-release-age setting (days) that is off unless you set it. pnpm’s minimumReleaseAge is measured in minutes and has changed defaults across major versions. Yarn has introduced an npm age gate of its own. The practical point is not which number is “right.” It is that leaving Dependabot on three days while install paths stay unrestricted only moves risk off the bot’s PR list.

Also watch emergency paths. Security updates are supposed to ignore cooldown, but operators have hit cases where cooldown filtering still interfered with security jobs. After you set a long wait, verify that a known vulnerable package still produces a security PR promptly. Policy on paper and behavior in the updater logs are not always the same on day one of a config change.

What to put in dependabot.yml

Start from the new default, then decide where three days is wrong for your risk and review capacity.

Minimal explicit policy (same as the new default, but reviewable in git):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3

Tighter or looser by SemVer, with an emergency escape for a package you trust to ship fast:

cooldown:
  default-days: 3
  semver-major-days: 7
  semver-minor-days: 3
  semver-patch-days: 2
  exclude:
    - "critical-internal-sdk"

Useful patterns for most teams:

• Keep security updates on the fast path (the product default). Do not try to “improve” them with cooldown.
• Prefer a slightly longer wait on majors than on patches if review cost is the bottleneck; majors already deserve human attention.
• Use exclude sparingly for packages you actively monitor or pin tightly; a long exclude list is how day-zero risk sneaks back in.
• Pair cooldown with groups so the PRs that do arrive are reviewable batches, not a daily trickle of one-line bumps.
• Align schedule.interval with cooldown. Daily checks plus a three-day age gate still only open PRs for releases that cleared the window; weekly schedules reduce noise further.

Then close the other paths. Set the package manager’s release-age option in project config (and document the bypass for hotfixes). Fail CI if a lockfile introduces a version younger than your policy, or adopt a check that does the same at PR time. Decide what happens when a security fix is younger than the age gate: keep the vulnerable version and alert, force an exception list, or accept a short-lived risk with an audit trail.

Who should care and when to opt out

Most application teams on public registries should keep the default or lengthen it. Three days is a reasonable floor for npm, PyPI, crates.io, and similar ecosystems where automated bots are a known amplification path for bad publishes.

Consider shortening or opting out only when you have a concrete reason: private registries with controlled publish pipelines, internal packages that must ship the same day across many repos, or release trains where Dependabot is the deployment mechanism rather than a security net. Even then, prefer exclude for named packages over a global default-days: 0 that turns the whole ecosystem hot again.

Organizations that centralize Dependabot config (or generate it) should roll the default explicitly so every repo’s git history shows the policy, not a silent platform change. GHES admins should plan for 3.23 rather than discovering quieter version PRs after upgrade.

The bottom line is simple. GitHub moved the safe default for version-update PRs. That cuts a real class of day-zero merges for teams that only ever updated through Dependabot. It does not secure install, does not authenticate publishers, and does not replace review. Wire the bot delay, the resolver age gate, and the security-update fast path together, or the gap will be where the next bad release walks in.