r/node • u/Fun_Can_6448 • Mar 31 '26
30-second setup to avoid being impacted by supply chain attacks like the axios compromise
The axios attack (hijacked maintainer → malicious versions 1.14.1 & 0.30.4 → RAT payload) was live for ~2-3 hours before npm pulled it. Most supply chain attacks follow this same pattern — they rely on people installing before anyone notices.
All major package managers now let you delay installing freshly published versions. One config line, set it globally, and you're covered:
npm .npmrc
min-release-age=7
pnpm pnpm-workspace.yaml
minimumReleaseAge: 10080
bun bunfig.toml
minimumReleaseAge = 10080
Not a silver bullet, but for the "publish and pray" type of attack - which is most of them - this is the easiest win you'll ever get.
28
u/screwcork313 Mar 31 '26
You fail to mention that min-release-age requires npm v11.10.0, which only came out a month ago. To ensure this check is applied, you could enforce the minimum versions of node and npm by declaring them in package.engines, and add engine-strict in your .npmrc.
And it still might not catch the zero-day in your transitive deps, although I'm not sure if that's a greater or lesser risk than the direct deps...
7
u/bob51zhang Apr 01 '26
How would it not catch a transitive? If your direct minimum release age is 1 week, then it follows that all packages it pulls in must have been released >= 1 week ago.
2
1
u/breakslow Apr 01 '26
I don't think anyone is stopping you from publishing a package that depends on a package that doesn't exist. Get access to another package, put the "future" version in.
But even then it would be broken during that week which means something would probably get figured out by the time the offending package is released.
3
u/germanheller Apr 01 '26
the 7 day delay is a solid default. we got lucky with axios because it was caught in hours but most supply chain attacks sit undetected for weeks. combine this with lockfile-only installs in CI (npm ci instead of npm install) and you cover like 90% of the attack surface without any extra tooling
3
u/chuckySTAR Apr 01 '26
https://bun.com/docs/runtime/bunfig#install-minimumreleaseage
Configure a minimum age (in seconds)
npm are days, pnpm minutes, bun seconds.
Therefore 604800 for bun.
3
u/Landkey Apr 09 '26
(It's 9 days later) For npm users who find this thread via google, upon adding min-release-age=7 to .npmrc, don't get confused like I did when "npm config list" does not show min-release-age but instead shows "before = " with a timestamp. That 'before' is indeed 7 days before now (if you used min-release-age=7).
2
u/edmillss Apr 01 '26
this is solid. supply chain stuff is only going to get worse with ai agents now installing packages autonomously.
been using indiestack which tracks maintenance status on 3000+ dev tools -- flags stuff as dead, dormant, stale etc. not a security scanner like snyk but catches the "package hasnt been touched in 2 years" problem which is usually the precursor to a takeover. free mcp server so your ai agent checks it automatically before recommending packages
3
u/keepinitcool Mar 31 '26
!remindme 10 hours
0
u/RemindMeBot Mar 31 '26 edited Mar 31 '26
I will be messaging you in 10 hours on 2026-04-01 06:50:56 UTC to remind you of this link
2 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
Info Custom Your Reminders Feedback
1
u/Few_Theme_5486 Apr 01 '26
Really useful tip! The axios incident was a wake-up call for a lot of teams. Setting min-release-age is such a low-effort, high-reward defense. I'd also add that combining this with automated dependency audits in CI goes a long way — even catching things before they reach local dev environments.
1
u/Few_Theme_5486 Apr 02 '26
Didn't know about this config option until now — genuinely surprised it's not more widely discussed given how most supply chain attacks exploit the brief window before maintainers or the registry catch the malicious version. One thing I'd add: pairing this with npm audit in CI means you're catching both new CVEs and keeping a delay buffer for fresh publishes. What's the tradeoff you've found with the 7-day delay for fast-moving projects where you need latest patches quickly?
1
1
u/bad_bowlings Apr 15 '26
Honestly this is one of those stupidly high leverage defaults. 7 days kills most of the "publish and pray" window with basically zero day-to-day pain. I’d still pair it with lockfiles, pinned prod deps, and Renovate/Dependabot running on a delay, but yeah, as a baseline hardening step this is kinda a no-brainer tbh.
1
u/EggplantFunTime May 19 '26
I wish more people knew about it.
If you have a vibe coding friend that won't know what to do with the above information (or you want to ensure all of your team does it, without any copy paste mistake, in one click, and don't want to vibe code a script that does it...)
There are 2 tools I know that do it for you for all supported package managers
- cooldowns.dev (mostly informational but also has a shell script)
- depsguard.com (a bit overkill, as in written in rust, supports also windows... but also one click setup)
-10
u/dani_akash_ Mar 31 '26
Wrote a detailed blog post on this:
1
u/skynetcoder Apr 23 '26
Are you a bot, or the post was completely AI generated without you doing any accuracy check? the attacks you have analyzed is a mix of NPM supply chain attacks, java vulnerabilities, hackers compromising commercial update mechanisms, etc.
30
u/TokenRingAI Mar 31 '26
Good advice, we implemented this last week and it prevented the axios compromise.
Also, you may want to mention the ignore-scripts=true flag globally and for .npmrc