Defending Against npm Supply Chain Attacks

Just want the setup?
Skip to Setting it up. Otherwise, here's what you're up against and how to cut the risk.

This is normal now

For years, staying safe came down to not doing careless things: don't click the link in the sketchy email, don't open the random attachment.

Supply chain attacks turned that on its head. The risky action is now the one every developer runs dozens of times a day — npm install and npm update.

That's the new normal, and four things make it ugly:

• Frequency — a serious npm compromise now lands roughly once a week. Qix-maintained utilities, Nx, and a constant drip of typosquats are the ones that didn't even make the front page.
• Scale — the ones that did are enormous. Axios ships to over 70 million installs a week; the Shai-Hulud worm's November wave hit 492 packages totaling 132 million monthly downloads; a single May 2026 run poisoned 42 TanStack packages.
• Ease — you don't have to slip up. A routine npm install or npm update that resolves a freshly poisoned version is enough, even if that version was live for only a few minutes.
• Impact — the moment it installs, it potentially runs with your full privileges: your tokens, your keys, your access.

And as Socket's Feross Aboukhadijeh put it: "The faster you upgrade, the more vulnerable you are to supply chain attacks… there's some middle ground where you want to be behind a little bit but not too behind."

Impact and blast radius

During the TanStack attack window, any project that depended on one of those packages, directly or as a transitive sub-dependency, was exposed: run npm update or npm install (in a checkout with no committed lockfile) while the malicious versions were live, and you'd have pulled them straight in.

A committed package-lock.json you didn't regenerate would likely have kept you pinned to the safe versions — but that's a thin, accidental line of defense.

When one of those packages runs, the code potentially executes with whatever privileges the developer has. It can exfiltrate the tokens and secrets within reach, establish access that survives a reboot, and pull down further commands to run later.

Another move is self-propagation: if the machine holds publish rights for other packages, the worm uses them to republish those packages with the same or similar payload — which is how the TanStack and Shai-Hulud waves jumped from one maintainer account to the next.

This almost always starts where installs and updates happen, which is usually a developer machine. It reaches build pipelines too — but a pipeline does one narrow thing the same way every time, keeps specific logs, and runs in a fixed environment. That keeps the blast radius smaller and you can at least trace what a compromised run could have touched.

A developer machine is the opposite of fixed. It's running an experiment today and something unrelated tomorrow, while logged into every cloud CLI and holding SSH keys, npm and GitHub tokens, and .env files for every client project.

On top of that, you rarely have the logging to reconstruct what happened: when did the developer run the install that pulled the bad version — an hour ago, three days ago, in an environment that's changed several times since? The impact and the blast radius are both hard to even specify — unknown scope, unknown timing, a moving target.

What actually helps

There's no way to hand-vet every transitive dependency, but you don't have to. The ecosystem hands you one advantage: compromised versions of popular packages get caught fast — often within hours, and TanStack's in under half an hour. Three measures put that to work, in rough order of impact.

1. Wait before installing new versions. The single biggest lever is to not install anything published in the last 24 hours. By the time a version is a day old, the malicious ones have almost always been found and pulled. pnpm exposes this as a global minimumReleaseAge setting; when a version is too fresh it quietly falls back to the newest one old enough to qualify. This is the main reason we moved to pnpm — npm and yarn don't offer an equivalent global delay.

2. Don't run install scripts you didn't ask for. The Axios-style attacks fire during install through preinstall/postinstall hooks, with no further interaction. pnpm doesn't run dependencies' build scripts by default — you approve the few that genuinely need them with pnpm approve-builds. A freshly pulled package can't execute on the machine just for being downloaded.

3. Put Socket Firewall in front of every install. Socket Firewall (sfw) is a zero-config proxy you prefix to package-manager commands. It checks each package against Socket's malware database and blocks confirmed-bad ones — at any depth in the tree — before they reach disk, regardless of the version's age.

None of these are exotic, but together they mean a brand-new malicious release has to survive a 24-hour delay, be explicitly approved to run scripts, and stay off Socket's blocklist before it can do anything at all.

Setting it up

You need a recent Node — any current LTS is fine. With that in place, install pnpm and Socket Firewall globally, and run pnpm setup so pnpm is on your PATH:

npm i -g pnpm sfw
pnpm setup

Set the 24-hour release delay globally:

# delay installing newly published packages by 24h (1440 min)
pnpm config set minimumReleaseAge 1440 --global

Route every package manager through the firewall by adding these to your shell profile (~/.zshrc, ~/.bashrc):

alias pnpm='sfw pnpm'
alias npm='sfw pnpm'
alias npx='sfw pnpm dlx'
alias yarn='sfw pnpm'

Also clear your local caches once when you set up — sfw only inspects packages it actually fetches, so anything already cached slips past it. Socket lists the command for each package manager in their FAQ (pnpm store prune, npm cache clean --force, and so on).

No silver bullet

None of this is a guarantee. A package already in your cache slips past the firewall, and a typosquat Socket hasn't catalogued yet can still land.

But for the majority of supply chain attacks filling the headlines, a release delay plus blocked install scripts plus the firewall — backed by a committed lockfile and 2FA on every maintainer account — puts you in a far better spot than npm install with no guardrails. It's free, and it's an afternoon of setup.

If you'd like a second pair of eyes on your setup, or help with Laravel & AWS, get in touch.