Triage reachability and impact

A vulnerability identifier is the start of investigation. Product context determines urgency and containment.

Severity scores rank the bug in the abstract, not in your product. A critical advisory affects an XML parser used only by a local documentation command. Another medium advisory affects an internet-facing parser running with database access. Severity alone would rank them in the wrong operational order.

Confirm the basics first

Verify the installed version actually falls in the affected range:

npm ls lodash
# └─┬ [email protected]
#   └── [email protected]

The advisory says “fixed in 4.17.21”, and you run 4.17.20 — confirmed affected. Also check where it runs: a finding that disappears with npm audit --omit=dev lives only in development tooling, which changes the exposure story without making it automatically safe (dev tools run in CI, next to tokens).

Trace reachability

Next question: does the vulnerable function reach production? Read the advisory to learn which behavior is vulnerable — a specific function, a parsing mode, a configuration. Then check whether your code, or the dependency path into it, exercises that behavior:

npm explain lodash
grep -rn "template(" src/

If the vulnerable function is lodash.template and nothing in your graph calls it, the risk drops sharply. Write that evidence down; a bare “not exploitable” claim is worthless in six months.

Then consider attacker prerequisites and worst credible impact. Who can reach the vulnerable code path — anonymous internet users, or only admins? What privileges and data does the process hold when it runs?

Prioritize with evidence, not forever

Patch high-impact reachable paths quickly, but continue tracking lower-risk findings with evidence and deadlines.

Reachability evidence can justify priority, but it can become an excuse to postpone patches forever. Code changes, and last quarter’s unreachable function becomes this quarter’s hot path. Give every accepted delay an owner and review date.

Triage one real advisory by recording the installed version, vulnerable function, runtime path, attacker prerequisites, privileges, data exposure, and fix. Save evidence for each conclusion. Then force the vulnerable feature into a test build or disable the suspected call path and verify whether the reachability conclusion changes.