A 7-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 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.
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 --versionThen 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=10080That 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@versionWorth 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.
You might also like...
- What a software supply chain attack means for your Statamic website
- Browser console errors: when the noise hides the signal
- Blocking scanner traffic at Nginx for a leaner Statamic cache
- Why my Statamic static cache hit 2.3GB (and how I fixed it)
- Introducing Sentinel: the Statamic monitoring tool I built for myself, now free for everyone
- An npm Supply Chain Attack Just Hit One of the Most Popular Packages on the Internet
- What does website maintenance include?
- Business Websites Have a Running Cost. Here's Why That's a Good Thing.
- Why Web Development Manchester is on the Rise
- Why bespoke web development matters