A call graph is a map of a program in which each function is a point and each call from one function to another is an arrow. Security tools walk the arrows to see whether code you run can reach a vulnerable function inside a dependency. No path means the flaw is probably not exercised.
The simplest example
Imagine three functions. Main calls Load. Load calls Parse. Somewhere in a library there is also a function called Repair that has a known bug. Nothing calls Repair. The call graph has arrows from Main to Load and Load to Parse, and Repair sits alone.
A scanner that sees only package versions would flag the library. A scanner with the call graph sees that Repair is an island.
How the graph is built
Static analysis reads source code or compiled output without running it. For each function body it records the calls it finds. Joining those records across your code and every dependency gives the whole graph.
Direct calls are easy. The name is written right there. Trouble starts when the target is not known until runtime.
Where graphs get fuzzy
- Interfaces and virtual methods. The call goes to whatever object is present at runtime. Analysis must guess which implementations are possible.
- Function pointers and callbacks. Same issue: the target is a value, not a name.
- Reflection. Code looks up a method by a string and calls it. The Java tutorial documents this directly: a program can load classes by name and invoke methods by name at runtime.
- Generated or loaded code. Plugins and eval style features add code the analysis never saw.
The Go vulnerability checker documents its own version of this: calls made through the reflect package are not visible to static analysis, and interface and function pointer calls are handled conservatively.
Over and under approximation
When the analysis is unsure, it can lean two ways. Assuming a call might happen adds extra arrows and can report a path that is not real. That makes a false positive. Ignoring uncertain calls drops arrows and can miss a real path. That makes a false negative.
Good tools pick a side on purpose and say which. Ask your vendor or your own team which way yours leans. See over-approximation and under-approximation in call graphs.
Why a security reader should care
You do not need to build call graphs. You need to know three things. The graph is a model, not the truth. It is better on some languages than others. And a missing arrow is a claim you can check by reading the reported path.
Quick check
Is a call graph the same as a dependency graph?
No. A dependency graph shows which packages depend on which. A call graph is finer grained and shows which functions call which. Reachability needs the second.
Can a call graph be perfect?
Not for real programs that use dynamic features. It can be useful and checkable without being perfect.
Sources
Last reviewed: 19 October 2026.
