In web applications under our maintenance, around ten pull requests open automatically each week for dependency version updates. If CI is green, you merge without reading the contents—this is common practice in the field, and not something to condemn. Even a few minutes per PR adds up when there are ten of them, and the vast majority are genuinely safe updates.
The danger is that when a malicious release slips into that “vast majority,” mechanical merging carries it straight into production along the shortest possible path. There is always a lag between a package being compromised and the community catching on to issue warnings. Merging during that time lag was the worst possible way to fail.
In July 2026, GitHub addressed this time lag.
The default became “wait three days after release”
Dependabot version updates now default to not opening a pull request until at least three days have passed since a new release was published to the registry. No configuration is required; this behavior applies if you take no action (Dependabot version updates introduce default package cooldown — GitHub Changelog).
There is one crucial distinction: this wait time applies strictly to version updates, while security updates continue to open pull requests immediately, just as before. Fixes for known vulnerabilities will not be delayed by three days. Confusing this leads to the misinterpretation that “this change dulls security responsiveness,” making it well worth clarifying upfront.
The cooldown duration can be customized. Using the cooldown option in .github/dependabot.yml, you can specify a range from 1 to 90 days, or disable it explicitly. The default simply shifted to three days; the freedom of choice remains.
Changes sharing the same philosophy are also advancing within language package managers, as discussed in Dependency cooldown in pip 26.1. “Not adopting new releases immediately” is increasingly becoming the default across ecosystems.
Why three days is sufficient
The rationale behind the three-day figure lies in the timeline of attacks. Package takeovers are at their most dangerous immediately after release. Distribution begins while no one has reviewed the code, and automated update pipelines deliver it straight to organizations. Conversely, once several days have passed post-release, the odds of someone noticing and raising the alarm rise substantially. Even in real-world npm worm incidents, the time between discovery and widespread alerts was brief (The Mini Shai-Hulud worm timeline).
In other words, this change does not enhance detection capabilities. Instead, it is designed so that you wait until the detection capabilities already existing in the world have taken effect. As a defense, it is understated, but exceptionally sound because it works at zero cost.
As a byproduct, the probability of encountering broken releases also drops. Because you can avoid releases that were yanked immediately or patched right away, update stability improves regardless of whether malicious intent was involved.
The layers that cooldown does not protect
Because this is easily overlooked, let us be explicit: these three days only delay the timing of when Dependabot opens a pull request. Which version the application actually installs is determined at a completely different layer.
This point was raised immediately after the change: if version constraints remain loose, dependency resolution during CI or deployment can pull in new versions directly (GitHub’s Dependabot Cooldown Has an Install-Layer Gap — TECHi). Even if pull requests wait three days, a hole opens in your defense if updates enter on day one through another avenue.
Therefore, there are two additional things you must verify.
First, is a lockfile committed to the repository, and does CI install strictly respecting it? This comes down to whether commands like npm ci that install strictly to the lockfile are used, or whether dependencies are re-resolved every time via npm install.
Second, are dependencies being refetched in build or deployment pipelines? In configurations that pull latest packages every time a container image builds, the newest versions enter regardless of Dependabot settings. The supply chain risks of CI/CD itself were discussed in Continuous audits of GitHub Actions.
Translating changes into maintenance operational agreements
Reflecting the changed default in your maintenance operational rules will make life easier later. The baseline approach is to treat each update type differently.
| Update type | Default behavior | Operational approach |
|---|---|---|
| Security updates | PR opens immediately | Review and merge with priority. Do not stall this pipeline |
| Version updates (patch/minor) | PR opens after a 3-day wait | Batch and process periodically. Require green CI |
| Version updates (major) | PR opens after a 3-day wait | Evaluate individually. Exclude from auto-merge |
The crucial element is separating security updates from version updates operationally. When both arrive in the same queue, teams become overwhelmed by sheer volume and treat everything identically. As long as you maintain a rule that “security updates are reviewed the same day,” the rest can be batched and handled weekly.
The consequences of neglect also deserve mention. If you accumulate updates, when a vulnerability fix is urgently needed, the version gap will be too wide to perform the upgrade cleanly. Halting updates is equivalent to rendering yourself unable to move during an emergency. Waiting three days is not halting updates, so please do not conflate the two. How unmaintained sites actually reach a dead end was covered in Case study: attacks on neglected websites.
Two things for clients to verify
If you outsource development or maintenance to an external vendor, asking the following two questions will clarify the state of operations:
“Are security updates and version updates handled differently?” If they are handled identically, one of them is being handled carelessly. If security updates are treated casually, it is hazardous; if version updates are, costs will inflate.
“Is a lockfile committed, and does CI use it?” While this seems like a technical question, it is the kind of inquiry that can be answered in a single sentence. If no clear answer is returned, responsibility for dependency management may not be assigned.
Does the scope of the maintenance contract include dependency updates? If so, what are the update frequency and decision criteria? Leaving these points ambiguous for years results in a situation where updates never occur despite the vendor ostensibly “maintaining” the system.
What to do this week: start with a one-line check
In your or your contractor's repository, open .github/dependabot.yml. If there is no mention of cooldown, the default three-day delay will apply moving forward. That means there is nothing you need to configure.
From there, check whether commands respecting the lockfile are used in CI configurations. If both pieces are in place, you are already capturing nearly the full benefit of this change.
Whether you want to consult on maintenance architecture including dependency update operations, or assess how readily existing systems can be upgraded, GleamHub offers support through our development, AI, and automation consultations. Because the optimal setup varies depending on your requirements, we provide customized quotes. Please reach out to us via Contact Us.
Sources
- Dependabot version updates introduce default package cooldown — GitHub Changelog
- The case for a cooldown: Why Dependabot now waits before issuing version updates — The GitHub Blog
- GitHub Introduces Default “Cooldown” Policy for Dependabot Version Updates — InfoQ
- Version updates now have a 3 day cooldown by default — dependabot/dependabot-core Discussion #15582
- GitHub’s Dependabot Cooldown Has an Install-Layer Gap — TECHi
