Yes. The CVE record format has optional fields for affected modules, program files and program routines, so a CNA can say which function or file contains the flaw. Because the fields are optional, many records leave them out, and tools cannot count on them being there.
The three fields
The CVE schema defines these on each affected product entry:
| Field | What it holds |
|---|---|
| modules | Affected components, features, sub-products, APIs, commands, utilities or functionality |
| programFiles | Names or paths of affected source code files |
| programRoutines | Affected functions, methods, subroutines or procedures, each with a name |
All three are described as optional. The schema also has a platforms list for flaws that matter only on certain operating systems, hardware or architectures, and says that a missing or empty list implies the other fields apply to all relevant platforms.
Why this matters for triage
A package level advisory says "library X, versions below 2.4.1". That tells you to upgrade, but not whether your code ever touches the broken part. A routine name lets a tool ask a sharper question: does any call path from your code reach this function? That is the idea behind reachability analysis.
Without a routine name, a tool can still reason from the code diff in the fix, but that takes more work and is less certain.
Where else function data lives
| Source | Where the function level data sits |
|---|---|
| CVE record | programRoutines, programFiles, modules on the affected entry |
| Go vulnerability database | ecosystem_specific.imports, with import paths and symbols |
| Python advisory database | An ecosystem_specific imports field listing affected modules and attributes, which the project says helps reduce false positives |
The Go documentation states that affected import paths and symbols can be listed, optionally with operating system and architecture values. So function level data exists in several formats, none universal.
Steps to use it
- Open the CVE record and read the affected entries.
- Check whether
programRoutines,programFilesormodulesare present. - If yes, search your code for calls to those names.
- If not, read the vendor advisory and the fix commit for the changed functions.
- Record the result: called, not called, or unknown.
- Treat unknown as affected until you can show otherwise.
What not to conclude
A function name in a record is the CNA's claim and may be incomplete. Absence of a call in your first party code does not rule out a call through another library. And a record without routines does not mean every function is at risk. See does reachability analysis need the advisory to name the function for how tools cope.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are separated once the affected code path is checked against your calls.
Safeguard reachability analysis checks whether your code reaches the vulnerable code, on top of SBOM and dependency scanning. A free scan shows the result on your project.
Quick check
Do all CVE records list the vulnerable function?
No. The fields are optional and many records omit them.
Does a missing function name mean the flaw is everywhere in the package?
No. It means the record does not say. Check the vendor advisory and the fix commit.
Sources
Last reviewed: 19 October 2026.
