No. Rice's theorem says that every non-trivial question about what a program does is undecidable in general, and whether code is ever reached is one of those questions. Real tools work anyway by accepting some error in a chosen direction. The practical goal is a useful, honest approximation, not perfection.
The one-paragraph theory
Rice's theorem states that all non-trivial semantic properties of programs are undecidable. A semantic property is about behaviour, such as "does this function ever run?", as opposed to a syntactic one, such as "does the file contain an if statement?". A property is non-trivial if some programs have it and some do not. "Is this vulnerable function ever called?" fits.
You do not need the proof. You need the consequence: no tool, from any vendor, can promise a correct answer on every program.
How tools live with that
Tools choose which way to be wrong.
- Sound-leaning tools report a path whenever one might exist. They rarely say "not reachable" wrongly, but they report extra reachable findings.
- Precision-leaning tools report a path only when they are fairly sure. They produce fewer findings and risk missing a real one.
- Mixed tools report a confidence level or an unknown state, so people can decide.
Which is right depends on the decision. For a risk acceptance, you want a tool that leans toward caution. For a nightly backlog sort, a tool that leans toward fewer findings may be fine, as long as the unreachable bucket is revisited when things change.
Why it still pays off
Imperfect does not mean useless. Most dependency vulnerability alerts sit in packages where your code never touches the affected function. Removing even a share of those from the urgent queue frees time. The error that matters is the wrong "safe" label, so design your process to catch it:
- Keep the evidence with every "not reachable" decision.
- Re-run analysis when a dependency or an entry point changes.
- Spot check a sample of unreachable findings each quarter.
- Keep exposure and exploit signals in the decision, not reachability alone.
Questions to put to any reachability claim
| Question | Why it matters |
|---|---|
| Which direction does it err? | Tells you the risk of a false safe label |
| Does it report unknown? | Shows whether uncertainty is hidden |
| Can you see the call path? | Lets a person verify |
| What does it assume about reflection and plugins? | These are the usual gaps |
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings move out of the urgent list and what evidence supports each move.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
If it is undecidable, why do vendors sell it?
Because approximations are useful. The claim to doubt is "perfect", not "helpful".
Does this mean I should ignore reachability results?
No. Use them to order work, keep the evidence, and revisit unreachable decisions when your code or dependencies change.
Sources
Last reviewed: 19 October 2026.
