Dependency Update Cooldown
also called Release Age Gate, Minimum Release Age
Waiting a fixed number of days after a package release before automation proposes or merges it, so hijacked or broken versions are caught by the ecosystem first, with a fast lane for security fixes.
A bot opens and merges a patch update to a popular package an hour after release. The maintainer's account was compromised and the new version carries a payload. Every service that auto-merged it ships the payload before anyone has read the diff. A cooldown delays routine updates until a release has aged a few days, so the community, scanners and registry maintainers get first contact with a bad version.
Why it matters
Two risks pull in opposite directions. Slow updates leave known vulnerabilities in production (Log4Shell in December 2021 was being exploited within hours of disclosure). Instant updates deliver hijacked or broken releases at the moment of least scrutiny. Most malicious package versions are detected and pulled within days, often hours, so a short delay removes much of the second risk at little cost for ordinary updates.
Implementation patterns
- Minimum age in the update bot or package manager configuration: 3 to 7 days for routine updates, longer for packages with install scripts.
- Security fast lane: advisories rated critical or high bypass the cooldown, with a named reviewer who reads the diff and checks the advisory is real.
- Lockfiles with integrity hashes, so what was reviewed is what installs.
- Disable or review install scripts, the usual execution point of a malicious package.
- Monitor maintainer changes: an ownership transfer or a new publisher on a critical package is a trigger for manual review.
- Shrink the tree: fewer transitive dependencies reduce both the exposure and the update load.
Industry example
The 2018 event-stream incident is the documented case: a maintainer handed the project to a new contributor, who added a dependency (flatmap-stream) carrying an encrypted payload that targeted a specific cryptocurrency wallet's build. The malicious version was live for roughly two months before a developer noticed it, long enough for any unpinned install to pick it up. An age gate does not fully protect against a payload that stays dormant for weeks, which is why it is paired with hashes, reduced dependencies and install-script controls.
Failure scenarios
- Cooldown applied to security fixes, delaying a critical patch by a week.
- Cooldown without hashes: a version that was reviewed at day 5 can be replaced by a re-published artifact at day 6.
- Slow-burn payloads that wait out the cooldown.
- Bot disabled in frustration after too many pull requests, leaving the project unmaintained.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Cooldown of 3 to 7 days | Fewer hijacked versions installed | Routine fixes arrive late |
| No cooldown | Minimal patch latency | Exposure on release day |
| Manual quarterly updates | Reviewed changes | Large diffs and long vulnerable windows |
When not to use it
Do not delay critical security fixes for a package that is demonstrably being exploited; use the fast lane. A small service with few dependencies and a maintainer who reads release notes may not need the mechanism.
Interview question
Q: How would you set dependency update policy for 300 services?
What a strong answer covers: the two opposed risks; cooldown for routine updates; the security fast lane; hashes and lockfiles; install-script controls; monitoring maintainer changes; reducing the dependency tree; and measuring time-to-patch for critical advisories as the guardrail.
Quick check
Quiz: A critical advisory is published for a package you use. Does the cooldown apply? No; critical fixes use the fast lane with a human reviewing the diff.
Flashcard: Why do most malicious versions get caught? — Scanners and users find them within days, so a short delay avoids the first wave.