npm package security is one of the hardest parts of modern Node.js security because the npm ecosystem is massive. The npm registry has more than 2 million packages, making it the largest software registry in the world. That scale helps developers build quickly, but it also creates security risk: abandoned packages, vulnerable transitive dependencies, typosquatting, malicious releases, and supply chain attacks can enter an application through a single install command.

Most Node.js teams do not ship only the packages listed in package.json. The real dependency tree lives in package-lock.json, where direct and transitive packages are pinned. That file can include hundreds or thousands of packages. If one nested dependency has a known CVE, your app may still be affected even if your developers never imported that package directly.

This npm package security guide is written for Node.js developers and engineering leads who need a practical way to find vulnerable packages, fix risky dependencies, and monitor new CVEs after deployment.

This guide explains how to audit npm dependencies, where npm audit helps, where it falls short, which historical npm packages deserve extra attention, how to scan package-lock.json, how to fix vulnerable packages safely, and how to add npm security checks to GitHub Actions.

The npm Package Security Landscape

The npm ecosystem is fast, open, and highly interconnected. That creates three major risk categories: known vulnerabilities, malicious supply chain activity, and dependency maintenance problems. A package can be vulnerable because of a coding flaw, malicious because a maintainer account was compromised, or risky because it is abandoned and no longer receives fixes.

The challenge with npm package security is that risk rarely comes only from the packages your team installs directly. Vulnerabilities can enter through transitive dependencies, abandoned packages, compromised maintainer accounts, or malicious packages hidden deep in the dependency tree.

• Known CVEs: Packages such as lodash, minimist, follow-redirects, axios, and node-fetch have had publicly tracked vulnerabilities affecting real applications.
• Supply chain attacks: The event-stream incident showed how a malicious dependency, flatmap-stream, could enter a trusted package and target downstream users.
• Typosquatting: Attackers publish packages with names similar to popular libraries so developers accidentally install the wrong dependency.
• Abandoned packages: Some packages remain widely installed even after maintainers stop updating them, leaving users stuck with unresolved vulnerabilities.
• Transitive risk: A vulnerable package can appear deep inside the dependency tree even when it is not listed directly in package.json.

The key lesson is simple: you cannot secure a Node.js application by reading package.json alone. You need to inspect the full resolved dependency tree.

Where npm Audit Helps npm Package Security — and Where It Falls Short

npm audit is the built-in npm command for checking project dependencies against known vulnerability advisories. It submits dependency information from your project to the configured npm registry and returns a report of known vulnerabilities. When possible, npm audit fix applies compatible updates to the package tree.

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

This is useful and should be part of your workflow. But npm audit is not a complete npm package security program by itself.

• It depends on advisory coverage: If a vulnerability, malicious behavior, or supply chain compromise is not represented in the advisory source used by your registry, the audit may not flag it.
• Transitive fixes can be unclear: A vulnerable transitive dependency often requires upgrading the parent package, using overrides, or waiting for an upstream maintainer to release a fix.
• Output can be noisy: Large applications may produce long reports that make it hard to decide which package update removes the most risk.
• Zero findings do not mean zero risk: A clean audit result does not detect all malicious package behavior, typosquatting, abandoned maintenance, or non-CVE supply chain risk.
• Force fixes can break applications: npm audit fix --force may introduce semver-major upgrades, so teams should test carefully before merging.

Tip: Use npm audit as a baseline check, but combine it with lockfile scanning, CI/CD enforcement, manual review of risky packages, and continuous monitoring for new CVEs.

Historically Vulnerable npm Packages to Watch

A strong npm package security process should pay special attention to packages that appear across millions of projects or have a long history of public advisories.

The table below highlights npm packages that frequently appear in dependency security conversations. Counts vary by vulnerability database and date, so treat the “known CVE/advisory footprint” column as a practical signal, not a live authoritative total.

How to Audit package-lock.json for npm Package Security

package.json shows what your project requests. package-lock.json shows what npm actually resolved. For serious npm package security, the lockfile matters because it includes transitive dependencies, exact versions, resolved package URLs, integrity hashes, and nested dependency relationships.

Start with basic inspection:

npm ls
npm ls lodash
npm ls minimist
npm ls follow-redirects
npm ls axios
npm ls node-fetch

Search the lockfile directly:

grep -n "\"lodash\"" package-lock.json
grep -n "\"minimist\"" package-lock.json
grep -n "\"follow-redirects\"" package-lock.json
grep -n "\"axios\"" package-lock.json
grep -n "\"node-fetch\"" package-lock.json

For a JSON-based view, use Node.js to find installed versions from the lockfile:

node -e "const lock=require('./package-lock.json'); for (const [k,v] of Object.entries(lock.packages||{})) if(k.includes('node_modules/lodash')) console.log(k, v.version)"

Then compare the installed versions against advisories or scan the file with an SCA tool. Manual grep is useful for quick checks, but it does not scale well across many projects or thousands of dependencies.

npm Commands for Fixing Vulnerabilities

The safest fix depends on whether the vulnerable package is direct or transitive. If it is direct, upgrade it explicitly. If it is transitive, upgrade the parent package or use npm overrides when appropriate.

Run the standard audit fix first:

npm audit fix

Use force only when you understand the breaking-change risk:

npm audit fix --force

Upgrade a direct dependency to a known safe version:

npm install lodash@latest
npm install minimist@latest
npm install follow-redirects@latest
npm install axios@latest
npm install node-fetch@latest

Install a specific patched version when your application needs version control:

npm install lodash@4.17.21
npm install minimist@1.2.8
npm install node-fetch@2.6.7

If a vulnerable transitive dependency cannot be fixed through the parent package immediately, use overrides in package.json with caution:

{
  "overrides": {
    "minimist": "1.2.8",
    "follow-redirects": "1.15.6"
  }
}

After applying fixes, reinstall and retest:

rm -rf node_modules
npm ci
npm test
npm audit --audit-level=high

Tip: Do not commit dependency fixes without reviewing package-lock.json. Most npm dependency security changes happen in the lockfile, not just in package.json.

Where npm audit Falls Short for Transitive Dependencies

npm audit can report transitive dependency vulnerabilities, but fixing them is often the hard part. If a vulnerable package is nested under another library, the direct fix may not be npm install vulnerable-package@fixed-version. The correct fix may be to upgrade the parent dependency that brought it in.

For example, if follow-redirects appears through axios, upgrading follow-redirects directly may not be enough if the dependency is locked under the parent package. You may need to upgrade axios, use an override, or wait for a compatible upstream release.

This is why package grouping matters. A long list of 60 CVEs may come from only a few packages. A good workflow should show the package upgrade that removes the most risk, not only the individual CVE list.

Upload package-lock.json to Vulert for a Comprehensive Scan

Vulert can analyze package-lock.json and yarn.lock files for JavaScript and Node.js projects. This is useful when you want a fast dependency report without connecting a repository or installing an agent. Uploading the lockfile gives the scanner visibility into the resolved dependency tree, including transitive dependencies.

For npm package security, Vulert helps by showing affected packages, vulnerable versions, CVSS scores, fixed versions, and fix guidance. It also supports continuous monitoring, so your team can get alerts when a new CVE affects dependencies already used by your application.

This is useful for teams that need more than a one-time terminal result. Developers can fix the package, engineering leads can prioritize by package health, and teams using Jira can turn findings into trackable remediation work.

Add npm Security Scanning to GitHub Actions

For teams running production Node.js applications, npm package security should be part of CI/CD, not a manual task developers remember only before releases.

Add a basic security check to your CI/CD pipeline so vulnerable dependencies are caught before deployment. This example uses npm ci, runs tests, and fails the workflow for high or critical npm audit findings.

name: Node.js Dependency Security

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  npm-security:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Audit npm dependencies
        run: npm audit --audit-level=high

This workflow is a good baseline. Mature teams may add scheduled scans, SARIF uploads, security issue creation, dependency review, or a separate SCA scanner for deeper reporting and continuous monitoring.

Practical npm Package Security Workflow

A sustainable npm package security workflow should be simple enough for developers to follow and strict enough to catch real risk. Use this sequence for most Node.js applications:

• Scan the lockfile: Use package-lock.json as the primary source because it contains exact resolved versions and transitive dependencies.
• Prioritize by severity and exposure: Fix critical and high vulnerabilities first, especially in production services and internet-facing applications.
• Group by package: Upgrade packages that remove multiple vulnerabilities instead of opening separate tickets for every CVE.
• Test every upgrade: Run unit tests, integration tests, and build checks because dependency upgrades can introduce breaking behavior.
• Monitor continuously: New CVEs appear after release, so scan again after deployment and alert the team when risk changes.

Key Takeaways

• npm package security starts with the lockfile: package-lock.json shows the exact resolved dependency tree, including transitive packages.
• npm audit is useful but not complete: It helps identify known vulnerabilities, but it does not detect every supply chain risk or always provide clear remediation for nested dependencies.
• Historically risky packages deserve special attention: Watch packages such as lodash, minimist, follow-redirects, axios, and node-fetch.
• Fixes require testing: npm audit fix --force can introduce breaking changes, so use it carefully and test before merging.
• CI/CD scanning prevents risky changes from shipping: GitHub Actions can fail builds when high or critical dependency vulnerabilities appear.
• Continuous monitoring matters: A clean scan today does not mean your dependencies will stay safe after new CVEs are disclosed.

Frequently Asked Questions

Can npm audit show zero vulnerabilities while risk still exists?

Yes. A zero-vulnerability audit result only means npm did not find known advisories for the submitted dependency tree. It does not prove the project is free from malicious package behavior, typosquatting, abandoned packages, private advisory gaps, or future CVEs.

How often should Node.js dependencies be scanned?

Scan during pull requests, before releases, and continuously after deployment. Daily monitoring is a good baseline for many teams, while critical production apps may need faster alerts for newly disclosed CVEs.

Can Vulert scan package-lock.json?

Yes. Vulert supports package-lock.json and yarn.lock for Node.js projects. It can analyze dependencies, identify known vulnerabilities, show fix guidance, and support continuous monitoring.