How a scanner links a CVE to a specific vulnerable function

To say a CVE is reachable, a scanner must know which function holds the flaw. That symbol data comes from curated advisory records, from patch analysis, or from research. Many advisories list only affected versions. When function data is missing, a scanner falls back to package level matching.

Two kinds of advisory data

A version record says that versions from one release up to a fixed release are affected. A symbol record adds the package path and function names where the flaw lives.

The OSV schema is built around version ranges, with introduced and fixed events. For richer detail it offers an ecosystem specific object whose meaning is defined by each ecosystem. The schema's own examples show the Go ecosystem including affected functions there and a Rust example using a functions key. It does not require such fields.

Where Go does it well

The Go vulnerability database says each entry is reviewed so that the description, package and symbol information, and version details are accurate. That is why the Go checker can speak about functions. Symbol information is part of the review.

Other ecosystems vary. Some advisories name functions in free text. Some name nothing.

How tools fill the gaps

• Human curation. Analysts read the fix commit and write down the changed functions.
• Patch diffing. Tooling compares the vulnerable and fixed versions and flags changed functions as likely locations.
• Vendor research. A team adds symbol data to its own database.
• Fallback. With no symbols, the tool marks the whole package as the unit and cannot say more.

What it means for your results

When symbols exist, you get a precise answer: path found, or not. When they do not, you get a package level answer, and the finding should be labeled that way. A tool that says not reachable without symbol data deserves a question about what it checked.

Ask three things of any report:

1. Is the vulnerable function named?
2. Where did that name come from?
3. Was the call path shown, so I can read it?

Patch diffing has limits

Changed functions in a fix are a good guess, not a guarantee. A fix can touch a helper while the dangerous entry is another function. Curated data is slower to produce and often better.

A quick worked case

Suppose an advisory says versions 1.0 through 1.4.2 of a library are affected and 1.4.3 fixes it. The record names no function. Your scanner can tell you that you run 1.4.1 and should upgrade. It cannot tell you whether your code touches the flawed code. If a second advisory for the same library names the exact parser function, the scanner can say much more about that one. Two findings on one package can therefore carry very different levels of evidence, and a good report shows which is which.

Quick check

Safeguard pairs reachability analysis with SBOM and dependency scanning. Try the free scan to see how findings are presented.

Sources

• OSV schema specification
• Go vulnerability management

Last reviewed: 19 October 2026.