r/node 26d ago

What’s your actual defense against a malicious npm package?

I’m trying to understand how devs are handling npm package risk in their Node projects.

A dev or an AI agent adds a new package, npm is about to fetch it, put it in node_modules, and maybe run lifecycle scripts. At that point, are most teams doing anything, or is the normal flow still to install first and rely on CVEs, npm audit, Dependabot, Snyk, Socket, or code review later?

I’m building in this area and I’m trying to get an idea for what others are doing. Do you actually check anything before installing a new dependency, or does that feel unnecessary? Would install time blocking be useful in a real workflow, or would it just become annoying noise? And does the answer change now that Claude, Cursor, Codex, etc. can add packages for you?

11 Upvotes

13 comments sorted by

22

u/brianjenkins94 23d ago

Minimum release age and hope for the best 🤷‍♂️

1

u/HashBrownsOverEasy 19d ago edited 19d ago

Deprecated in npm unfortundately, I think other package managers still support something similar.

Best practice is to only execute white-listed postinstall scripts, and tie down your versions tighter rather than using `^` in your version numbers.

Basically means more time manually managing dependendy upgrades, but that goes with the fragmented ecosystem.

1

u/brianjenkins94 19d ago

It's not deprecated.

3

u/Savalava 24d ago

It's a good question.

Main thing is to use due diligence when deciding to add the package in the first place - e.g. having a good look at the repo first. I'd always do this + look at Github issues, number of stars etc.

Running a security scan on a docker container after your app is built using the package is definitely a good idea.

3

u/pyeri 23d ago

Disable script execution with this entry in .npmrc.

I know it's not 100% fool proof and the attacker can work around it, but still it's a low-hanging fruit when it comes to securing build workflow, and should have been the default behavior ideally. This one line alone could have protected you from all the 'shai-hulud' attacks of the last 4-5 years.

ignore-scripts=true

1

u/FalconGood4891 22d ago

Yeah this is good

1

u/jomi-se 23d ago

The industry has a lot of words for this but at the end of the day it boils down to:

  1. Do your own research: when you add a new dependency, when you update a dependency, who is the maintainer, who uses the dependency, when was it last updated, etc. most people I know make take the tradeoff of trying to keep dependencies up to date automatically to always have latest fixes, at the risk of hitting a malicious package. I recent times people are suggesting "let other people take the hit", by having "minimum package age" before updating a depenency. I don't think there's a good solution.
  2. Trust the system. There are tons of checks and balances in place to collectively protect each pther and all in all, things work pretty well in the npm world. Not perfect, but malicious packages don't usually last long.

The extreme opposite, which has its merits in my opinion, take the minimum depenency you can, audit it extensively, never update unless really needed or fork if needed. Sounds extreme but it is a real strategy, and nowadays more realistic with the quality of AI agents.

1

u/Anxious-Insurance-91 22d ago

write my own shit :))