GitHub’s Dependabot Cooldown Has an Install-Layer Gap

GitHub has made a three-day waiting period part of Dependabot’s default behavior. That sounds like a small scheduling change. It is really a change to where software teams place trust: a newly published dependency no longer gets an automatic version-update pull request the moment it appears.

The GitHub announcement says Dependabot now waits until a release has been available in its registry for at least three days before opening a version-update pull request. The default needs no configuration, covers supported ecosystems on GitHub.com, and is planned for GitHub Enterprise Server 3.23. Security updates remain immediate.

That last distinction matters. GitHub has put a time gate in the update-bot path. It has not put the same gate around every package-manager command, every developer workstation, every CI resolver, or every other dependency bot. A repository can therefore receive fewer day-zero Dependabot PRs while still admitting day-zero package code through another path.

The new default is useful. It is not a complete supply-chain policy.

GitHub moved one control point

Dependabot’s cooldown was not invented this week. GitHub made the option generally available in July 2025, when teams had to choose and configure a minimum package age themselves. The July 2026 change turns a three-day wait into the baseline for version updates.

That shift changes the burden of action. Previously, a security-conscious team had to know the option existed, edit .github/dependabot.yml, choose a duration, and keep the policy consistent across ecosystems. Now the ordinary Dependabot version-update flow begins with a delay unless an operator changes it or opts out.

GitHub’s Dependabot options reference shows that the control can still be made more specific. Teams can set a default duration, assign different waits to semantic-version major, minor, and patch releases, and include or exclude named dependencies. The documented range is one to 90 days, with lists capped at 150 entries. Those controls shape when Dependabot proposes a version change. They do not inspect whether the package is benign.

This is a timing control, not an authenticity verdict. A three-day-old package has survived three days in public; it has not automatically proved its provenance, build process, maintainer identity, or runtime behavior. Time can create a window for maintainers, registries, scanners, and users to surface a bad release. It cannot guarantee that anyone will.

The distinction is familiar in other distribution failures. TECHi’s report on the Notepad++ updater supply-chain attack involved a different delivery path, but it illustrates the same systems lesson: protecting one handoff does not secure every route by which code reaches a machine.

Dependabot does not control the installer

Dependabot and a package manager act at different layers.

Dependabot watches a repository, evaluates available versions, and proposes changes. The package manager resolves dependency ranges, writes or reads a lockfile, downloads artifacts, and installs a dependency graph. A three-day delay at the first layer does not automatically become a three-day delay at the second.

Consider a developer who manually adds a package, a CI job that regenerates a lockfile, or another automation service that updates dependencies. None of those actions has to wait for a Dependabot PR. Their behavior is governed by the package manager and its configuration.

That makes version and default settings material.

The current npm install documentation defines a min-release-age control, measured in days, but its default is null. Unless a team or tool sets it, npm does not impose a release-age floor. npm also documents an important emergency behavior: if the age rule blocks a version that npm audit fix needs, npm keeps the vulnerable version, warns, and exits with a non-zero status. The safety control is visible, but the operator must decide how to handle the collision.

pnpm’s answer depends on the major version. The pnpm 10 settings reference sets minimumReleaseAge to zero by default. When configured, the rule is measured in minutes and applies to direct and transitive dependencies. The pnpm 11 reference changes the built-in default to 1,440 minutes, or one day. It also says the built-in default is non-strict for backward compatibility, while an explicitly configured rule is strict by default. A repository that upgrades pnpm can therefore change its supply-chain posture without touching Dependabot.

Yarn has made another choice. Its security documentation says Yarn 4.12 introduced an npmMinimalAgeGate that defaults to one day, with preapproved-package exceptions and a per-command bypass. That is still shorter than GitHub’s new three-day Dependabot default, but it operates where packages are resolved for installation.

These differences are not trivia. They define the gap between “our bot waited” and “our environment refused young code.”

A three-day wait changes risk, not truth

GitHub’s rationale is sound. A malicious or broken release often has a period during which downstream users, registry operators, and maintainers can react. Delaying a routine version PR means a repository is less likely to merge the release at the first available moment.

The mechanism has two practical benefits.

First, it reduces exposure to the most impulsive update path. Teams that merge routine Dependabot PRs after automated tests will no longer see those PRs for a version in its first three registry days. That gives external signals time to accumulate before the familiar green-check workflow begins.

Second, it can reduce update churn. A package that publishes a quick corrective release may move past the first version before Dependabot opens a pull request. Teams spend less review time on a version that was immediately superseded.

Neither benefit proves a package safe. A quiet package can remain malicious for longer than three days. A compromised maintainer may retain trusted credentials. A release can pass tests and still contain behavior that activates only under specific conditions. A registry timestamp says when a version became available, not whether its source, build, and artifact align.

The new default also does not replace lockfile review. A lockfile can make subsequent installs reproducible, but the first resolution still needs a policy. Nor does it replace artifact integrity, signed provenance where available, install-script controls, dependency ownership review, or runtime monitoring.

Automation can help with those tasks, but it cannot collapse them into one green badge. TECHi made a similar point when examining Microsoft’s AI security agents: automation is most valuable when its authority and handoff points are explicit.

Security updates need a separate fast lane

GitHub explicitly excludes Dependabot security updates from the new wait. A qualifying vulnerable dependency should still receive an immediate security-update pull request.

That is the right default because a known vulnerability reverses the timing problem. Waiting may reduce exposure to an untrusted new release, but it also prolongs exposure to a disclosed flaw. The ordinary update lane and the emergency patch lane should not share one blunt rule.

The complication appears when an install-time age gate is stricter than the bot’s security exception. Dependabot can open the security PR immediately, yet npm, pnpm, Yarn, or another resolver may refuse the new patched version because it is too young. A CI failure is preferable to silently weakening a policy, but only if the team recognizes the reason and has a controlled response.

A workable exception process is narrow and auditable. It should identify the exact package or version, record why the bypass is needed, keep the exception time-limited, and restore the normal rule after the fix is admitted. Disabling the age gate for the whole dependency graph turns an emergency door into a permanent opening.

Tests also need to distinguish policy failures from code failures. A resolver rejecting a young security patch is not evidence that the patch is broken. It is evidence that two safety controls disagree. The pipeline should expose that disagreement clearly enough for a human to resolve it.

Teams need one policy across both layers

The useful response to GitHub’s change is not to copy the number three into every configuration file. It is to map the dependency path and decide which layer owns each decision.

A strong review starts with six checks:

• Confirm which repositories use Dependabot version updates and whether any cooldown overrides already exist.
• Record the package manager and exact major version used on developer machines and in CI. Defaults differ across npm, pnpm, and Yarn, and they can change between releases.
• Decide whether the install layer should match the three-day Dependabot window, use a shorter interval, or enforce a stricter period for selected dependencies.
• Define a narrow security-patch exception before the first urgent fix collides with the age gate.
• Verify that CI re-applies the install policy to lockfile changes rather than trusting that the pull-request author used the same local settings.
• Keep provenance, integrity, install-script, and runtime controls separate. A release-age test should not be treated as a substitute for them.

The correct duration depends on the repository. A fast-moving application may accept a shorter window for a small set of closely watched packages. A stable service with a conservative release cadence may choose a longer wait. Internally maintained packages may need explicit exceptions, especially when a public-registry age rule would otherwise slow coordinated deployments.

What matters is consistency. A Dependabot delay that disappears during manual installation is a dashboard improvement, not an enforced boundary. An install-time gate with no emergency path can turn a disclosed vulnerability into an operations incident. The policy must cover routine updates, manual changes, transitive resolution, and urgent fixes as separate cases.

GitHub’s broader role in developer automation makes these defaults consequential. Its work around MCP connectivity with Microsoft is another example of the platform becoming a control surface for tools that act on repositories. As that surface grows, teams need to ask not only what an automation can do, but where its authority stops.

What the new default does not settle

The announcement leaves several questions for operators to watch.

GitHub Enterprise Server users need to confirm the behavior when 3.23 arrives rather than assume GitHub.com timing applies to an earlier server release. Organizations with existing cooldown settings should verify whether their explicit rules take precedence exactly as intended. Teams using multiple ecosystem entries in one Dependabot configuration should check each entry, not infer coverage from one successful pull request.

Documentation also needs to catch up with behavior. At the time of this announcement, parts of GitHub’s reference material still described immediate consideration of new versions as the default. The newer dated announcement is the authoritative change record, but a stale sentence can mislead an operator auditing configuration. GitHub should reconcile that quickly.

The most useful evidence will come after deployment: fewer immediate version PRs, fewer quickly superseded updates, and no material increase in security-patch delay. If teams still install young packages through manual or CI paths, the Dependabot metric alone will overstate the protection.

That is the invalidator for the optimistic reading. If organizations treat the new default as complete supply-chain protection, the control has failed at the policy level even if Dependabot behaves exactly as designed.

The practical verdict

GitHub has improved the baseline. A three-day default inserts useful friction into a common automated update path, preserves an immediate lane for known security fixes, and gives operators room to tune or opt out.

The improvement is narrower than its headline. Dependabot controls when it proposes a routine version change. Package managers control what code is eligible to resolve and install. npm, pnpm, and Yarn do not share one default, and version changes can alter that posture.

The safe interpretation is precise: Dependabot now waits. Your dependency policy still has to decide whether everything else does.