Copied to Clipboard
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.