TL;DR
Your app ships with hundreds of npm packages, and any one of them can turn out to have a hole in it. Run npm audit to see the known ones. Turn on Dependabot to hear about new ones. Not every warning is exploitable, but the critical ones shouldn't sit.
What Are Vulnerable Dependencies?
When you install a package, you're running somebody else's code and shipping it to your users. A typical JavaScript project carries 500 to 2000 packages once you count the nested ones. You chose a dozen.
The rest arrived on their own. Any of them can be carrying:
- A known vulnerability, published after the version you installed
- Malicious code, from a maintainer account somebody took over
- An ordinary bug that turns out to be exploitable anyway
How to Find Vulnerable Dependencies
1. npm audit
# Run audit
npm audit
# See detailed report
npm audit --json
# Auto-fix where possible
npm audit fix
# Force fix (may have breaking changes)
npm audit fix --force
2. Automated Tools
| Tool | Cost | Features |
|---|---|---|
| Dependabot | Free (GitHub) | Auto PRs, security alerts |
| Snyk | Free tier available | Deep scanning, fix suggestions |
| Socket.dev | Free tier available | Supply chain analysis |
| npm audit | Free | Built-in, basic reporting |
Understanding Vulnerability Severity
Severity isn't a formality. It's the gap between stopping now and next week's list:
- Critical: someone can run code on your server or read your database. Stop and fix it.
- High: real damage, given a condition an attacker can arrange. This week.
- Medium: small blast radius, or awkward enough that most won't bother. Queue it.
- Low: fix it next time you're in there.
Context matters: A vulnerability in a dev-only dependency (like a testing library) is less critical than one in your production code. A vulnerability requiring specific conditions you don't have might not affect you.
Best Practices
- Run npm audit in CI: so a critical finding fails the build, not your memory
- Enable Dependabot: it opens the update PR while you're asleep
- Commit your lockfile: otherwise every environment resolves its own tree
- Look up new dependencies first: downloads, last release, open issues
- Delete what you stopped using. Code you don't ship can't hurt you.
Pro tip: Use npx depcheck to find unused dependencies you can safely remove.
Should I fix every npm audit warning?
No. Start with critical and high. For the rest, especially dev-only packages like test runners, work out whether it's reachable before you break things updating it.
What if there's no fix available?
A few ways out. Wait for the maintainer, swap in another package, fork it and patch it yourself, or block the path an attacker needs.
How often should I update dependencies?
Security updates, as soon as you practically can. Everything else goes on a schedule, monthly or quarterly, so small updates stay small. Skip a year and the upgrade stops being a version bump.
Scan Your Dependencies
Our scanner checks your package.json for known vulnerabilities.