Outdated dependencies with CVEs are a liability you can quantify.

npm audit outputs a list that looks alarming. Most of it isn't. The triage process:

Severity levels:

• Critical: Direct exploitability in a production context. Prioritize immediately.
• High: Exploitable under certain conditions. Fix within a sprint.
• Moderate: Limited impact or difficult to exploit. Fix during normal maintenance.
• Low/Info: Theoretical vulnerability; unlikely to affect a production application.

Context matters:

A vulnerability in a server-side package is different from a dev-only build tool dependency. A critical vulnerability in node-fetch that's only used in a CLI build script isn't exploitable in your production web application.

Ask: "Is this package used in a production path that handles untrusted user input?" If no, the vulnerability risk is lower.

The update process:

1. Run npm audit or pnpm audit to see the full list
2. Sort by severity
3. For critical/high: identify the package, the vulnerability, and whether it's exploitable in context
4. Update the vulnerable package: npm update package-name for minor updates
5. For major version updates: read the changelog, update carefully, test
6. For packages with no fix: assess risk and consider alternatives

Locked transitive dependencies:

Many vulnerabilities are in transitive dependencies (a package your package depends on). The direct fix is to update the package that depends on the vulnerable one. Sometimes this requires waiting for upstream to release a fix; sometimes an overrides entry in package.json can force the patched version.

Dependabot:

GitHub Dependabot automatically opens pull requests for dependency updates. Set it up; review the PRs. It doesn't fix everything, but it keeps dependencies from falling too far behind.