A trustworthy reachability report shows more than a reachable or not label. It lists the vulnerable function, the entry points assumed, the call path, the build configuration, the data source and any unresolved dynamic calls. If a report hides these, you cannot check it, and you should not use it to defend a decision.
The checklist
- Finding identity. Package, version, advisory identifier.
- Vulnerable location. The function or symbol, and whether the advisory named it or the tool inferred it.
- Result state. Reachable, not reachable or unknown, with no silent fourth category.
- Call path. A readable chain from an entry point to the vulnerable function, for reachable findings.
- Entry points. Which were assumed, and whether you could add your own.
- Scope. Production, test or build tooling.
- Build configuration. Version, platform, flags and the resolved dependency set.
- Unresolved dynamic sites. Reflection, dynamic loading or plugin calls that could not be followed.
- Date and tool version. Results age, and tools change.
- Next recheck trigger. What event should cause a new run.
How to score a report
| Items present | Reading |
|---|---|
| 9 to 10 | Strong enough for a formal decision |
| 6 to 8 | Fine for triage, add evidence before an exception |
| Fewer than 6 | Treat as a hint only |
This is a rule of thumb, not a standard. Adjust it to your own risk appetite.
Why each item earns its place
The call graph literature is clear that static graphs are approximations, and that the exact answer is undecidable. A report that does not tell you where its approximation might be wrong asks for blind trust. Items 5, 7 and 8 show you the edges of what was analysed. Item 4 lets a person verify, which is the strongest check of all.
Using it in a proof of concept
Ask each tool you evaluate for a sample report on a repository you know well. Score it against the list. Then add one seeded reachable function and one seeded unreachable function, and see whether the report gets both right and says how it knows.
For audit and customer questions
If you cite reachability in a security questionnaire or an audit response, attach or reference a report that meets most of these items. A short reasoned answer with evidence is more convincing than a high count of "not reachable" findings.
Try it yourself
Click through it at your own pace, or open it full screen. Notice what evidence is shown beside each verdict.
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
Is a call path always required?
For reachable findings, yes, since it is the quickest way to verify. For not reachable findings, the evidence is the scope and configuration assumed.
How often should a report be refreshed?
When dependencies, entry points or build settings change, and on a regular schedule as a backstop.
Sources
Last reviewed: 19 October 2026.
