Read a dependency vulnerability report in this order: the package and your resolved version, the advisory identifier, the affected range, the fixed version, the dependency path, and then severity. Those six fields tell you whether you are affected, what to upgrade to, and who owns the change.
Definitions
Advisory identifier. The ID of the published record, such as a CVE, GHSA, GO or PYSEC number. One flaw can have several, linked as aliases.
Affected range. The versions the advisory says contain the flaw.
Fixed version. The first version that contains the fix, when one exists.
Dependency path. The chain from your project to the vulnerable package.
Fields in reading order
| Order | Field | Question it answers | Typical trap |
|---|---|---|---|
| 1 | Package and resolved version | What exactly is in my build? | Reading the range, not the resolved version |
| 2 | Advisory identifier | What is this called, and where do I read more? | Counting aliases as separate issues |
| 3 | Affected range | Is my version inside it? | Ranges that end at a last affected version, not a fix |
| 4 | Fixed version | What do I move to? | A fix that is a new major version |
| 5 | Dependency path | Who brings it in? | Several paths to one package |
| 6 | Severity | How bad in general? | Treating a score as risk to you |
The OSV schema expresses ranges with introduced and fixed events. A range can end at a fixed version or at a last affected version, and the schema warns that the last affected form can produce false negatives, since later versions are treated as unaffected.
A report in the wild
govulncheck separates its output into two parts. In the affected section, call stacks show your code calling the vulnerable function, with the module, the version found and the version in which it was fixed. In the informational section, the module is imported but no call stack reaches the flaw, and the tool says you may not need to take action. npm audit, by contrast, computes impact and remediation for the tree and tells you when a fix needs manual intervention.
Steps
- Sort the report by direct findings first, then by whether a fix exists.
- For each row, confirm the resolved version in your lockfile.
- Open the advisory. Look for affected functions, configurations and platforms.
- Check the fixed version for breaking changes.
- Trace the path and choose the closest parent to upgrade.
- Record the outcome: fixed, not affected, or accepted with a date.
What a report does not say
- Whether your code calls the flawed function, unless the tool does reachability.
- Whether the flaw is exploited in the wild. That needs other data.
- Whether a fix will break your build.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and find the six fields above.
Quick check
Why are there two IDs for one finding?
They are aliases. A flaw can be published as a CVE and as a GHSA record, and databases link them.
Is a high severity score always urgent?
No. Severity describes the flaw in general. Urgency depends on whether you use the affected code and how exposed it is.
Safeguard shows these fields for each finding and adds reachability analysis. A free scan lets you see a report on a repository.
Sources
Last reviewed: 19 October 2026.
