A 2-day cooldown against npm supply-chain attacks

npm min-release-age is a setting I added to every project I maintain, and it took about thirty seconds. It tells npm to ignore any package version published less than a set number of days ago. Set it to two days and a brand-new release will not install until it has been public for 48 hours.

It is a boring setting, and that is fine: once it is in place it applies to every install without anyone having to remember it.

Why a cooldown is a good idea

Most npm supply-chain attacks follow the same shape. An attacker compromises a maintainer account or slips a malicious version into a popular package. That version then races to land in as many installs as possible before anyone notices.

The window between "published" and "caught and pulled" is usually short. Hours, sometimes a day or two. The npm registry and the wider community are quick to flag and yank these releases once the behaviour is spotted. The danger is concentrated right at the start of a version's life.

A cooldown sidesteps that window entirely. If npm refuses to touch anything younger than two days, the malicious release has usually been reported and removed before your build would ever reach for it.

Most malicious package versions are caught within hours. A 2-day cooldown means you are never the one who installs them first.

You give up almost nothing in return. Genuine updates are still there waiting for you; they just arrive a couple of days later. For a production site, a two-day lag on dependency updates is not a cost, it is good hygiene.

How to set it up

You need npm 11.10.0 or newer. Check with:

npm --version

Then add one line to an .npmrc file in your project root, next to package.json. The value is the number of days, so a two-day cooldown is 2:

# Skip any package version published less than 2 days ago
min-release-age=2

That is the whole setup. Commit the file and it applies to everyone on the team and to your continuous integration (CI) builds. Run npm install or npm update exactly as you always have. When npm resolves versions it skips anything too new and picks the most recent release that clears the cooldown. No errors, no extra commands to remember.

When you need a fresh version anyway

Sometimes a genuinely urgent patch lands and you want it before the two days are up. Override the cooldown for a single command:

npm i --min-release-age=0 some-package@version

Worth knowing: the cooldown only affects new installations or updates. Versions already pinned in your package-lock.json stay put until something triggers an update, so this protects what you install next, not what is already locked.

The bigger picture

A cooldown is not a complete defence. It will not save you from a vulnerability that sits undetected for weeks, and it is no substitute for lockfiles, audits, and paying attention to what you depend on. What it does is remove you from the highest-risk group: the people who install a poisoned release in its first few hours.

This is exactly the kind of unglamorous, low-effort safeguard that protects a site for years. It is also the sort of thing that never gets done, because it is nobody's job until something breaks. Keeping dependencies current and defended is a core part of my website maintenance plan, so the boring-but-important settings are handled before they ever become a problem.