Dependency Cooldowns Block 80% of Supply Chain Attacks

A new analysis reveals that 80% of major supply chain attacks from the past 18 months could have been blocked with one simple setting: a 7-day dependency cooldown. Security researcher William Woodruff examined ten high-profile attacks including tj-actions, Ultralytics, and rspack, finding that most had exploit windows measured in hours, not weeks. The fix costs nothing and takes five minutes.

What Are Dependency Cooldowns?

A cooldown is a waiting period between when a package is published and when your automated tools will update to it. During this window, the package exists publicly – security vendors scan it, the community reviews it, and any malicious code gets flagged. You simply wait out the danger zone.

The logic is straightforward. Supply chain attacks follow a predictable pattern: an attacker compromises an open source project, uploads malicious code, and the clock starts ticking. Security vendors race to detect and report. Upstream maintainers pull the bad version. The entire exploitation window is typically hours or days.

The Data Is Damning

Woodruff compiled timing data for ten prominent attacks:

• Ultralytics (phase 2): 1 hour
• rspack: 1 hour
• Nx: 4 hours
• web3.js: 5 hours
• chalk: under 12 hours
• num2words: under 12 hours
• Ultralytics (phase 1): 12 hours
• tj-actions: 3 days
• xz-utils: 5 weeks (the outlier)
• Kong Ingress Controller: 10 days

Eight of ten attacks had windows under one week. A 7-day cooldown would have blocked them all. Bump that to 14 days and you catch nine out of ten – only the sophisticated xz-utils attack, which involved months of social engineering to gain maintainer trust, slips through.

Implementation Takes Five Minutes

For projects using Dependabot, add this to your configuration:

version: 2
- package-ecosystem: github-actions
  directory: /
  schedule:
    interval: weekly
  cooldown:
    default-days: 7

For Renovate, it is equally simple:

{
  "minimumReleaseAge": "7 days"
}

That is it. Zero cost. Free tier. Works immediately.

The Uncomfortable Truth About Security Vendors

Here is where Woodruff gets spicy: supply chain security is “seriously overhyped,” in part because vendors have financial incentives to frame every attack as existential. They need you scared enough to buy their products.

Cooldowns flip this dynamic. Vendors still compete to detect attacks quickly – that is their value proposition – but the urgency falls on them, not you. They race to flag malicious packages during your cooldown window while you sip coffee and wait. If they succeed, the attack never reaches your codebase. If they fail, well, their product is not worth much anyway.

The Limitations Are Real

Cooldowns will not stop everything. The xz-utils attack ran for five weeks because the attacker played a long game, building trust over years before inserting the backdoor. No amount of waiting helps when the maintainer is the adversary.

More fundamentally, supply chain security is a social trust problem masquerading as a technical one. We trust that package maintainers are who they say they are, that their credentials have not been stolen, that their CI/CD pipelines are not compromised. Cooldowns add a buffer but do not solve the underlying issue.

The real ask: package managers should build cooldown support natively. Dependabot and Renovate are great, but the package manager itself – npm, pip, cargo – should enforce this at the source. Until then, use the tools you have.

The Bottom Line

An 80-90% reduction in supply chain attack exposure. Five minutes of configuration. Zero dollars spent. The math is not complicated. If you are not using dependency cooldowns, you are leaving free security on the table.