Tech News
← Back to articles

We should all be using dependency cooldowns

read original related products more articles

ENOSUCHBLOG

Programming, philosophy, pedaling.

Nov 21, 2025 Tags: oss, security

TL;DR: Dependency cooldowns are a free, easy, and incredibly effective way to mitigate the large majority of open source supply chain attacks. More individual projects should apply cooldowns (via tools like Dependabot and Renovate) to their dependencies, and packaging ecosystems should invest in first-class support for cooldowns directly in their package managers.

“Supply chain security” is a serious problem. It’s also seriously overhyped, in part because dozens of vendors have a vested financial interest in convincing your that their framing of the underlying problem is (1) correct, and (2) worth your money.

What’s consernating about this is that most open source supply chain attacks have the same basic structure:

An attacker compromises a popular open source project, typically via a stolen credential or CI/CD vulnerabilty (such as “pwn requests” in GitHub Actions). The attacker introduces a malicious change to the project and uploads it somewhere that will have maximum effect (PyPI, npm, GitHub releases, &c., depending on the target). At this point, the clock has started, as the attacker has moved into the public. Users pick up the compromised version of the project via automatic dependency updates or a lack of dependency pinning. Meanwhile, the aforementioned vendors are scanning public indices as well as customer repositories for signs of compromise, and provide alerts upstream (e.g. to PyPI). Notably, vendors are incentivized to report quickly and loudly upstream, as this increases the perceived value of their services in a crowded field. Upstreams (PyPI, npm, &c.) remove or disable the compromised package version(s). End-user remediation begins.

The key thing to observe is that the gap between (1) and (2) can be very large (weeks or months), while the gap between (2) and (5) is typically very small: hours or days. This means that, once the attacker has moved into the actual exploitation phase, their window of opportunity to cause damage is pretty limited.

We can see this with numerous prominent supply chain attacks over the last 18 months:

Attack Approx. Window of Opportunity References xz-utils ≈ 5 weeks Source Ultralytics (phase 1) 12 hours Source Ultralytics (phase 2) 1 hour Source tj-actions 3 days Source chalk < 12 hours Source Nx 4 hours Source rspack 1 hour Source num2words < 12 hours Source Kong Ingress Controller ≈ 10 days Source web3.js 5 hours Source

... continue reading