By ByteBot
GitHub changed how Dependabot works on July 14, 2026. The update tool now enforces a three-day default waiting period before opening any version update pull request. No opt-in required. If your repo uses Dependabot version updates, you already have it. The stated goal is to slow down supply chain attacks. Whether three days actually accomplishes that is a more complicated question.
What Changed
Previously, Dependabot would open a PR the moment a new release appeared on its registry. Now it waits. The bot checks that a release has been publicly available for at least three days before proposing an update.
The change rolled out immediately to all repos on github.com. GitHub Enterprise Server gets it in version 3.23. No configuration is required to get the three-day window — it is the new default for every repo using Dependabot version updates.
One important carve-out: security updates are fully exempt. If a CVE drops and Dependabot has a patch lined up, it opens the PR immediately. The cooldown applies only to routine version bumps, not vulnerability fixes. That is the right call.
The Rationale and Where It Gets Complicated
GitHub’s logic is straightforward: give the community time to detect malicious releases before they reach your codebase. A compromised package hitting npm at midnight could be flagged by registry scanners, spotted by the maintainer, or reported by another developer before your Dependabot PR shows up three days later.
It is a reasonable idea. But the Hacker News discussion thread (125 comments) surfaced the obvious counterargument almost immediately: any attacker worth worrying about can just wait. Malware can be written to sit dormant for a week, a month, or longer before activating. The xz-utils backdoor (CVE-2024-3094) involved two years of trust-building before the malicious commit landed. A three-day cooldown would not have caught it.
The most dangerous supply chain attacks are not rushed. They are patient. And patient attackers can outlast any cooldown window GitHub sets.
The Gap No One Is Talking About
There is a structural limitation that rarely gets mentioned: Dependabot operates at the PR-proposal layer. It does not control how packages get installed.
When a developer runs npm install locally, npm does not know about Dependabot cooldown. When a CI job regenerates a lockfile, it can pull day-zero packages regardless. Package managers have their own defaults and they vary significantly:
- npm: no minimum package age by default
- pnpm 10: zero wait by default
- pnpm 11: one day by default
- Yarn: one day by default
The cooldown does not close the install-layer gap. Any developer adding a dependency manually, any CI system refreshing its lockfile, any script running outside Dependabot control — all of those paths remain unprotected. One control point cannot secure the entire supply chain.
How to Configure It
The three-day default requires no action. If you want to customize it or opt out, add a cooldown block to your .github/dependabot.yml:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
cooldown:
default-days: 3
semver-major-days: 14
semver-minor-days: 7
semver-patch-days: 2
exclude:
- "internal-pkg"The Dependabot options reference has the full syntax. You can set different wait times by semantic version bump level, include or exclude specific packages by name with wildcards supported, and set the window anywhere from one to 90 days. Setting any value to zero effectively disables the cooldown for that category.
Keep It But Do Not Rely on It
The three-day cooldown is worth keeping. It adds a small friction layer at zero cost to your workflow. Unsophisticated attackers pushing fast-moving malware will occasionally be caught in that window. The GitHub Changelog announcement frames it correctly: it raises the bar, not eliminates the risk.
But do not let it become a false sense of security. The supply chain attacks that have caused real damage — xz-utils, the Lazarus Group npm payload chains, the self-replicating Shai-Hulud worm that hit 500 packages in 2025 — are not stopped by a three-day delay. They require artifact signing, provenance tracking, lockfile auditing, and runtime monitoring.
The cooldown is one layer in defense-in-depth. Treat it that way. Set reasonable values by semver bump level, exclude packages you control, and then build out the rest of your security stack.
