Detecting malicious npm packages before they install

TL;DR: Dependency scanning was built to answer "does any package I depend on contain a known vulnerability." Supply chain attacks ask a different question: "is a package I trust doing something it never did before." Across 208 high-scoring threads, the damage lands at install time — through postinstall scripts that harvest credentials before any human reviews anything — and the tooling teams already run is not looking there.

The evidence

PainHunt holds 208 posts scoring 10 or higher out of 15 on package-ecosystem compromise, averaging 11.1/15 with a pain intensity of 8.2/10 — the highest in this batch — and a willingness-to-pay signal of 7.3. The distribution is Mastodon 145, Dev.to 23, Medium 17, with Bluesky, Reddit, and Lemmy making up the rest. That skew matters: this is practitioners writing up incidents, not a vendor category being talked into existence.

Four mechanisms recur.

Install scripts are the delivery vehicle. Compromised packages execute code during installation, harvesting credentials without the developer taking any deliberate action. Not at runtime, not in production — during a routine install on a laptop.

The blast radius is every secret the developer can reach. The threads enumerate what gets taken: GitHub credentials, cloud secrets, SSH keys, registry tokens, and CI/CD secrets. One compromised transitive dependency does not stay inside the project; it inherits the developer's whole identity.

Dependency confusion is still open. Internal package names exist on public registries, which lets an attacker publish a higher version under the same name and have build systems prefer it. This attack was described publicly years ago and the threads show it still working.

Existing tooling is described as insufficient. Teams report no practical visibility into transitive dependencies, no real-time detection while a compromise spreads, and difficulty auditing hundreds of dependencies across multiple projects. The gap named is not "we have no scanner" — it is "the scanner does not detect this."

The threads also include the uncomfortable case where the security tool is the vector: scanners themselves being compromised through their own supply chain, which is what makes a pure-agent architecture a harder sell than it looks.

Why now

Attack economics inverted. Publishing a malicious package costs nearly nothing and reaches every downstream consumer automatically. Compared with phishing a specific company, poisoning one widely-used dependency is dramatically cheaper per compromised machine, and that ratio is not going back.

Dependency graphs kept growing. A mid-size application pulls in hundreds to thousands of transitive packages. Nobody reads them, nobody can, and the number of maintainer accounts that must all stay uncompromised grows with it.

AI-assisted development widened the surface. Coding agents add dependencies quickly and install them without a human evaluating provenance. The review step that used to sit between "we need a library" and "it is in the lockfile" is thinner than it was.

The wedge

The general build is a software composition analysis product, and that market is crowded with tools doing known-CVE matching well. The unserved job is behavioural detection at install time.

• Treat postinstall as the boundary. Run installs in an instrumented sandbox and report what a package actually did — files read, network destinations contacted, environment variables touched. A package that starts reading ~/.ssh in a patch release is the signal, and no CVE database will ever contain it.
• Diff behaviour across versions, not code across versions. Reviewing a diff does not scale and obfuscated payloads defeat it anyway. Comparing observed behaviour between 4.2.1 and 4.2.2 is a much smaller, much more decidable question.
• Own dependency confusion as a first feature. Scan the customer's internal package names against public registries and alert on collisions. It is cheap to build, immediately demonstrable in a sales call, and the threads show it still landing.
• Report blast radius, not severity. "This package ran a script that could read your AWS profile and your GitHub token" drives action. A CVSS score does not, especially when there is no CVE.
• Make CI the enforcement point, the laptop the detection point. Developers will not adopt a tool that slows local installs. Detect locally, warn asynchronously, block in CI where a few seconds cost nothing.

Risks and honest caveats

• Registries and package managers may close this themselves. Provenance attestation, sandboxed install scripts, and stricter defaults are all live directions. If install scripts stop running with ambient privileges, most of this product's value evaporates — which is good for the world and bad for the business.
• False positives are unusually costly. Plenty of legitimate packages compile native code, download binaries, and touch the filesystem at install. A tool that cries wolf on node-gyp gets muted in a week, and a muted tool is worse than none because it creates the belief that someone is watching.
• The buyer is not the user. Developers feel the friction; security teams hold the budget. Products in that position have to be genuinely pleasant for the person who did not choose them.
• You inherit the trust you are selling. A tool with read access to dependency graphs and CI is itself a high-value target, and the threads already contain the case of a compromised security scanner. Your own supply chain becomes a sales objection on day one.
• The sample skews to one platform. Mastodon supplies 145 of 208 threads. The security-practitioner population there is real and well-informed, but it is not evidence about what a mid-market engineering manager will authorise.

How to validate this further

The question that decides the product is whether teams would pay for detection or only for prevention that blocks the install outright — those imply different risk tolerances and different price points. Use the PainHunt dashboard to filter security threads by intensity and read the ones describing an actual incident rather than a general concern; those name what the team wished they had known and when. Then test whether install-time behavioural reporting alone closes a deal, using idea validation.

Related reading: detecting leaked AWS keys that still authenticate, patched, but were you already breached?.