What is a dependency cooldown and why wait before updating?

A dependency cooldown is a rule that keeps a software project from adopting a freshly published version of an open source library until it has been public for a set time, anywhere from a few hours to a few weeks. Dependencies are the packages of code written by others that an application downloads from public registries such as npm for JavaScript or PyPI for Python. The risk arises when an attacker hijacks the account of someone who maintains a widely used package and publishes a version with malicious code inside: whoever updates right away installs it. Those versions are short-lived, though, and the pnpm documentation notes that the npm registry usually removes them within hours. Waiting gives researchers and registry operators time to catch them before they reach your build, the final package that ships to production. Renovate calls the same setting "minimum release age".

See also: Patch management · The process by which a company discovers, prioritizes, tests and installs security updates for its systems, measured in days of exposure.

How long to wait, and what should not wait

There is no standard duration: pnpm waits one day by default, GitHub's Dependabot applies three days to version updates, and Renovate uses 14 days as its example. The name caught on with a November 2025 post by William Woodruff, an engineer at Astral, the company behind uv. He compared ten known attacks, a sample he himself calls very small, and in eight the malicious version had been available for less than a week.

The same wait delays genuine fixes, though. That is why Renovate and Dependabot let security updates through immediately (those that close a known vulnerability, usually one with a CVE identifier); the wait applies to routine updates. This is where a cooldown meets patch management, which sets how urgently a flaw has to be closed. Woodruff also points out the flip side: once the exemption exists, announcing a vulnerability becomes a tempting way to skip the wait.

The dependencies of your dependencies

A project declares a few dozen libraries, but each one pulls in others, called transitive dependencies, that nobody chose. The bots that propose updates work only on declared dependencies, while the package manager (npm, pnpm, uv) resolves the whole tree. That is why the Renovate documentation recommends setting the wait in both the bot and the package manager: otherwise a brand-new version slips in through the side door, as a dependency of a dependency. The major package managers now support it under different names: min-release-age in npm, minimumReleaseAge in pnpm and exclude-newer in uv.

An enterprise example

A company builds an internal assistant and uses litellm, a Python library that offers one interface to several language model providers. In 2026 compromised versions of litellm appeared on PyPI: according to PyPI's incident report, 2 hours and 32 minutes passed between upload and quarantine, long enough for them to be downloaded more than 119,000 times. With a seven-day wait set both in the update bot and in uv, those versions would never have reached a build: by the time the week was up they were gone. The bot, by contrast, immediately proposes a security fix for another library, but uv ignores it until the team exempts that package by hand.

Why it matters for decision makers

A cooldown is cheap: one line of configuration and a few days' delay on new library features. It reduces one specific risk, installing a malicious version right after it is published, and nothing more: it does not stop an attack that stays hidden for weeks, and it does not replace an SBOM, the component inventory that tells you where to act when something goes wrong. A cooldown fits naturally in a DevSecOps pipeline. Ask the team or the vendor two questions. Is the wait set in both the bots and the package managers? Are security updates exempt in both, and does someone look at them right away?