When npm install becomes a security event

Why the npm threat model is so messy

Step 1: Stop running install scripts by default

Step 2: Use npm ci everywhere except local dev

Step 3: Audit the lockfile, not just package.json

Step 4: Verify package provenance

Step 5: Pin, proxy, and contain

What none of this fixes Look, I love npm. I've been shipping JavaScript for years and the ecosystem is genuinely incredible. But every few months we get another headline: a popular package gets hijacked, a maintainer's token leaks, a typosquatted package siphons environment variables for a week before anyone notices. The frustrating part? The advice is always the same — "be careful what you install" — as if you're supposed to audit 1,200 transitive dependencies before every deploy. Let me walk through what actually causes these incidents and what you can do at the project level. None of this is bulletproof, but the gap between a default npm install and a reasonably hardened install is bigger than most people realize. A typical Node project lists maybe 30 dependencies in package.json. Your node_modules ends up with 1,500. Every one of those packages can: The kicker: most of this happens before your tests run, before your linter runs, before any review. The moment you run npm install, you've already executed whatever code the package author wanted to run. This is the highest-leverage change you can make. Drop this in your project .npmrc: Or pass it explicitly: Yes, this breaks packages with legitimate native-build steps — node-gyp, sharp, better-sqlite3. The workaround is to enable scripts only for the packages you actually trust. There's no built-in allowlist, but you can rebuild specific packages after install: I started doing this last year on a fintech project and the friction is real — but it's a one-time setup cost per project, and it shuts down the most common payload-delivery path in npm supply chain incidents. npm install is allowed to update your lockfile. In CI, that's a footgun. If a transitive dep silently shifts to a compromised patch version, npm install happily picks it up. npm ci does the opposite: it installs strictly from package-lock.json and errors out if the lockfile is out of sync with package.json. See the official docs for the full behavior. Combine this with pinned deps and you've removed the silent version-drift attack surface. Most code reviews focus on package.json because it's small. But the lockfile diff tells the real story — a one-line package.json change can introduce 80 new transitive dependencies. When reviewing a PR that touches deps, look for: I'll be honest: nobody manually does this for every PR. That's what npm audit and Dependabot are for — but those mostly catch known CVEs, not zero-day supply chain stuff. The human eyeball check on lockfile diffs is still valuable for any load-bearing dep. npm added provenance attestations via Sigstore back in 2023. When a package is published from a CI pipeline with provenance enabled, you can verify which repo and which workflow built it. You can inspect provenance from the CLI: Packages with provenance are cryptographically tied to a public source repo and a specific build, which makes the "I phished the maintainer and published from my laptop" attack much harder. It's not universal — most packages still don't ship with provenance — but for your own publishes, enabling it is one flag: A few additional defenses worth setting up once and forgetting: Let me be straight: there is no configuration that makes npm install safe in an absolute sense. The trust model is fundamentally "we run code from strangers." Every defense above raises the cost of an attack — it doesn't eliminate it. The realistic goal is layered. Reduce the blast radius (no install scripts). Slow down bad updates (lockfile + pinning). Increase visibility (lockfile review, provenance, SBOMs). Contain damage if something gets through (sandboxed installs, no secrets in the build env). If you only do one thing this week, set ignore-scripts=true in your project .npmrc and figure out which native packages legitimately need to be rebuilt. That single change cuts off the most common payload-delivery path in real-world incidents. The "no way to prevent this" framing is funny because it's half true — you can't prevent compromised packages from being published. But you absolutely can prevent them from executing in your build environment. The defaults are bad. Your project doesn't have to inherit them. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse