How to secure your npm packages against supply chain threats

The JavaScript ecosystem thrives on open collaboration, but its reliance on third-party packages creates a persistent security blind spot. Every npm install pulls thousands of lines of code from strangers, yet most developers treat dependency management as an afterthought. When a hijacked package like ua-parser-js or node-ipc makes headlines, the usual advice—"be careful what you install"—feels more like damage control than prevention.

The real challenge isn’t awareness; it’s action. How do you harden an npm install in a way that balances security with practicality? Here are five steps to reduce supply chain risks without derailing development workflows.

Why npm’s default install process is a security risk

A typical package.json lists 20 to 50 direct dependencies, but node_modules often contains 1,000 to 2,000 total packages due to transitive dependencies. Each package brings hidden execution paths:

• Automated install scripts (preinstall, install, postinstall) run without warning
• Maintainer account takeovers or leaked tokens allow malicious updates
• Typosquatting attacks replace familiar packages with lookalikes
• New versions can silently overwrite lockfiles in CI environments

The most dangerous part? These scripts execute before your tests, linters, or code reviews. A single npm install can introduce vulnerabilities before your team even sees the changes.

Disable install scripts to block the most common attack vector

The fastest way to reduce exposure is to block install-time scripts entirely. Add this setting to your project’s .npmrc file:

# .npmrc
ignore-scripts=true

Alternatively, pass the flag directly:

npm install --ignore-scripts

This breaks packages that rely on native builds like node-gyp or sharp. For trusted dependencies requiring compilation, re-enable scripts only for those specific packages:

npm install --ignore-scripts
npm rebuild sharp better-sqlite3

The setup takes time, but it eliminates the primary delivery mechanism for supply chain attacks.

Use npm ci in CI pipelines to prevent silent version shifts

In development, npm install updates your package-lock.json to accommodate dependency changes. In CI, this behavior is dangerous—compromised patches can slip in unnoticed.

npm ci enforces strict lockfile compliance. It fails if the lockfile doesn’t match package.json, preventing unauthorized version updates:

npm ci --ignore-scripts

Pair this with pinned dependency versions (removing ^ and ~ in package.json) to stop automatic patch releases from reaching production minutes after publication. The trade-off is slower dependency updates, but it drastically reduces the attack surface.

Inspect lockfile diffs to catch hidden supply chain changes

Most teams review package.json changes but overlook package-lock.json. A single dependency update can introduce 50 to 100 new transitive packages, many of which aren’t obvious in the main manifest.

When reviewing pull requests that modify dependencies, watch for:

• New top-level packages with unfamiliar names
• Packages published within the last 30 days
• Single-maintainer packages with millions of downloads
• Names designed to mimic popular packages (e.g., cross-env-shell vs. cross-env)

While tools like npm audit and Dependabot catch known CVEs, they miss zero-day threats. Manual lockfile inspection remains a critical step for load-bearing dependencies.

Verify package provenance to confirm build authenticity

npm introduced provenance attestations in 2023, linking packages to their source repositories and CI workflows. Packages with provenance include cryptographic proof of their origin, making it harder for attackers to publish from compromised accounts.

Check a package’s provenance with:

npm view <package-name> --json

Look for an attestations field in the distribution metadata. For your own packages, enable provenance during publication:

npm publish --provenance --access public

This won’t cover every package—most still lack attestations—but it adds a critical layer of verification for critical dependencies.

Additional hardening steps for high-risk projects

Beyond scripts and lockfiles, consider these supplementary measures:

• Pin exact versions in production projects. Avoid ^ and ~ to prevent unexpected patch releases.
• Use a private registry or proxy like Verdaccio to cache, mirror, and restrict packages reaching your team.
• Run installs in a sandboxed environment with limited network access. Block outbound connections to prevent postinstall scripts from exfiltrating data.
• Generate a Software Bill of Materials (SBOM) using CycloneDX. This creates a detailed inventory of all dependencies, speeding up incident response and compliance checks.

These steps aren’t foolproof, but they raise the barrier for attackers and reduce the blast radius of a breach.

The trade-offs of a hardened npm workflow

There’s no magic setting to make npm install completely safe. The npm ecosystem fundamentally relies on trust—code from strangers running on your systems. The goal isn’t perfection; it’s layered defense.

Start with the highest-impact changes: disable install scripts, enforce npm ci, and inspect lockfile diffs. Add provenance checks and SBOM generation as capacity allows. The result? A significant reduction in supply chain risk without sacrificing productivity.