When npm install becomes a security event

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.

Why the npm threat model is so messy

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:

• Run arbitrary code at install time via preinstall, install, and postinstall scripts
• Get hijacked if the maintainer's account is phished or their token leaks
• Be replaced with a malicious version when ownership transfers to a new maintainer
• Be typosquatted (lodahs vs lodash) and copy-pasted into a Dockerfile at 2am

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.

Step 1: Stop running install scripts by default

This is the highest-leverage change you can make. Drop this in your project .npmrc:

# Disable preinstall/install/postinstall scripts globally for this project
ignore-scripts=true

Or pass it explicitly:

npm install --ignore-scripts

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:

npm install --ignore-scripts
# Rebuild only the native deps you trust
npm rebuild sharp better-sqlite3

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.

Step 2: Use npm ci everywhere except local dev

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.

# In your Dockerfile, GitHub Actions, etc.
npm ci --ignore-scripts

See the official docs for the full behavior. Combine this with pinned deps and you've removed the silent version-drift attack surface.

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

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:

• New top-level packages you don't recognize
• Packages with very recent first-publish dates
• Packages with one maintainer and millions of downloads (single-point-of-failure targets)
• Suspicious names (typos, hyphenation tricks like cross-env-shell vs cross-env)

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.

Step 4: Verify package provenance

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:

npm view <package-name> --json
# Look for the "attestations" field in the dist block

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:

npm publish --provenance --access public

Step 5: Pin, proxy, and contain

A few additional defenses worth setting up once and forgetting:

• Pin exact versions in critical projects. Drop the ^ and ~ in package.json. You give up automatic patch updates — you also stop new patch releases from running in prod five minutes after publish.
• Use a private registry or proxy. Verdaccio is the open-source standard. It lets you cache, mirror, and gate which versions reach your team.
• Run installs in a sandboxed environment. A locked-down container with no network egress except to the registry is a good starting point. If a postinstall script tries to phone home, the connection fails.
• Generate an SBOM. CycloneDX has a free npm plugin. It won't stop an attack, but it makes the post-incident question "are we exposed to package X at version Y?" answerable in seconds instead of hours.

What none of this fixes

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.