adjudicating-dependency-cve-reachability

# Adjudicating dependency-CVE reachability: affected, or just noisy? A scanner that lists every CVE in your dependency tree is measuring your `package.json`, not your exposure. Most flagged CVEs are unreachable: you never call the vulnerable function, or you call it in a way the bug does not trigger, or no attacker-controlled input gets there. Adjudicating reachability turns a wall of red into the short list that actually matters, and gives you a defensible reason for each one you set aside. ## When to use - An SCA tool, dependency bot, or advisory flagged a CVE in a library you use. - You are drowning in "critical" dependency alerts and need to triage by exposure. - You must justify a "not affected" status (for an auditor, a VEX statement, a customer) with evidence, not a guess. - You are deciding whether an urgent patch is actually urgent for *you*. ## Scope check Authorized source only (your own application and the dependencies it ships). If you can't name the authorization, stop. ## The loop 1. **Pin the vulnerable symbol.** From the advisory and, crucially, the *fix commit*, identify the exact vulnerable function(s) or sink in the dependency and the affected version range. "The library is vulnerable" is not actionable; "`parse_untrusted()` before v2.3 is vulnerable when called with X" is. Reading the patch tells you precisely what is unsafe and under what condition. 2. **Test call-path reachability.** Does any path from your own entry points reach ...