Dependabot now waits three days: turn dependency speed into a supply-chain policy

Dev

Automatically merging yesterday's package release is not always ‘fast maintenance.’ If the release is broken, a publisher account was compromised, or malicious behavior is discovered later, update automation can become the attacker's distribution channel. On July 14, GitHub changed the default so Dependabot routine version-update pull requests wait until a release has existed on its registry for at least three days. This is a valuable observation window, not a safety certificate. The practical task is to connect that delay to review, resolution, installation, and exception policies.

Supply-chain policy diagram connecting a package release, Dependabot's three-day observation window, update PR, dependency review, frozen install, and deployment, with security updates taking an immediate bypass lane
The three-day cooldown is an observation window before PR creation. Review, lockfiles, install policy, CI, and an emergency lane turn it into a real control.

What changed: routine version updates now wait at least three days

The new default applies to Dependabot version updates across all supported ecosystems on github.com and is planned for GitHub Enterprise Server 3.23. No configuration is required. A newly published release is skipped until it has been available on the registry for at least three days.

Known-vulnerability security updates remain immediate. GitHub deliberately separates keeping dependencies current from removing a known vulnerable version, so a critical fix is not held behind the routine cooldown.

Repositories can override the default in .github/dependabot.yml. The official cooldown options include a default window, separate SemVer major/minor/patch windows, and include/exclude lists. Durations can range from 1 to 90 days; include and exclude accept up to 150 entries each, and exclusions take precedence. Three days is a baseline, not a universal recommendation.

Three days creates signal time; it does not validate a release

A delay gives maintainers and early adopters time to withdraw a broken release, open issues, or publish a warning. Silence does not prove safety. A low-adoption package, a targeted compromise, or delayed malicious behavior may produce no public signal during the window.

Cooldown and Dependabot's schedule are separate clocks. A weekly repository may not receive a PR immediately after day three; it will wait for the next scheduled check. Review queues, CI, and deployment windows add more time. Measure the whole release-to-production lead time instead of treating the number three as the policy outcome.

SemVer size is useful but not equivalent to risk. A patch can carry a supply-chain compromise, while a major can contain an urgent compatibility fix. Combine version class with maintainer trust, install-time capabilities, production reach, test quality, and rollback cost.

The critical boundary: a Dependabot PR is not an install policy

The cooldown controls when Dependabot creates a version-update PR. It does not automatically stop a developer from running npm install package@latest, a lockfile-free CI job from resolving a fresh transitive version, or another update bot from selecting it. ‘Dependabot waits three days’ is not the same as ‘the organization cannot install releases younger than three days.’

Current npm documentation provides an install-layer min-release-age filter. A project-level min-release-age=3 can prevent npm from selecting releases newer than the threshold, while min-release-age-exclude can exempt internal packages. This is an npm capability; verify syntax and support separately for every other package manager.

For approved trees, commit the lockfile and use a frozen install such as npm ci. npm documents that npm ci fails when package.json and the lockfile disagree and never rewrites them. The cooldown delays creation of a new tree; the frozen install prevents an unreviewed tree from appearing later in CI or production.

Once the PR exists, review the tree—not just its age

GitHub Dependency Review exposes direct and transitive changes in manifests and lockfiles, including release dates and known vulnerabilities. Requiring the Dependency Review Action can turn selected vulnerability and license rules into a merge gate.

A green unit-test suite is not the complete review. Look for new lifecycle scripts, native binaries, network access, unexpectedly large transitive diffs, changes in artifact origin, and packages that reach privileged build or production contexts. High-risk changes may deserve a sandboxed install with restricted network access.

Split auto-merge rules by blast radius. Type definitions, runtime libraries, GitHub Actions, container images, and infrastructure providers do not carry the same permissions. ‘Patch plus green CI’ should not be a universal approval rule.

Community signal: developers are asking where the waiting actually applies

Community discussions about minimum release age repeatedly focus on a gap: delaying direct update PRs does not control every transitive dependency or every installation path. Other threads reflect alert and PR fatigue that eventually causes teams to disable automation. These posts are audience signals, not authoritative evidence of product behavior.

The operating model must therefore explain three distinctions: PR cooldown versus resolver enforcement, version updates versus security updates, and delaying a PR versus reducing PR volume. Groups, schedules, open-PR limits, and reviewer capacity still determine whether automation remains usable.

The goal is not simply to update slowly. Security fixes need a fast lane; routine changes need observation and review; emergency exceptions need recorded approval, expiry, canary deployment, and rollback.

A practical checklist for today

1. Inventory every dependabot.yml and distinguish explicit cooldown policies from repositories inheriting the new default.

2. Document separate SLAs for version and security updates.

3. Classify production dependencies, dev tools, GitHub Actions, containers, and IaC providers by blast radius.

4. Start with explicit major/minor/patch windows, then adjust them using deployment and incident evidence.

5. Give every exclusion an owner, reason, and expiry.

6. Require dependency review and inspect transitive lockfile changes.

7. For npm projects, evaluate project-level min-release-age with the current CLI.

8. Commit lockfiles and use npm ci or the ecosystem's equivalent frozen mode in CI and production.

9. Define an emergency bypass with approval, canary, and rollback.

10. Measure PR delay, merge lead time, failures, rollbacks, and known-vulnerability exposure.

Risks and counterarguments

‘Newest is safest’ is persuasive for known vulnerability fixes, which is why security updates bypass the cooldown. It is not universally true for every routine release. The opposite—‘older is always safer’—also fails because old versions accumulate known vulnerabilities and compatibility debt.

The default may delay PR arrival without reducing the eventual number of PRs. If fatigue is the problem, use grouping, scheduling, auto-merge scope, and reviewer capacity alongside cooldowns.

Install-time age gates are also incomplete. Check private-registry timestamps, versions already locked, Git or URL dependencies, and exemption lists. Mature supply-chain security layers release age with provenance, dependency diffs, testing, least privilege, reproducible installs, and fast remediation.

A starting policy, not a universal answer

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
      exclude:
        - "@myorg/*"

These numbers are an example for team discussion, not GitHub's universal recommendation. Adjust them to risk, update cadence, and emergency needs.

Dependabot cooldown operating checkpoints

✓1. Inventory every dependabot.yml and distinguish explicit cooldown policies from repositories inheriting the new default.

✓2. Document separate SLAs for version and security updates.

✓3. Classify production dependencies, dev tools, GitHub Actions, containers, and IaC providers by blast radius.

✓4. Start with explicit major/minor/patch windows, then adjust them using deployment and incident evidence.

✓5. Give every exclusion an owner, reason, and expiry.

✓6. Require dependency review and inspect transitive lockfile changes.

✓7. For npm projects, evaluate project-level min-release-age with the current CLI.

✓8. Commit lockfiles and use npm ci or the ecosystem's equivalent frozen mode in CI and production.

✓9. Define an emergency bypass with approval, canary, and rollback.

✓10. Measure PR delay, merge lead time, failures, rollbacks, and known-vulnerability exposure.

Official change: GitHub Changelog: Dependabot version updates introduce default package cooldown

Bottom line

Dependabot's three-day default is more than a small timing change: it turns routine dependency updates into a risk-specific time policy. Keep security updates immediate, observe routine releases, freeze approved trees with resolver and lockfile controls, and attach ownership and expiry to every exception.

Sources

다른 글