What changed and why now
On July 14, GitHub flipped a supply-chain safeguard from opt-in to default. Dependabot version updates now wait until a new release has been available on its registry for at least three days before opening a pull request. The behavior requires no configuration and applies across all supported ecosystems on github.com, with GitHub Enterprise Server picking it up in release 3.23. This is the same minimum-package-age control that became generally available as an optional setting in July 2025, now promoted to a default because most teams never turned it on. Making the safer behavior automatic is the pattern we keep seeing across developer tooling as supply-chain risk climbs the priority list.
The rationale is stated plainly in GitHub's own notes: new releases are a common entry point for supply chain attacks, where a compromised or broken version can reach your dependency updates before maintainers and the community have caught it. A short delay gives that signal time to surface, so a team is less likely to merge a bad release the moment it ships. This mirrors the wave of npm and registry incidents where malicious versions were caught within hours or days of publication. A three-day buffer would have blunted several of those attacks at the moment they mattered, which is precisely the window this default is designed to cover.
The exemption that keeps it safe
The design detail that makes this workable is the carve-out for security updates. The cooldown applies only to version updates, the routine bumps that keep dependencies current. Security updates, the ones Dependabot opens in response to a known advisory, still open immediately. That separation resolves the obvious objection, because a blanket delay on all updates would leave known-vulnerable dependencies sitting in production for three extra days while the fix waited in a queue. By splitting routine maintenance from urgent remediation, GitHub gets the benefit of the cooldown without slowing the response to disclosed vulnerabilities, which is the tradeoff most security teams would have asked for.
Teams that want different behavior retain full control through the cooldown option in the .github/dependabot.yml file. You can widen the window for high-risk ecosystems, shorten it where you have strong internal scanning, or opt out entirely for repositories where speed matters more than the buffer. We would treat the three-day default as a sensible floor rather than a ceiling, and organizations with mature internal vetting might extend it further for their most sensitive services. The point is that the safe behavior now happens by default, and any deviation from it becomes an explicit, reviewable decision recorded in configuration rather than an oversight.
The gap leaders should not miss
The most useful analysis of this change is also the most sobering. Writing at TECHi, chief executive Jazib Zaman argued that the cooldown is a timing control rather than a complete security guarantee, and he pointed at what he called an install-layer gap. His framing is worth quoting: a three-day delay at the first layer does not automatically become a three-day delay at the second. Dependabot controls when it proposes a routine version change, but package managers control what code is eligible to resolve and install. A cooldown on the pull request does nothing about a transitive dependency that a lockfile resolution pulls in during a build.
That distinction is where governance either holds or quietly fails. As Zaman put it, 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. His summary lands the point: Dependabot now waits, and your dependency policy still has to decide whether everything else does. For a CTO, the takeaway is to map the cooldown onto the rest of the install pipeline, including npm, pnpm, and Yarn resolution behavior, and to confirm that the same delay philosophy is enforced where packages actually enter the build. The default is a genuine improvement, and it is one layer of several.
What this means for your pipelines
For most engineering organizations, the immediate effect is that a small class of risky automated merges simply stops happening, with zero effort required. That is the best kind of security change, because it improves the baseline for teams that were never going to configure the setting themselves. The cost is modest: routine dependency updates arrive three days later than before, which is immaterial for the vast majority of version bumps. Teams running tight release trains should check whether any workflow depends on same-day Dependabot pull requests, but that pattern is rare and usually a sign of a fragile process rather than a requirement worth preserving.
The broader signal is that platform defaults are becoming a primary security lever. GitHub has spent the past year shifting risky behaviors from opt-in to opt-out, from install-script handling to this cooldown, and the through-line is that most teams inherit whatever the platform decides. Engineering leaders should audit which of these defaults now apply to their repositories, because the security posture of an organization is increasingly set by upstream configuration choices rather than internal policy documents. We would use this change as a prompt to review the full Dependabot configuration, confirm the security-update exemption behaves as expected, and extend the same cooldown thinking to every layer where third-party code enters the build.
The trend line to track
This release fits a clear pattern of registry and platform operators adding friction between publication and consumption. Package cooldowns, staged publishing, and provenance attestation are all variations on the same idea: fast propagation of new code is convenient for maintainers and dangerous for consumers, and the tooling is finally rebalancing toward safety. For enterprise buyers, the practical question is whether their internal registries and mirrors implement equivalent delays, because a cooldown on github.com means little if an internal proxy pulls and caches the malicious version instantly. Consistency across the pipeline is what turns a collection of point features into an actual defense.
We expect more defaults to move in this direction, and the organizations that benefit most will be the ones treating supply-chain configuration as a first-class part of their platform. The three-day cooldown is a small, sensible change that will prevent real incidents at the margin, and it costs almost nothing to accept. The mistake would be to read it as a solved problem. The correct response is to accept the default, verify the exemption, and then do the harder work of extending the same delay discipline to the install layer, where Zaman correctly notes the real resolution happens. That is the difference between a checkbox and a policy.
