GitHub just made dependency updates a little slower. That may be the safer default.

Technology reporting

GitHub changed Dependabot version updates: instead of opening a pull request as soon as a package release appears, Dependabot now waits until that release has been available in its registry for at least three days. The change, announced in GitHub’s changelog on July 14 and reflected in its docs today, applies by default to version updates across supported ecosystems on GitHub.com. GitHub says it will also arrive in GitHub Enterprise Server 3.23.

That sounds like a tiny product tweak. It is a quiet admission that “latest” is no longer a neutral word in software supply chains.

For years, dependency bots were optimized around speed: find an outdated library, open a pull request, run tests, merge if green. That workflow helped teams escape stale dependencies. But the same automation can also widen blast radius. If an attacker compromises a maintainer account, publishes a poisoned package, or ships a broken patch under a familiar name, the fastest consumers are often the most exposed. A bot can notice the new version before maintainers, registries, scanners, or the wider community have time to flag trouble.

GitHub’s answer is not a new scanner or a magic trust score. It is a timer.

What changed

Dependabot now applies a default three-day cooldown to version updates. GitHub’s docs say “a new version is not considered for a version update until 3 days after its release.” The default requires no repository configuration. It applies to version updates, not to security updates, so Dependabot security update pull requests are still supposed to open immediately when GitHub has an applicable vulnerable-dependency fix.

The distinction matters. A version update is ordinary maintenance: moving from one available version to a newer one because the dependency is behind. A security update is tied to a known vulnerability alert. GitHub is slowing the former, not the latter.

Teams can override the behavior in Dependabot configuration. GitHub’s documented cooldown option lets maintainers set a default number of cooldown days, define different windows for major, minor, and patch updates where semantic versioning is supported, and use include or exclude lists for particular dependencies. The docs say those lists can contain up to 150 entries and support wildcards. If a dependency appears in both lists, the exclude rule wins, meaning it is updated immediately rather than held by the cooldown.

The supported package-manager list is broad: GitHub’s docs include npm and Yarn, pip, Maven, Gradle, Go modules, Cargo, Docker, GitHub Actions, Terraform, OpenTofu, NuGet, Helm, Swift, Bun, Deno, uv, vcpkg, and others. The default cooldown is documented for all listed managers; semantic-version bump controls are narrower because not every ecosystem maps cleanly onto SemVer.

How it actually works

Dependabot still checks for updates according to the schedule in a repository’s Dependabot file. The new behavior adds a release-age gate between “a newer version exists” and “open a pull request.” If a dependency’s newest release falls within the configured cooldown period, Dependabot skips that dependency for now. Once the cooldown has passed, Dependabot resumes normal update behavior and applies the repository’s configured versioning strategy.

That is a deliberately boring mechanism, which is why it is useful. It does not need to classify every malicious package on day one. It simply avoids being first in line.

A cooldown can help in several common failure modes. If a package release is broken, early adopters will usually report failed builds or runtime regressions. If a maintainer account is hijacked, registries and security researchers may remove or flag the package within hours or days. If malware is discovered through dynamic analysis, static scanning, or community review, the signal needs time to propagate. The new default gives that signal a chance to exist before automation proposes the upgrade.

But the timer is not a security boundary. A malicious release can survive three days. A compromised maintainer can publish a plausible patch and wait. A targeted package can be crafted to behave benignly in common sandboxes and badly in production. A cooldown lowers the chance of instantly merging fresh poison; it does not prove a delayed release is safe.

Does the evidence show it matters?

The case that this matters is strong. The case that three days is the perfect number is not yet proven publicly.

The strong part is the threat model. Open-source package registries are production infrastructure now. A modern service can include hundreds or thousands of direct and transitive dependencies, and many teams rely on automated pull requests to keep that graph moving. OpenSSF’s Package Analysis project exists because malicious behavior in open-source packages is common enough to justify automated behavioral analysis across repositories. The project describes looking for signals such as what files packages access, what network addresses they connect to, what commands they run, and whether previously safe software starts behaving suspiciously.

The standards world points in the same direction. NIST’s Secure Software Development Framework treats software supply-chain risk and vulnerability management as core development practices. SLSA focuses on provenance, build integrity, and the trustworthiness of artifacts that organizations consume. Neither framework says “wait three days and relax.” The larger principle is simpler: dependency intake needs controls, not just speed.

The weaker part is measurement. GitHub has not published, in the changelog item, an independent benchmark showing that a three-day default prevents a quantified share of malicious or broken dependency updates. It also has not shown a public before-and-after study of false negatives, delayed fixes, or developer time saved. The responsible conclusion is narrower: the default is directionally sensible because many supply-chain incidents are discovered shortly after release, but its exact effectiveness is unverified from public evidence.

Who is affected

The most affected group is not security specialists. It is everyday maintainers who enabled Dependabot to reduce maintenance drag and then mostly stopped thinking about it.

Small teams may notice fewer immediate version-update pull requests, especially on fast-moving JavaScript, Python, container, and GitHub Actions dependencies. Platform teams may need to explain why a just-released version does not appear in a Dependabot PR the same day. Organizations using GitHub Enterprise Server should watch the GHES 3.23 rollout.

Security teams get a cleaner default but also a new policy question: which dependencies deserve a longer cooling-off period, and which should bypass it? A low-level web framework, CI action, package-manager plugin, or runtime library may deserve stricter intake than a development-only formatting tool. On the other hand, a dependency used to ship urgent operational fixes may need a shorter delay or an explicit exclusion.

What developers and operators should do

First, do not opt out reflexively. If your repository uses Dependabot version updates, treat the new default as a baseline safety rail, especially for dependencies that are not carrying a known vulnerability fix.

Second, review configuration instead of assuming the default matches your risk. Identify packages where freshness is operationally important, packages where compromise would be especially dangerous, and packages where updates are mostly noise. Use cooldown rules to make those distinctions explicit. If a direct production dependency often ships urgent non-advisory fixes, consider whether it belongs on an exclusion list. If a dependency is high-risk and rarely urgent, consider a longer window.

Third, keep security updates separate in your mental model and in review process. GitHub says the cooldown does not delay Dependabot security updates. That helps, but only when the vulnerability is known to the advisory system and maps cleanly to your dependency. Teams still need dependency review, lockfile discipline, CI tests that exercise real behavior, and a way to roll back quickly.

Fourth, do not confuse delayed automation with provenance. A package that is three days old can still be malicious. Use signed releases and provenance where ecosystems support them, pin GitHub Actions by commit SHA for sensitive workflows, restrict install scripts where practical, and route packages through a controlled artifact repository if the risk justifies it. The cooldown buys time; it does not inspect the package for you.

Finally, teams using other dependency bots should copy the idea, not necessarily the exact number. The broader operating principle is simple: automation should not make your production dependency graph the first test environment for the internet.

The most interesting thing about GitHub’s change is how modest it is. No grand AI claim, no magic shield, no benchmark theater. Just a three-day pause in a system that used to reward immediacy. In 2026, that counts as infrastructure maturity.

Sources

• GitHub Changelog: “Dependabot version updates introduce default package cooldown”
• GitHub Docs: Dependabot options reference
• GitHub Docs: Dependabot version updates
• OpenSSF Package Analysis project
• NIST SP 800-218: Secure Software Development Framework
• SLSA v1.1: About SLSA

---

Shadowfetch is a technology publication. Explore Shadowfetch Linux — our own Linux build — and the Shadowfetch apps on the App Store.