Ten npm practices cover most of the risk: commit your lockfile, install with npm ci, audit regularly, control install scripts, use two-factor authentication and granular tokens when you publish, publish with provenance, keep dependencies few, review new packages, and protect your CI. Each one blocks a specific way attackers reach npm projects.
1. Commit the lockfile
package-lock.json records exact versions and integrity hashes. Without it, two installs a day apart can pull different code.
2. Install with npm ci in CI
npm ci installs exactly what the lockfile says and fails if package.json and the lockfile disagree. Plain npm install may rewrite the lockfile. Use ci for builds and releases.
3. Run npm audit and read it
npm audit checks your dependency tree against known advisories. The npm docs describe the report and how fixes are suggested. Treat the output as a starting point, since many findings sit in code you never call. Reachability analysis helps separate real exposure from noise.
4. Control install scripts
Packages can run scripts at install time, which is a common route for malicious packages. Setting ignore-scripts to true stops them by default; then allow the few packages that truly need a build step. Test this in CI first, since some native modules will fail.
5. Turn on two-factor authentication
If you publish packages, require two-factor authentication on the account. npm documents the options. A stolen password alone should never be enough to push a release.
6. Use granular, short-lived tokens
Do not leave a broad publish token in a developer's shell profile. Create tokens limited to the packages and actions needed, set an expiry, and keep them in CI secrets, not in the repository.
7. Publish with provenance
npm supports provenance statements that link a published package to the source and build that produced it, when you publish from a supported CI system. Consumers can then verify that a package came from the repository it claims. Run signature checks on what you install as well, using the audit signatures command.
8. Keep the tree small
Every dependency, direct or transitive, is code you run. Before adding a package for ten lines of logic, write the ten lines. Remove unused packages. A smaller tree means fewer advisories and fewer maintainers to trust.
9. Review new and changed packages
Check a new package before adding it: how long it has existed, how many maintainers, last release, open security issues and whether the name is close to a popular one. Typosquatting relies on people not looking. Be wary of a dependency whose maintainer changed recently.
10. Protect the pipeline
The build runs with secrets and publish rights, so it is a prime target. GitHub's guidance for Actions recommends least privilege for the workflow token and pinning third party actions to a full commit SHA. Do the same on any CI.
A constructed example
A team adds a small string utility. The review notes it has one maintainer, no release for three years, and an install script that downloads a binary. They replace it with eight lines of their own code. The lockfile diff shrinks by four transitive packages, and ignore-scripts no longer needs an exception.
How to check or apply this
- Confirm the lockfile is committed and CI uses npm ci.
- Run npm audit and sort results by reachability and exploitation.
- Set ignore-scripts and list exceptions.
- Enforce two-factor authentication for every publisher.
- Replace broad tokens with granular, expiring ones.
- Turn on provenance for releases and verify signatures on installs.
- Remove unused dependencies each quarter.
- Add a short review checklist for new packages.
- Pin CI actions and reduce workflow permissions.
Safeguard's free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies if you want a quick look at a package manifest before changing anything.
Quick check
Is npm audit enough?
No. It reports known advisories. It will not catch a brand new malicious package, so combine it with install script controls and package review.
What does provenance prove?
It links a published package to the source repository and build that produced it. It does not prove the code is free of bugs or malice.
Sources
- About audit reports, npm Docs
- Generating provenance statements, npm Docs
- About two-factor authentication, npm Docs
- Security hardening for GitHub Actions, GitHub Docs
Last reviewed: 18 October 2026.
