When a call graph tool cannot tell where a call goes, it must guess. Over approximation keeps every possible target and reports some paths that are not real, which means false positives. Under approximation drops uncertain targets and misses some real paths, which means false negatives. Security triage needs to know which way a tool leans.
A small example
Your code calls an interface method. Three classes implement that interface. Only one is ever created at runtime, but a static tool cannot easily prove which.
- Over approximate: assume all three implementations might run. If one of them calls a vulnerable function, report a path. It may be a path that never executes.
- Under approximate: assume none, or pick one. You might miss the implementation that does call the vulnerable function.
What each choice costs
| Choice | Error you get | Effect on your team |
|---|---|---|
| Over approximate | False positives | More findings to read, some wasted effort |
| Under approximate | False negatives | A real exposure labeled not reachable |
For security, the second cost is usually worse because it is quiet. A false positive costs minutes of review. A false negative costs trust in the label.
What published tools say
The Go vulnerability checker documents that function pointer and interface calls are analyzed conservatively and that this may give false positives or inaccurate call stacks. It also says binary mode may report false positives for code that is in the binary but unreachable. And it states that reflection calls are invisible in source mode. So one tool is conservative in some places and blind in others, and says so.
How to evaluate a tool
- Ask which direction it leans for interfaces, callbacks and reflection.
- Plant a test: add a known vulnerable dependency, call it through an interface, and see whether the tool finds it.
- Plant the opposite: import a vulnerable package and never call it, and confirm it is flagged unreachable.
- Read a few call paths end to end.
See how to validate a reachability tool on your own code for the full plan.
Which should you prefer
For critical systems, leaning toward over approximation is the safer default, as long as the volume is manageable. For a very noisy backlog, a tighter result may be the only usable one. The right answer depends on what a miss costs you.
What to ask a vendor
Questions that get useful answers: which call types are resolved precisely, which are treated as possible, and which are ignored? Can I see the path behind a result? What does the tool do with reflection? A team that can answer these plainly has thought about the trade. A team that only says high accuracy has not told you which kind of error you are accepting.
Quick check
Is a false positive in reachability harmful?
It wastes review time but is the safer error. A false negative can hide a real exposure.
Can a tool avoid both errors?
Not for programs with dynamic behavior. It can reduce both and be honest about the trade.
Safeguard's reachability analysis sits within its dependency scanning. The free scan shows reported paths so you can judge them yourself.
Sources
Last reviewed: 19 October 2026.
