We should all be using dependency cooldowns

Programming, philosophy, pedaling.

---

November 21, 2025

Tags: OSS, security

---

TL;DR: Dependency Cooldown is a free, easy and simple way incredibly effective
way to reduce vast majority of open source supply chain attacks. More individual projects should implement cooldowns for their dependencies (through tools like Dependabot and Renovate), and the packaging ecosystem should invest in first-class support for cooldowns directly in their package managers.

---

“Supply chain security” is a serious problem. this is also seriously exaggeratedPartly because dozens of sellers have a vested financial interest in convincing you that they are their Ready underlying problem ^{(1) is correct, and (2) is worth your money.}

The thing to consider is that most open source supply chain attacks have the same basic structure:

1. An attacker compromises a popular open source project, usually through stolen credentials or a CI/CD vulnerability (such as “pwn requests” in GitHub actions).

2. The attacker makes malicious changes to the project and uploads it somewhere maximum impact (PYPI, NPM, GitHub releases, &c., depending on the target).

   on this point, the clock has startedBecause the attacker has gone among the public.

3. Users pick up a compromised version of the project through the lack of automatic dependency updates or dependency pinning.

4. Meanwhile, the above vendors are scanning public indices as well as client repositories for signs of compromise, and providing alerts upstream (e.g. on PyPI).

   In particular, sellers are encouraged To report faster and louder upstream, as this increases the perceived value of their services in a crowded field.

5. Remove or disable the upstream (PyPI, npm, &c.) compromised package versions.

6. End-user troubleshooting begins.

The main thing to see is that the difference between (1) and (2) can be very large.
^{(week or month), while the difference between (2) and (5) is generally very small: hours or days. This means that, once the attacker moves into the actual exploitation phase, their window of opportunity The damage caused is quite limited.}

We can see this with several major supply chain attacks over the last 18 months^,

attack	About. window of opportunity	Reference
xz-utils	≈ 5 weeks	Source
Ultralytics (Step 1)	12 hours	Source
Ultralytics (Step 2)	1 hour	Source
tj-verbs	3 days	Source
chalk	<12 hours	Source
nx	4 घंटे	Source
rspack	1 hour	Source
num2words	<12 hours	Source
kong entry controller	≈ 10 days	Source
web3.js	5 hours	Source

(Of course, each of these attacks has significant downstream impacts, but only
Inside Their window of opportunity. Each subsequent agreement, like Shai-Hulud, represents New Windows of opportunity where attackers regrouped and advanced next Set of compromised credentials.)

What I mean by this is: some windows of opportunity are larger, but majority
One of them is less than a week old. As a result, ordinary developers can avoid bulk by setting up such attacks cooling On their dependence.

cooling

A “cooldown” is exactly what it sounds like: a window of time between when the dependency is published and when it is deemed suitable for use. Dependencies are public during this window, meaning “supply chain security” vendors can work their magic while the rest of us wait for any problems to occur.

I Love Cooling for several reasons:

• As above, they are empirically effective. they won’t stop All attackers, but they to do Interrupt most of the high-visibility, large-scale impact supply chain attacks that have become more common.

• They unbelievably Easy to implement. Furthermore, they are virtually free
  To apply in most cases: Most people can use Dependabot’s functionality, Renovate’s functionality, or the functionality directly in their package manager^,

  That’s how simple it is at Dependabot:

  1
  2
  3
  4
  5
  6
  7
  8
  9
  
  
  
    version: 2
  
    # update once a week, with a 7-day cooldown
    - package-ecosystem: github-actions
      directory: /
      schedule:
        interval: weekly
      cooldown:
        default-days: 7
  
  
  
  
  
  

  (Rinse and repeat for other ecosystems as needed.)

• cooling enforce positive behavior From supply chain security vendors: Vendors are still encouraged to quickly discover and report attacks, but are No Encouraged to emit large amounts of blogspam about “critical” attacks on largely underfunded open source ecosystems.

Conclusion/Mixed Thoughts

In the very small sample given above, 8/10 attacks had a chance of lasting less than a week. Setting a cooldown of 7 days could have prevented most of these attacks from reaching end users (and caused knock-on attacks, of which there were many). Extending the cooldown to 14 days would have prevented all but 1 of these attacks^,

Cooldowns, obviously, are not a panacea: some attackers Desire Avoiding detection, and delaying the addition of potentially malicious dependencies by a week or two does not fundamentally change the fact that supply chain security is a
social trust The problem, not purely technical. Still, an 80-90% reduction in risk through free and easy technology seems hard to beat.

Related to the above, it’s unfortunate that cooldowns aren’t baked in. directly
More in the packaging ecosystem: Dependabot and Renovate are great, but
even better This will happen if the package manager itself (as a source of ground truth) can directly enforce cooldowns (including dependencies not introduced or bumped through the automated flow).

---

---