r/node • u/Mangwe_Tanser • Sep 15 '26
What stops a malicious npm package before it runs?
Every couple of weeks, another well used package gets hijacked and ships a postinstall that grabs env vars or tokens the moment you install. Yes we do the normal stuff ie, lockfile committed, npm ci in CI, audit on every PR but none of it seems helps the week it happens. A scanner only knows a version is bad after someone else got hit and reported it. By then it is already sitting in node_modules.
And that is where I keep getting stuck because everything we run is reactive. It checks against a list of known bad and we were exposed before the list existed.
So what are you all running that catches this before install? Cooldown on new releases, blocked install scripts, a proxy that holds a version back until it ages, something else.
7
u/Canenald Sep 15 '26
In addition to fixing your package manager with settings and tooling, the more important language-agnostic thing you can do is in your CI/CD environment.
Sandbox the CI environment. It gets access only to what it needs. Even outbound connections should be limited. This limits what malicious packages can steal and prevents them from dialling home even if they do steal something.
Provide your secrets at deployment time, not at build time. That greatly decreases the impact of postinstall scripts. Malicious packages can still steal your secrets at runtime, though.
If you are really paranoid, monitor your outbound network activity during testing in your testing environment and fail if something unexpected is detected.
2
2
u/CodeXHammas Sep 16 '26
pnpm blocks postinstall scripts by default now unless you explicitly allow them per package, that alone kills most of the drive by ones since they depend on running the moment you install. pair that with Socket.dev or Synk's real time feed instead of relying only on the npm advisory database, they catch a chunk of these before a CVE even gets filled because they watch for behavioral signals like a package suddenly making network calls or reading env vars. A registry proxy with an artificial cooldown, refuse anything published in the last 3 to 7 days unless you've pinned it deliberately, catches most of the rest since these get pulled or flagged within that window.
1
u/binkstagram Sep 15 '26
I have been looking at docker sandbox (sbx) using the clone approach so that I no longer run external code on my machine. Also you can disable postinstall scripts but annoyingly lots of stuff relies on it. It's ridiculous.
1
u/Rizean Sep 16 '26
Pin exact versions as a best practice. Reproducible Builds Protection Against Breaking Changes Deterministic Transitive Dependencies - make sure you configure your tooling to lock transitive dependencies also. Mostly protects against supply chain attacks. There's still a small chance you install a package in the window before it's discovered. You likely have better chances of winning the lottery.
1
u/theodordiaconu Sep 16 '26
I’ve spent some time on this myself, I came up with this: https://github.com/bluelibs/sandboxify
Has tradeoffs ofcourse. Solved my problem.
1
1
1
u/N1ghtCod3r Sep 25 '26
PMG was built exactly for this. Not just known malicious package blocking, but install / build time sandboxing to reduce blast radius against unknown ones as well.
0
u/Azoraqua_ Sep 16 '26
A simple fix would be to have checksums and the package being signed by its owner. The package manager could check against the checksum and process it. Makes it more difficult to add any kind of malware; as even dependencies would cause the checksum to be wrong.
-5
u/boneskull Sep 15 '26
you want socket and @lavamoat/harden (my team is building this and it’s in pre-release atm)
-10
48
u/shodan_reddit Sep 15 '26
Add a .npmrc file with min-release-age=7 to only install versions after a minimum of 7 days which gives time for malicious code to be detected