When a developer says "we never call that code", treat it as a hypothesis, not an insult and not a fact. Ask where the vulnerable function lives, trace calls from the application's entry points to it, and record the result. If no path exists, you have evidence for a documented exception.
Why the claim is often right and still needs proof
Many dependencies bring in code the application never uses. A flaw in a rarely used function of a large library is often unreachable in a specific application. Developers know this, which is why a flat list of findings frustrates them.
The claim still needs proof for two reasons. Code can be reached indirectly, through another library, a plugin system, reflection or a framework default. And a claim in a chat message does not satisfy an auditor or a customer.
Turn the claim into a check
- Identify the vulnerable function. The advisory usually names a function, class or configuration. If it names just the package, say that the affected part is unknown.
- List the entry points. These are the places input arrives: routes, message consumers, scheduled jobs, command handlers, file imports.
- Trace the paths. Follow calls from each entry point toward the vulnerable function, including calls through other libraries.
- Check the conditions. Some flaws need a specific setting or input type. Confirm whether your configuration meets them.
- Record the outcome. Reachable, not reachable, or unknown, plus the date and the version checked.
Tools can do the tracing at scale. A person should still read the result for dynamic features such as reflection, which static analysis may not follow.
Three outcomes and what each means
| Result | What to do |
|---|---|
| Reachable | Treat it as a priority, patch or mitigate |
| Not reachable | Record it, set a review date, and still plan the upgrade |
| Unknown | Treat as possible until someone finishes the check |
"Not reachable" is not forever. A later change can introduce a call. Re-check when the code or the dependency changes, and keep the upgrade on the list as routine hygiene.
Have the conversation without friction
Start with agreement: "You may be right, and if so, we can close this with a note instead of an emergency." Then ask for help with the trace, since the developer knows the code. Offer to write up the result together. This turns a dispute into a shared task and gets a better record.
Avoid arguing from severity alone. A high score does not make the code reachable, and a developer's confidence does not make it unreachable.
Try it yourself
Click through the demo to see how reachability analysis separates findings that can be exercised from those that cannot, and how that changes the list.
Click through it at your own pace, or open it full screen.
Safeguard includes reachability analysis that does this tracing and records the result against each finding. The free scan at gold.safeguard.sh/scan lets you try it on your own project.
Quick check
Does "not reachable" mean I can skip the upgrade?
No. It lowers urgency. Keep the upgrade on the list because code and usage change.
Who should verify a "we never call that" claim?
The developer who owns the code, with a second person or a tool confirming the trace, and the result written down.
Last reviewed: 19 October 2026.
