Skip to Content (Press Enter)

A 7-day cooldown against npm supply-chain attacks

A one-line setting that tells npm to skip any package version published in the last 7 days. Cheap insurance against 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 seven days and a brand-new release simply will not install until it has been public for a week.

That sounds boring. It is. Boring is the point.

canary in a bird cage.

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 seven days, the malicious release has almost always been reported and removed before your build would ever reach for it. You let everyone else be the canary.

Most malicious package versions are caught within hours. A 7-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 week later. For a production site, a seven-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 in minutes, so seven days is 7 x 24 x 60 = 10080:

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

That is the whole setup. Commit the file and it applies to everyone on the team and to CI. Run npm install or npm update exactly as you always have. When npm resolves versions it quietly 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 week is up. Override the cooldown for a single command:

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

Worth knowing: the cooldown only affects new resolution. 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 quietly 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.

Updated: 16th June, 2026 by Stephen Meehan in Web Development, Maintenance Services
.

Get a measurably better website

Your online presence matters, increase engagement, lower bounce rates, and improve conversions.
Design & Build