3 ms·
I spent months studying how malicious npm packages actually work. Most of them do the same thing eg run a preinstall script, read your .env and credentials, and
by ComCat 7mo ago
I spent months studying how malicious npm packages actually work. Most of them do the same thing eg run a preinstall script, read your .env and credentials, and send them to a remote server. All
before your app starts.
npm install will run this code automatically. No prompt, no warning.
I built Dependency Guardian a behavioral analysis engine that scans packages for malicious patterns before they touch your system.
it has:
- 26 detectors (shell execution, credential theft, exfiltration, obfuscation, time bombs)
- 53 cross-signal amplifiers that correlate findings across detectors
- ~2,900 tests across 76 test files
- Benchmarked against 11,356 real packages at 99.95% precision
It would have caught Shai-Hulud, the Chalk/Debug hijack, and the S1ngularity campaign.
Snyk, Dependabot, and npm audit all missed these because they rely on CVE databases. If there's no CVE filed yet, they're blind. Dependency Guardian reads the actual code.
curious if anyone here has been exposed/experiences to supply chain attacks and how they handled them
- sandreas 7mo agoThanks for sharing. I still wonder why this is not an official npm / node effort to better secure the ecosystem...
- john01dav 7mo agoOnce this or something like it becomes widespread, won't sophisticated attackers simply test their attacks against this? So, for example, if it checks for `rm` invocations, just implemented the functionally of `rm` in the malware, or if it checks for exfiltration of data, then shell out to curl to do that in a different process. If you think of making it so robust that this is impossible, you're just describing a container, which we already have.
- cyanydeez 7mo agoNo, sophisticated attackers will make their own toolchain to catch all the other attackers, _Except themselves_.
- ComCat 7mo agoYou're describing two different things, The container comparison misses where these attacks actually happen. Containers limit what code can do at runtime. We flag what code intends to do before it ever runs. These are complementary. A container won't stop a postinstall script from reading ~/.ssh/id_rsa and posting it to an attacker's server if your CI environment has network access and a mounted home directory — which most do. Yes sophisticated attackers adapt. But the current state of npm supply chain attacks is that most don't even try to evade — because nobody's looking at the code. Every major attack in 2025 used the same playbook: credential theft + network exfil + install script abuse. Raising the floor from "zero analysis" to "26 behavioral detectors with cross-signal correlation" eliminates the entire class of low effort attacks and forces the rest into increasingly constrained patterns.
- groundzeros2015 7mo agoThis. The real problems are arbitrary pre-install scripts and a culture of not knowing what’s in the dependency tree
- huflungdung 7mo ago[dead]
- wink 7mo agoIsn't this exactly what `ignore-scripts=true` in your .npmrc should be avoiding with npm 11? Although I am still not 100% sure if it would work in `~/.npmrc` for external packages...