Dependabot Default Cooldown: Review Version Updates Without Delaying Security Fixes

GitHub changed the default timing for Dependabot version updates: a newly released package must now have been available in its registry for at least three days before Dependabot opens a version-update pull request. GitHub says the default requires no configuration and applies across supported ecosystems on github.com. The important operational boundary is that this delay applies to routine version updates, not Dependabot security updates.

GitHub documents the default, its scope, and the available configuration controls. The review workflow below is inferred defensive guidance. CodeRiskTools did not independently test GitHub’s hosted Dependabot service or measure whether a three-day window catches compromised releases. A delay can create observation time; it cannot prove that a package is trustworthy.

What the three-day default changes

Before this default, a version-update pull request could put a just-published release in front of a maintainer quickly. GitHub describes fresh releases as a common entry point for broken or compromised dependency versions and says a short delay gives maintainers and the community time to surface warning signals. The new default changes when the routine pull request is opened; it does not replace dependency review.

Do not confuse version updates with security updates

Dependabot version updates keep declared dependencies current even when no known vulnerability is involved. Dependabot security updates respond to an eligible Dependabot alert and attempt to raise a pull request to a patched version. GitHub’s security-update documentation explains that an update may fail when the dependency graph cannot be resolved or when an indirect dependency requires a parent change.

This distinction should appear in review records. If a routine update arrives after the cooldown, label it as a version update. If the pull request responds to an alert, preserve the alert link, advisory identifier, affected range, fixed version, and update error state. “Dependabot did not open a pull request” is not the same as “the repository has no vulnerable dependencies.”

Configure cooldown only with a written policy

GitHub’s options reference documents default-days, separate major/minor/patch windows for ecosystems with supported semantic-version handling, and include/exclude lists with wildcard support. The reference also says an exclusion takes precedence if the same dependency appears in both lists. A minimal policy-specific block can look like this:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 7
      semver-patch-days: 3
      exclude:
        - "example-internal-package"

This is an illustrative configuration, not a universal recommendation. Validate syntax against the current official reference and test it in a non-critical repository. Longer windows reduce freshness; exclusions remove the cooldown for matching packages; opting out increases exposure to newly published versions. Keep the rationale beside the repository’s dependency policy.

A six-step review workflow after the cooldown

1. Classify the lane. Confirm whether the pull request is a routine version update or a security update. Do not infer this from the package name alone.
2. Pin the evidence. Record the manifest, lockfile, old version, proposed version, registry, commit SHA, and Dependabot pull-request URL.
3. Inspect release provenance. Check the official registry record, source tag, maintainer or publisher changes, signed artifacts where available, and whether the source-to-package relationship is explainable.
4. Read the effective diff. Review lockfile changes, new transitive dependencies, install scripts, build hooks, executable downloads, permission changes, and unexpected platform-specific artifacts.
5. Exercise the update. Run clean-install tests in an isolated environment with bounded credentials and network access. Include negative tests for affected security boundaries, not only a green build.
6. Record the decision. Merge, defer, pin, replace, or investigate with an accountable reviewer, exact commit, evidence links, and residual risk.

Supply-chain checklist for the observation window

• Confirm the package release age from the authoritative registry rather than the pull-request timestamp.
• Check whether ownership, publisher identity, release automation, or repository location changed.
• Compare package contents and dependency graph changes, not only release notes.
• Search official advisories and maintainer issues; label community reports as unverified until reproduced.
• Keep security updates in the immediate lane even when routine updates use a longer policy window.
• Do not expose production tokens to package install scripts or pull-request workflows.
• Regenerate the lockfile with the expected package manager and inspect unexplained churn.
• Store the final decision and tests against the reviewed commit, then re-check after force-pushes.

Common mistakes the default does not solve

A three-day-old malicious release can still be malicious. A quiet issue tracker can reflect low adoption rather than safety. Passing tests can miss install-time behavior, data exfiltration, optional dependencies, or platform-specific payloads. Conversely, a recent release is not automatically compromised. Use the cooldown as one input to a reproducible decision, not as a reputation score.

Also avoid extending the delay to urgent remediation by process accident. If a security update appears, confirm its alert and patched range, prioritize it according to exposure, and investigate any update error. When teams intentionally add a cooldown or exclusion, code review should verify that the YAML matches the written policy.

FAQ

Does the new default delay Dependabot security updates?

No. GitHub’s July 14 changelog explicitly says the default applies only to version updates and that security updates continue to open immediately.

Can a repository change or disable the three-day window?

Yes. GitHub documents the cooldown option in .github/dependabot.yml, including configurable periods and dependency include/exclude controls. Verify current syntax and ecosystem support before changing it.

Does the cooldown certify a package as safe?

No. It is elapsed time before a routine update pull request, not a security assessment, signature, provenance guarantee, or complete supply-chain scan.

Should every team choose a longer cooldown?

Not necessarily. The right window depends on update urgency, exposure, package criticality, test quality, and the team’s ability to inspect releases. Document the trade-off and preserve an immediate security-update lane.

Official sources and next steps

• GitHub Changelog: Dependabot version updates introduce default package cooldown — vendor documentation for the three-day default, update-lane boundary, github.com scope, and GHES timing.
• GitHub Docs: Dependabot options reference — official configuration keys, precedence, and ecosystem support.
• GitHub Docs: Dependabot security updates — official explanation of alert-driven update behavior and limitations.

Continue with the CodeRiskTools dependency audit workflow, AI-agent supply-chain review, and pre-commit checks. The single comparison hub helps separate tool scope without claiming complete coverage.