## TL;DR
Do not fix npm audit output top to bottom; triage by whether the vulnerable code is actually reachable from your app, fix the reachable and the directly depended-on first, and document the rest as accepted or scheduled instead of staring at them every run. Alert fatigue ends when the list stops crying wolf.

## The query
```text
how to triage npm audit output without alert fatigue
```

## Use this when
- `npm audit` reports dozens or hundreds of findings and nobody acts on them
- You need to decide which findings block a release
- The team has started ignoring the audit output entirely
- You want a repeatable weekly or per-PR dependency review

## Not for
- Patch management for servers and OS packages
- Other ecosystems (pip, cargo, go); the ideas transfer, the commands do not
- Secure coding practices

## Steps

1. Get the full picture in a parseable form: run the audit with JSON output so you can sort and filter instead of scrolling. Note the counts by severity, then set severity aside for a moment.
   Expected output: a structured list of every finding with package, severity, and dependency path.

2. Separate direct from transitive dependencies. Your direct dependencies are your responsibility and your leverage; transitive ones you fix by upgrading the direct parent or waiting for it. Group the findings accordingly.
   Expected output: two lists, direct and transitive, with the direct list much shorter.

3. Check reachability for the scary ones: is the vulnerable function actually called in your code paths? Tools that trace which dependency code your app loads turn 200 findings into a dozen that matter. Unreachable code is still worth scheduling, but it is not a fire.
   Expected output: each high or critical finding marked reachable, unreachable, or unknown.

4. Fix in this order: reachable highs and criticals first (upgrade the direct dependency, or patch the transitive one if the parent lags), then reachable mediums, then schedule the unreachable. Test after each upgrade; dependency bumps break things.
   Expected output: the reachable list shrinks to zero; the scheduled list has dates.

5. Handle the unactionables explicitly: no fix available, fix only in a breaking major, or dev-only dependency not shipped to production. Record each with a reason and a review date instead of leaving it red forever.
   Expected output: every remaining finding has an owner, a reason, and an expiry.

6. Make it routine and quiet: run the audit in CI on a schedule, alert only on new reachable findings, and review the accepted list monthly. The goal is a feed that only speaks when something changed.
   Expected output: a CI job that is green most weeks and red only for genuinely new risk.

## Variant phrasings
### "npm audit fix breaks everything"
That is why step 4 says test after each upgrade and step 2 says group by direct parent: upgrade one parent at a time, run the suite, and stop guessing.
### "ignore npm audit dev dependencies"
Do not blanket-ignore; instead triage them as usually-unreachable-but-scheduled. Build-time compromise is real, it is just a different threat model from runtime.
### "npm audit alternative less noisy"
The noise is mostly a triage problem, not a tool problem. Reachability analysis plus new-findings-only alerting quiets any scanner.

## Why this happens
npm audit reports every vulnerable package in the tree, including transitive dev dependencies whose vulnerable functions your app never loads. Teams see hundreds of red lines, fix nothing because fixing everything is impossible, and then miss the three that matter. Triage restores the signal.

## Edge cases and pitfalls
- `npm audit fix` can silently upgrade across ranges you did not intend; review the lockfile diff.
- A finding marked unreachable today becomes reachable after the next feature; re-check reachability when dependencies change, not once.
- Private registries and vendored packages need their own audit path; the public advisory data may not cover them.
- Do not suppress findings by editing the audit output; use the documented exception record from step 5.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zQ_NuthTIew6ocES0qAumw