Reachable means a call path to the vulnerable function was found. It does not mean an attacker can use it. Unreachable means no path was found. It does not mean safe forever. Six myths come up again and again when teams start using reachability, and each one changes how you triage.
Myth 1: Reachable means exploitable
Fact. Reachable is a necessary condition for many flaws, not a sufficient one. The attacker still needs to control the input that reaches the function, and the right conditions must hold. The VEX specification reflects this with a separate justification label, vulnerable code cannot be controlled by adversary, distinct from the label for code not in the execute path.
Myth 2: Unreachable means safe
Fact. It means no path was found in the analyzed code. Dynamic features can hide paths, and later changes can add them. Treat it as a lower priority with a re-check date.
Myth 3: Reachability replaces severity scoring
Fact. CVSS describes the intrinsic severity of a flaw, and its own guide says it should not be used alone to assess risk. Reachability adds context about your code. You need both, plus exposure.
Myth 4: Reachability gives a yes or no every time
Fact. Some tools return levels, such as package imported, function present, or call path found. Others fall back to package level when symbol data is missing. Read what level a result is.
Myth 5: It works equally across languages
Fact. Languages with static types and simple call resolution give cleaner graphs than those with heavy runtime dispatch. Precision varies, and coverage notes in a tool's documentation matter.
Myth 6: Once a tool says not reachable, remove the finding
Fact. Keep it, with a reason. An auditor, a customer or your future self may ask why it was set aside. A not affected statement should carry a justification, and the OpenVEX specification requires either a justification label or an impact statement.
What to do instead
- Use reachability to sort, not to delete.
- Combine it with severity, exposure and exploitation data.
- Record the reason and date for every set aside finding.
- Re-check on change.
A short scenario
Two findings land on the same day. One is a critical flaw with no call path in your code. The other is a medium flaw with a call path from a public endpoint that passes user input straight in. Rank by severity alone and you fix the wrong one first. Rank by reachability alone and you might ignore a critical flaw that a small refactor will wake up. Use the signals together, and write down why you chose the order.
Quick check
Which myth causes the most damage?
Unreachable means safe. It leads teams to stop looking at items that can become live after a small code change.
What replaces a yes or no answer?
A level and evidence: the path shown, the data source, and the date analyzed.
Safeguard includes reachability analysis in dependency scanning. Try the free scan to see a path for a real project.
Sources
Last reviewed: 19 October 2026.
