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 that vulnerable function, directly or transitively? If nothing in your code (or the code you actually invoke) calls it, you are not reachable through the static graph. Record that, but note the blind spots below before you call it clean.

3. Check the trigger preconditions. Reaching the function is not enough. The CVE usually needs a specific argument shape, a config flag enabled, a feature in use, or a size or option the safe callers never pass. Confirm whether your call sites actually satisfy the condition the fix now rejects. Many "reachable" CVEs die here because you always call the safe overload or pass the safe flag.

4. Trace attacker control to the trigger. Reachable plus triggerable still needs an attacker in the loop. Trace from your untrusted entry points to the vulnerable argument. If only trusted, developer-supplied constants reach it, the exposure is theoretical. If untrusted input reaches the dangerous argument and satisfies the precondition, you have a real, reachable exposure.

5. Decide and record. Reachable + triggerable + attacker-controlled = confirmed affected; set severity from real impact in your context, not the advisory's generic score. Any leg failing = killed / not-affected, with the exact reason (symbol never called / precondition never met / input not attacker-controlled). Keep the not-affected record; the same CVE will be re-flagged next scan and you should not re-triage from scratch.

Blind spots that turn "unreachable" into "unknown"

• Dynamic dispatch and reflection. A call made through configuration, a plugin loader, dependency injection, getattr/eval, or a virtual/interface dispatch may not appear as a static edge. "No path" through one of these is inconclusive; confirm by reading how the call is wired.
• Transitive and vendored copies. The vulnerable code may arrive through a second dependency, a bundled/vendored copy, or a lockfile pin the manifest hides. Resolve what you actually ship, not what the top-level manifest lists.
• Build-time vs run-time. A dev/build-only dependency has a different exposure than one on the request path. Say which you are judging.

Worked example (a kill and a confirm)

Kill. CVE in a YAML library: full_load deserializes arbitrary objects. Pinning the symbol and searching your call sites shows you only ever call safe_load; full_load is never reached from your code. Killed / not-affected, kill_reason = "vulnerable symbol full_load not on any call path; only safe_load is used."

Confirm. CVE in an image-decoding library: a crafted file triggers a heap overflow in decode_frame. Your avatar-upload handler passes user-uploaded bytes straight into the library's decode entry, which reaches decode_frame, and the affected version is the one you ship. Attacker controls the file. Confirmed affected, high, remediation = upgrade past the fixed version or gate uploads through a safe re-encoder.

Rationalizations to reject

• "It's rated critical, patch it now." → Critical to someone with a different call graph. Adjudicate your reachability before you triage priority.
• "We import the library, so we're affected." → Importing is not calling. The vulnerable symbol may never be on a path you execute.
• "It's reachable, so it's exploitable." → Not without the trigger precondition and attacker-controlled input. Check both.
• "No static path, so we're clean." → Only if the call could not be made through reflection, config, or a plugin. Confirm the blind spots.

Executing this in practice

You need to read the dependency's fix to pin the vulnerable symbol and condition, a call graph that spans your code into the dependency (including transitive and vendored code) to test reachability, and a way to trace untrusted input to the trigger argument. A code property graph built over your app plus its resolved dependencies answers all three; without one, you read the call sites and the patch by hand. The verdict is yours; the graph only shows the paths.

Related

• extracting-nday-from-a-patch - reading the dependency's fix to pin exactly what is vulnerable and how it triggers.
• adjudicating-taint-paths - tracing attacker control from your entry points to the trigger argument.
• FINDING-SCHEMA.md - the shape every affected and not-affected decision takes.