Supply Chain Security

NPM Security Risks

Your node_modules folder is an attack surface. Understand the risks and protect your JavaScript projects.

Types of NPM Threats

Typosquatting

Malicious packages with names similar to popular packages (e.g., 'lodas' instead of 'lodash')

Real Example

crossenv vs cross-env, electron vs electorn

Impact

Code execution, credential theft, backdoors

Dependency Confusion

Attackers publish public packages with same name as internal private packages

Real Example

Multiple companies compromised in 2021 via this vector

Impact

Arbitrary code execution in build pipelines

Maintainer Account Takeover

Attackers compromise maintainer accounts and push malicious updates

Real Example

ua-parser-js, event-stream incidents

Impact

Millions of projects suddenly running malicious code

Malicious Postinstall Scripts

Packages with install scripts that execute malicious code during npm install

Real Example

Crypto miners, credential stealers in postinstall

Impact

System compromise during development

Abandoned Package Takeover

Attackers take control of abandoned but still-used packages

Real Example

leftpad-style situations, unmaintained dependencies

Impact

Supply chain compromise through neglected packages

Protection Strategies

1
Use package-lock.json

Lock exact dependency versions. Prevents automatic malicious updates.

Always commit package-lock.json. Use npm ci in CI/CD.
2
Run npm audit regularly

Check for known vulnerabilities in your dependency tree.

npm audit in CI/CD pipeline. npm audit fix for automatic fixes.
3
Review before installing

Check package stats, maintainers, and recent activity before adding dependencies.

Use npm info <package> and check GitHub repo before installing.
4
Minimize dependencies

Fewer dependencies = smaller attack surface. Consider if you need that package.

Audit dependencies regularly. Remove unused packages.
5
Use scoped packages for internal code

Prevent dependency confusion by scoping internal packages.

Use @company/package-name for private packages.
6
Enable 2FA on npm account

If you publish packages, protect your account from takeover.

Enable 2FA in npm account settings. Use publish-require-2fa.

Useful Audit Commands

npm audit

Check for known vulnerabilities in dependencies

npm audit fix

Automatically fix vulnerabilities where possible

npm audit --production

Only audit production dependencies

npm outdated

List packages that need updating

npx npm-check

Interactive update checker with more details

NPM Security by the Numbers

2M+
Packages on npm
~7K
Malicious removed/year
500+
Avg dependencies/project
80%
Have audit vulnerabilities

Check Your Deployed Application

VAS scans your running application for vulnerabilities that npm audit can't see— issues in how your code uses dependencies, not just the dependencies themselves.

Free Security Scan

Frequently Asked Questions

How common are malicious npm packages?

More common than you'd think. npm removes thousands of malicious packages each year. Major incidents happen regularly—event-stream, ua-parser-js, node-ipc, colors.js. Most target credentials or crypto mining. The sheer size of the npm ecosystem (2M+ packages) makes complete security impossible.

Is npm audit enough to stay safe?

No. npm audit only catches known vulnerabilities in its database. It doesn't detect: new malicious packages, typosquatting, dependency confusion, or compromised maintainer accounts. Use it as one layer of defense, not your only protection.

Should I worry about dev dependencies?

Yes. Dev dependencies run on your machine and in CI/CD. A malicious postinstall script in a dev dependency can steal credentials, install backdoors, or compromise your build pipeline. Audit all dependencies, not just production ones.

How do I know if a package is trustworthy?

Check: weekly downloads (popularity), number of maintainers, recent commit activity, GitHub stars and issues, npm publish history, package size vs functionality. Be extra cautious with packages that have few downloads, new maintainers, or do more than they should.

What should I do if I installed a malicious package?

1) Remove it immediately, 2) Rotate all credentials that might have been exposed, 3) Check for any files or processes it may have created, 4) Audit your git history for malicious commits, 5) Alert your team, 6) Consider the build/dev machine compromised if the package had postinstall scripts.

Last updated: January 16, 2026