The golden hour problem
Most supply chain attacks share a common pattern: malicious code gets published to a package registry, and within hours it’s already been downloaded thousands of times before anyone notices. By the time security researchers flag the package or the registry removes it, the damage is done.
This is the golden hour of supply chain attacks: the window where attackers race to compromise systems before their malicious package gets detected and removed. They exploit the immediate-adoption culture of modern development. When a popular package releases a new version, CI/CD pipelines worldwide pull it automatically within minutes, giving attackers just enough time to compromise thousands of build systems.
Consider the Nx supply chain attack from August 2025: Malicious packages were published to npm at 22:32 UTC on August 26. NPM was alerted at 02:58 UTC and removed all affected versions within an hour. Total exposure window: roughly 4–5 hours. Yet in that brief period, thousands of developers had their secrets exfiltrated, including SSH keys, GitHub tokens, and API credentials. The malware even attempted to leverage local AI CLI tools for reconnaissance, a disturbing first in supply chain attacks.
There’s a remarkably simple countermeasure that breaks this attack model entirely: dependency cooldowns.
What are dependency cooldowns?
A dependency cooldown is exactly what it sounds like: a waiting period before your tooling accepts new package versions. Instead of immediately adopting version 1.2.4 when it’s published, you wait 5 to 10 days before considering it for your project.
This approach works because of simple economics. Attackers publishing malicious packages face a race against time. Registry security teams, automated malware scanners, and the security community are constantly scanning for suspicious packages. Most malicious packages get detected and removed within days, often hours. A 7-day cooldown means you never touch packages during their most dangerous period.
The math is compelling: if malicious packages are typically removed within 24–72 hours, even a 7-day cooldown gives you a comfortable safety margin. Organizations with cooldown policies during the Nx incident were simply never exposed since the malicious versions had been removed days before their pipelines would have considered them.
It’s important to be precise about what cooldowns solve: Cooldowns address version freshness risk, the risk of blindly adopting new, unvetted releases. They do not mitigate known vulnerability risk. Once a vulnerability is identified and a fix is published, the risk calculus flips: delay becomes the dangerous option.
From a business perspective, the Nx and Shai-Hulud incidents exposed thousands of build systems to credential theft. Even without assigning specific costs per compromised environment, incidents of this scale translate into massive organizational impact across response effort, recovery time, and long-term risk exposure. A cooldown policy costs nothing and would have prevented this entire class of attack.
Tool support
Several dependency management tools now support cooldowns natively:
Dependabot introduced the cooldown option in mid-2025, allowing you to specify minimum age requirements before version updates are proposed. You can configure different delays based on semantic version changes, with longer waits for major versions and shorter ones for patches. Dependabot’s cooldown applies only to routine version updates, not security updates, so CVE patches should still flow through promptly. See the Dependabot cooldown documentation for configuration details.
Teams should still periodically validate this behavior in their own repositories. Cooldown logic is applied at update runtime, and overly broad configuration or exclusions can silently suppress updates if not tested.
Renovate offers similar functionality through its minimumReleaseAge setting (previously called stabilityDays). Renovate creates branches for pending updates but marks them with a “pending” status check until the cooldown expires. If you have automerge enabled, updates won’t merge until they’ve aged sufficiently. A notable behavior change in Renovate 42: packages without a release timestamp are now treated as if they haven’t passed the cooldown period, which is safer than the previous behavior. The Renovate minimum release age documentation covers the configuration options.
In Renovate setups with broad package rules, security updates can still appear “pending” unless explicitly excluded from cooldown logic. For this reason, security-specific rules are strongly recommended.
pnpm added the minimum-release-age setting in version 10.16, which filters packages by publish date and automatically remaps dist-tags to versions that meet the age requirement. This preserves semantic version compatibility while enforcing your security delay.
For ecosystems without native cooldown support, lock files provide a manual alternative. Tools like Poetry, uv, or Go modules with go.sum pin exact versions, including transitive dependencies, so newly published releases are never pulled in implicitly. Even when updates are scheduled weekly or bi-weekly, the refresh is a conscious, explicit step: you update the lock file, review the diff, and only then accept newer versions. This creates a de-facto cooldown window, ensuring that dependencies must “age” until the next planned refresh instead of being adopted immediately after release. The key is treating dependency updates as a deliberate, reviewable activity rather than something that happens automatically in the background.
A common misconfiguration trap
One recurring failure mode I see in audits is teams enabling cooldowns, assuming they are “safe,” and then relaxing their active monitoring of security advisories. Cooldowns reduce exposure to unknown malicious releases. They do nothing for known vulnerabilities already present in your dependency tree.
Without active vulnerability alerting and triage, cooldowns can actually increase dwell time for exploitable CVEs. Cooldowns are a preventive control, not a detective one.
Transitive dependencies: the hidden risk
Here’s a point that’s easy to miss: cooldowns must effectively apply to your entire dependency graph, not just direct dependencies. A malicious package introduced as a transitive dependency can still reach production even if your direct imports are carefully curated.
Modern dependency update tools can account for this, when they are used with lockfiles and conservative update policies. Tools like Dependabot and Renovate operate on the resolved dependency graph, meaning updates (including transitives) are proposed via lockfile changes rather than silently flowing in. As long as lockfiles are committed and updates are gated, transitive dependencies won’t change unless you explicitly accept an update.
A dangerous anti-pattern is allowing floating transitive dependencies in production while only cooling down direct dependencies. This recreates the golden-hour problem one level down the graph, exactly where attackers increasingly aim.
If you rely on manual version pinning or ecosystems without strong lockfile enforcement, this safety net disappears. In those cases, you must regularly regenerate and review the full dependency graph (for example via mvn dependency:tree, pip-compile, or equivalent tooling) to detect unexpected transitive additions or version shifts.
Handling urgent security patches
Cooldowns work best when paired with an explicit security SLA, for example: critical dependency CVEs must be triaged within 24 hours and patched within 72.
Cooldowns should apply to routine updates, not emergency security patches. Dependabot explicitly excludes security updates from cooldown rules. Renovate allows you to force immediate updates for specific packages through its Dependency Dashboard or security-specific rules.
For emergency overrides, establish a clear process. The security team should approve bypasses with documented justification. Record all cooldown bypasses in your security log for audit purposes.
Such fast-tracked packages deserve additional scrutiny. Where feasible, perform manual or automated review of the delta: look for obfuscation, dynamic code execution, unexpected network access, or new persistence mechanisms. Once the normal cooldown period expires, re-verify that the package remains trustworthy.
What cooldowns don’t protect against
Let's be clear about the strengths and limitations.
Dependency cooldowns are effective against:
- Compromised maintainer accounts with short-lived malicious releases
- Automated malware injection and wormable release pipelines
They are not effective against:
- Typosquatting attacks using similar package names
- Long-term maintainer compromise
- Zero-day vulnerabilities where fixes must be applied immediately
In other words: cooldowns buy you time, not certainty. Use that time to let scanners run, advisories surface, and the community react. Then decide from a position of information, not urgency.
Cooldowns are one layer in a defense-in-depth strategy. Combine them with SBOM generation, vulnerability scanning using tools like Trivy or Grype, code signing verification, and regular dependency audits. I’ll cover code signing and attestation of dependencies in a dedicated post soon, so stay tuned.
Getting started today
Rule of thumb: Delay unknown updates by default, fast-track known security fixes deliberately.
If you take nothing else from this post, implement a 7-day cooldown on your automated CI/CD dependency updates this week. The configuration is minimal, the protection is immediate, and the risk reduction is real.
For teams worried about being “slowed down”: you’re likely already waiting days or weeks between dependency updates in practice. Cooldowns simply formalize this delay and make sure it applies consistently, including on that one rushed Friday afternoon deploy.
Attackers are counting on you to adopt their malicious packages immediately. Make them wait.
Building secure pipelines?
Adding security to CI/CD is easy to start and hard to get right. I help teams do it properly. More info: DevSecOps Pipeline Consulting.