Yes, for function-level results. A tool can only ask whether your code reaches the vulnerable function if it knows which function that is. When an advisory names only a package and a version range, the tool falls back to package-level answers, such as "imported", unless someone adds the function detail.
Two inputs, not one
Reachability needs two pieces:
- Your code's call graph, built from your source and dependencies.
- The vulnerable location, the function or symbol an advisory points to.
The first you control. The second comes from advisory data, which varies in quality. The Go team's tooling illustrates the benefit when the data exists: the govulncheck documentation describes narrowing reports by analysing source code or a binary's symbol table, which relies on the vulnerability database identifying affected symbols. The tutorial output separates calls to a vulnerable function from mere imports of an affected package.
What you see when the detail is missing
| Advisory detail | What a tool can say |
|---|---|
| Package and version range only | Present or imported, not called or uncalled |
| Package, version, and affected function or module | Function-level reachable or not reachable |
| Free text description mentioning a function | Needs a person or model to extract it, with care |
That is why two tools can disagree on the same finding. One may have function data for the advisory and the other may not.
How to fill the gap
- Read the advisory text. Descriptions often name the parser, the option or the endpoint involved.
- Check the fix commit. The changed functions in the patch point to the vulnerable code. Verify by reading the diff, not by trusting a summary.
- Map to your use. Search your code for calls into the named function or the feature it belongs to.
- Record what you did. In your ticket, note whether the function was named by the advisory or inferred from the patch.
- Stay cautious. An inferred function can be incomplete, so use package-level treatment unless you are confident.
Be careful with extracted data
If a tool uses a language model to extract the vulnerable function from advisory text, treat the extraction as a hint. Spot check a sample against the patch. A wrong function name produces a confident wrong answer.
Why it matters for audits
A statement that says "not reachable" should say whether it is based on a named function or on a heuristic. Reviewers can then judge how much weight to give it.
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
What if the advisory names no function?
Use package-level handling by default, or derive the function from the fix commit and note that it is inferred.
Why do tools disagree on the same CVE?
They may use different advisory data, different call graph assumptions or different entry points.
Sources
- govulncheck command documentation, pkg.go.dev
- Tutorial: Find and fix vulnerable dependencies with govulncheck, go.dev
Last reviewed: 19 October 2026.
