`npm audit` flags a critical CVE in a transitive dependency used in production. What's the right response?
Short answer
Transitive code runs in your app, so a critical CVE is your risk. Assess whether the vulnerable code path is actually reachable, then remediate by bumping or overriding the version (or mitigating) and verify in production. Ignoring it because it's transitive leaves a known hole an attacker can exploit. Suppressing the audit just hides the warning. Reinstalling node_modules pulls the same vulnerable version. Track it through SCA, don't silence it.
A transitive dependency is code you didn't pick directly but that still ships and executes inside your application. A critical CVE in it is your vulnerability, exactly as if it were in your own source. The professional response is triage then remediate, not dismissal.
The right response
- Assess reachability and exploitability. Does your app actually call the vulnerable function or path, with attacker-influenced input? A critical CVSS score in an unreachable code path is lower real-world risk than a "medium" you call on every request. This prioritizes work without ever ignoring the issue.
- Remediate. Upgrade the direct parent that pulls the bad version; if it hasn't released a fix, use a dependency
overrides/resolution to force the patched transitive version, or apply a documented mitigation (config, WAF, disabling the feature) as a stopgap. - Verify and redeploy, then confirm the advisory clears in your SCA tooling.
Why the distractors are wrong or risky
- Ignore it because it's transitive is a misunderstanding of how dependencies work — the code runs regardless of who declared it, and attackers don't care that you didn't write it.
- Delete node_modules and reinstall re-resolves to the same vulnerable version your lockfile/ranges allow. It changes nothing about the advisory.
- Suppress the audit warning hides the signal while the exploitable code stays in production — the worst outcome, because now no one is tracking it.
What the interviewer is probing
Whether you treat dependency risk as real and ownable, can prioritize with reachability rather than panicking over every red line, and know the concrete mechanics — overrides/resolutions, lockfile behavior, and SCA tracking — to actually drive the fix and keep it from silently regressing.
Likely follow-ups
- How do you force a fixed version of a transitive dependency when the direct parent hasn't updated?
- What does 'reachability' analysis add over a raw CVE count, and what are its limits?
- How would you prevent this from recurring across many repos?