Skip to content
Tech News
← Back to articles

Dependency cooldowns turn you into a free-rider

read original get Dependency Management Toolkit → more articles
Why This Matters

Dependency cooldowns aim to mitigate supply chain attacks by delaying adoption of new releases, but they largely rely on free-riding and do not address the root security issues. While they may offer modest benefits, they impose significant costs on the broader ecosystem and depend on widespread coordination across multiple package managers. This approach raises concerns about fairness and effectiveness in securing software supply chains.

Key Takeaways

Dependency cooldowns turn you into a free-rider

Against dependency cooldowns as a response to supply chain attacks

Dependency cooldowns are suddenly in vogue. They have quite quickly become widely recommended and it looks like they're going to get fast-tracked into the basket of "industry standard best practices".

The hope is that by just waiting N days after release before adopting a new version - instead of adopting it immediately - any surreptitiously inserted hacks will have been discovered by someone else and the bad release "yanked" (or removed). And this does look, on the surface, like an effective approach: most supply-chain attacks are indeed detected within a few days.

But while dependency cooldowns are individually modestly - and only modestly - beneficial for those observing them, they place substantial costs onto everyone else. And they don't address the core issue: publishing and distribution are different things and it's not clear why they have to be coupled together.

Dependency cooldowns - the weakness of individual action

Frankly, dependency cooldowns work by free-riding on the pain and suffering of others. Fundamental in the dependency cooldown plan is the hope that other people - those who weren't smart enough to configure a cooldown - serve as unpaid, inadvertent beta testers for newly released packages. If there's a problem, those poor saps get hacked, everyone notices that they got hacked, and the problematic package/executable is yanked before the dependency cooldowners' thresholds are reached.

Even if this worked for individuals - I think it's impossible to sustain it as a sensible or moral system for the entire ecosystem to observe.

Another issue is that dependency cooldowns require a lot of different people to do work. Python has multiple package managers at this point (how many now? 8?). All must implement dependency cooldowns. And every project ever created has to configure the cooldown - which often isn't particularly easy or clear given that package managers often choose completely different ways to do it.

But in fact, even the cooldowners suffer. It's extremely easy to accidentally circumvent the cooldown that you have sagely configured in your project file. In Python, a single, personal, pip install litellm outside your project config would have recently gotten you hacked. So the cooldown approach is not actually complete, nor particularly safe.

... continue reading