How to Secure Your npm Supply Chain in 2026

Start with lockfile discipline

The lockfile is the reviewable record of the resolved dependency tree. Commit it, require it in pull requests, and treat changes to package versions, integrity values, registry URLs, and install scripts as code changes.

Use npm ci for CI and other automated clean installs:

npm ci
npm test
npm run build

npm documents four important behaviors: the project must already have a lockfile; a mismatch with package.json is an error; an existing node_modules directory is removed first; and the command does not update package.json or the lockfile. If the lockfile was created with dependency-tree flags, commit the corresponding project configuration so CI uses the same settings.

A clean install does not prove that the package graph is trustworthy. It gives reviewers and automation a stable graph to inspect.

Run advisory checks under a documented risk policy

npm audit checks the dependency tree against advisory data. It is useful for known issues, but it is only one control.

npm audit
npm audit --audit-level=high
npm audit --json

The example threshold is a policy choice, not a recommendation for every project. A public authentication service, a build-only tool, and an internal prototype have different exposure. Define:

• which severities block merge;
• how exploitability and reachable code affect triage;
• how quickly each severity must be remediated;
• who can accept a temporary exception;
• when the exception expires.

Run scheduled audits as well as pull-request checks so newly published advisories are evaluated against packages already in the lockfile.

Review dependency changes, not just advisory output

A useful dependency review asks questions that advisory databases cannot answer:

• Is this the intended package name and scope?
• Did the release add an install script?
• Did the maintainer or repository change?
• Did the package begin reading files or making network requests?
• Does the package add a large transitive tree for a small feature?
• Is the resolved URL the expected npm registry, such as https://registry.npmjs.org/..., rather than an unexplained Git source such as https://github.com/...?

Socket documents GitHub pull-request analysis for dependency changes and a firewall that can intercept installs based on supply-chain risk. These controls can surface useful evidence before merge or installation. They should feed human review and policy rather than being presented as infallible malware detection.

Use overrides as a temporary, tested control

When a direct dependency still requests a vulnerable transitive version, a root package.json override can constrain resolution while you wait for the upstream package to publish a compatible release.

{
  "overrides": {
    "semver": ">=7.5.2"
  }
}

After adding an override:

npm install
npm ls semver
npm audit
npm test

Record why the override exists, which upstream issue will remove it, and who owns the follow-up. An override changes the graph outside the direct dependency's declared range, so passing the full application suite matters more than a clean install alone.

Prefer trusted publishing and provenance for packages you publish

npm trusted publishing supports selected CI providers through OIDC. The workflow exchanges a short-lived identity for publishing authorization instead of storing a long-lived npm token. Under npm's documented conditions, trusted publishing also generates provenance that links the published package to its source and build context.

For package authors, the control set should include:

1. a protected release workflow;
2. minimal workflow permissions;
3. reviewed build inputs and lockfiles;
4. trusted publishing configured for the exact repository and workflow;
5. provenance checked on the published package;
6. a dry-run inspection of package contents before release.

Provenance answers where and how an artifact was built. It does not review the source or guarantee that the workflow was designed safely.

Scope internal packages and route them deliberately

Use organization scopes for private names such as @mycompany/utils. npm scopes can be associated with a registry, which makes the expected package owner and registry explicit.

@mycompany:registry=https://npm.mycompany.com/

Keep the public npm registry configured only for packages that should resolve there, such as https://registry.npmjs.org. Test registry configuration in a clean CI environment. A developer's cached credentials and local .npmrc can hide a routing mistake that appears only in deployment.

Reduce the dependency surface

Before adding a package, check whether the runtime already provides the needed capability. Removing an unused dependency is valuable even when it has no current advisory: it reduces future updates, review load, and maintainer trust relationships.

For dependencies you keep, document why they exist and where they run. A package used only in a local code-generation step has a different threat model from one executing on every server request.

Compare npm and pnpm on PkgPulse. Related guides: why npm audit is broken, how long npm packages get updates, and packages with the fastest release cycles.