npm audit Shows 47 High-Severity Findings, Here Is What to Actually Do

npm audit flags every vulnerability in every package in your dependency tree, regardless of whether your application can trigger it. A vulnerability in a deep transitive dependency, say, a prototype pollution issue in a utility package that your test runner uses, will show as high severity even if it requires attacker-controlled input to a code path that never executes in your app.

Three categories generate most of the noise:

1. Dev-only dependencies: Vulnerabilities in packages listed under devDependencies never reach production. A high-severity CVE in webpack or jest matters for developer machine security but not for your deployed app.

2. Unexploitable transitive vulnerabilities: The vulnerable function exists in your tree but nothing in your application calls it. npm audit has no call-graph awareness, it cannot tell you whether your code path reaches the vulnerable code.

3. Vulnerabilities with no fix available: npm audit flags these anyway, giving you a list item you cannot action. These need a workaround strategy, not a package update.

The result is that treating every npm audit finding as equal urgency is the same as treating every CVE as a P1. You end up either paralyzed or making changes that cause regressions without improving security.

Run npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.isDirect == true) | .key' to list only packages you directly depend on in package.json. These are your actual attack surface, you control whether they are in your tree and at what version.

For direct dependencies with high or critical severity findings, check three things before acting:

• Is there a patched version available? If yes, update it, test, and close the finding.
• Is the vulnerability in a code path your application uses? Read the CVE description. A vulnerability in an HTTP parser only matters if you expose an HTTP server.
• Is the package still maintained? If the maintainer has not released a patch and shows no sign of doing so, that is a different problem than a simple version bump.

For transitive dependencies, move them to a separate list. You address these differently.

You have three real options for a vulnerable transitive dependency:

Override with npm overrides (package.json): Add an overrides block to force a specific version of the transitive package across your entire tree. This works when the patched version is API-compatible with the version your direct dependency expects.

{
  "overrides": {
    "vulnerable-package": ">=2.3.1"
  }
}

Test after applying this, if the transitive package has a breaking change, your direct dependency may fail in unexpected ways.

Accept and document: If the vulnerability requires attacker-controlled input to a code path that does not exist in your application (for example, a ReDoS in a URL parser your app never calls with user input), document the decision. Write a comment in your package.json or a SECURITY.md explaining why this finding is not exploitable in your context. This creates an audit trail and prevents the same finding being re-triaged next sprint.

Replace the direct dependency: If a direct dependency is the reason you have a vulnerable transitive package, and the maintainer is not addressing it, look for an alternative. This is the highest-effort option but sometimes the right one.

Create a separate tracking category for devDependency vulnerabilities. These are real but they represent developer machine risk and CI/CD pipeline risk, not production application risk.

For dev dependency vulnerabilities, the relevant question is: can an attacker exploit this during your build process? Supply chain attacks against build tooling are real (the XZ Utils attack targeted a build dependency). But a prototype pollution vulnerability in a test runner is not the same risk as the same vulnerability in your production HTTP server.

Practical filter: flag devDependency vulnerabilities where the attack vector is network (AV:N in CVSS) or where the package is involved in processing external input (like a template engine used in code generation). These deserve remediation. Flag devDependency vulnerabilities where the attack is local-only or requires attacker presence on the developer machine as lower priority.

npm audit has no understanding of your application's actual code paths. Socket Security and Snyk both offer static analysis that traces whether your application code actually calls the vulnerable function in the flagged dependency.

Socket's free tier analyzes your package.json and flags packages with active supply chain indicators, malware, dependency confusion, typosquatting, install scripts that exfiltrate data. This is more useful than CVSS scores for catching the class of attack that hit TanStack in May 2026.

Snyk's open-source tier adds reachability analysis: it tells you whether the vulnerable function in a transitive package is on a reachable code path from your application entry points. A finding marked 'not reachable' can be deprioritized without further investigation.

One-time triage solves today's backlog but does not prevent it from rebuilding. Three practices that keep the signal-to-noise ratio manageable:

Fail CI only on direct, exploitable, high-and-critical findings. Add npm audit --audit-level=high --omit=dev to your CI pipeline. This blocks merges on critical findings in production dependencies while not blocking work because of a theoretical vulnerability in a dev tool.

Run a weekly automated triage: Schedule a CI job that runs npm audit --json, filters to direct production dependencies with critical/high scores, and opens a GitHub issue if any exist. This keeps the finding list visible without requiring a developer to manually check.

Pin your lockfile and audit it on every dependency change. Most vulnerabilities enter via package updates, not initial installation. The npm ci command uses the lockfile exactly, pair it with an audit step that runs whenever package-lock.json changes.