Dependency-cooldown discussions warm up

Efforts to introduce malicious code into the open-source supply chain have been on the rise in recent years, and there is no indication that they will abate anytime soon. These attacks are often found quickly, but not quickly enough to prevent the compromised code from being automatically injected into other projects or code deployed by users where it can wreak havoc. One method of avoiding supply-chain attacks is to add a delay of a few days before pulling updates in what is known as a "dependency cooldown". That tactic is starting to find favor with users and some language ecosystem package managers. While this practice is considered a reasonable response by many, others are complaining that those employing dependency cooldowns are free-riding on the larger community by letting others take the risk.

Everybody cool down

In November 2025, William Woodruff published a blog post advocating the use of dependency cooldowns to mitigate supply-chain attacks that affected open-source projects. In the post he looked at ten of the prominent supply-chain attacks that had taken place in 2024 and 2025, including the XZ backdoor, the attack on the Python ultralytics package, and the npm debug/chalk supply-chain attacks.

Each attack had the same basic structure: attack preparation, window of opportunity, detection of the attack, disabling of the compromised package, and then remediation. He said that the key thing to observe is that "once the attacker has moved into the actual exploitation phase, their window of opportunity to cause damage" is usually less than a week before the attack is detected by security vendors or other researchers.

Therefore, developers could avoid the bulk of the attacks by instituting a cooldown on dependencies of seven days. Woodruff also encouraged open-source projects to adopt cooldowns using dependency-management tools like Dependabot, and for packaging ecosystems to "invest in first-class support for cooldowns directly in their package managers". While not a perfect solution, he said, it would be a major improvement:

Cooldowns are, obviously, not a panacea: some attackers will evade detection, and delaying the inclusion of potentially malicious dependencies by a week (or two) does not fundamentally alter the fact that supply chain security is a social trust problem, not a purely technical one. Still, an 80-90% reduction in exposure through a technique that is free and easy seems hard to beat.

His blog post appeared on Hacker News, Lobste.rs, and elsewhere; it caught quite a few people's attention. In December, he published a follow-up that addressed common questions and objections.

For example, some people asked if cooldowns would be self-defeating. If everybody adopts them, then wouldn't the window of opportunity just include the cooldown period, thus negating the benefits? Woodruff countered with the observation that there are parties in the system—security vendors, open-source maintainers, and the package-index maintainers—with strong incentives to detect attacks before they reach users. In addition, universal adoption of cooldowns was "clearly not realistic: there are always going to be people who live at the edge. If those people want to be the proverbial canaries in the coalmine, that's their prerogative!"

He also listed a number of language ecosystems that had added or were exploring support for cooldowns in some of their tools, including Go, JavaScript, Python, and Rust. In March, Andrew Nesbitt did another round-up of the state of cooldown support in language package managers, dependency-update tools, and so forth. He looked at the package managers that currently support cooldowns, are in the process of adding support, as well as ecosystems where he couldn't find any evidence of plans to implement the feature. He noted that cooldowns are called "at least ten different configuration names across the tools that do support it", which made writing about the topic nearly as hard as the implementation of cooldowns in projects with multiple languages.

On April 6, the Python Package Index (PyPI) published an incident report following a supply-chain attack that affected the LiteLLM and Telnyx packages. The report included a section on how developers could protect themselves, which included dependency cooldowns as one way to avoid malware.

Wrong approach

On April 13, Cal Paterson published an argument against dependency cooldowns. He worried that the practice was being "fast-tracked into the basket of 'industry standard best practices'". It might look like an effective approach on the surface, he said, but cooldowns do not address what he felt was the core issue: "publishing and distribution are different things and it's not clear why they have to be coupled together".

He had a few complaints about cooldowns; for example, he argued that the cooldowns work "by free-riding on the pain and suffering of others" by treating those who grabbed updates right away as "unpaid, inadvertent beta testers for newly released packages". Even if the system works for individuals, he called it impossible to sustain "as a sensible or moral system" for an entire ecosystem to observe. Paterson also pointed out that it would require great effort on behalf of people who have to implement cooldown features:

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.

Upload queues

Instead of the cooldown approach, he argued that "the obvious alternative" was an upload queue: "Make new packages wait some period of time after they are published, before they are distributed." Publication would mean sending a release (a tarball, Ruby gem, Python wheel, etc.) to the central index for distributing packages. Distribution would be when the index begins serving packages to the public.

There would be an interim period where the package could be subject to automatic security scans, reviewed by the public, even downloaded by willing test subjects, but not widely distributed. He pointed to how Debian handles package distribution as a successful example of upload queues:

Debian stable effectively is an upload queue - the whole point is that it's made up of older releases that have already been subject to a QA process. The upload queue for language-oriented package managers need not be so comprehensive - but I do think there is something to take from the Debian example.

Debian, of course, has actual upload queues such as the new queue, but his larger point still stands. Upload queues not only provide more time to examine releases; the practice would also reduce the value of stealing release credentials. Many of the supply-chain attacks involved more than the insertion of malicious code, they also involve theft of release credentials so that the attacker can perform an unauthorized release of the package. If a package has to sit around for a few days, he said, the value of stealing release credentials goes down.

The wait period would serve to reduce or remove what he called "the entirely unnecessary element of surprise" when a new package release appears. Users would get advance notice of new releases.

And it's not just users who need advance knowledge. The upload queue period is also a good time to notify maintainers, to make sure that they are all indeed aware of the forthcoming release. "Notification: Release 2.4.1 has entered the upload queue" would be just the wake-up call required to avert a supply chain attack getting rolled out in many cases.

He acknowledged that cooldowns were useful in some situations and admitted he doesn't always want to be the first to upgrade: "the family TV set-top box is mission critical infra in my household". But he was against dependency cooldowns becoming community best practices. "I don't want my security to depend on someone else getting hacked first".

Paterson's post also picked up steam and made it to discussion sites. In the Lobste.rs thread about his post, Woodruff responded that Paterson's response was "directionally accurate" but missed a key part of the argument. "You're not free-riding on other maintainers, but instead on a number of 'supply chain security' companies that are financially incentivized to find malware as quickly as possible". He also agreed that upload queues were more desirable, and that instant distribution was a problem, but "it's also not something that's easy to take away now that it's been established as the norm for publishing language specific packages".

For now, since package indexes like PyPI have not announced plans to implement upload queues, users will need to rely on dependency cooldowns as a way to avoid being the victim of a supply-chain attack. It will be interesting to see what kind of progress is made over the next few years in implementing dependency-cooldown tooling across language ecosystems. Of course, attackers are also going to be watching and adapting their strategies as well—scanning for vulnerabilities during a cooldown period may catch many attempts to slip in malware, but it would be optimistic to bank on cooldowns working all the time.

[Thanks to Paul Wise for the topic suggestion.]

Note: you can avoid this step in the future by logging into your LWN account.