Use a fixed event whenever you know the release that contains the fix. The OSV schema strongly recommends it over last_affected, because last_affected assumes the next release is fixed and can cause false negatives. Pair a range with an explicit versions list when the ecosystem's ordering is hard to compute.
How an OSV range works
An OSV entry lists affected packages. Each can carry ranges, and each range is a list of events, where each event has exactly one key:
| Event | Meaning |
|---|---|
| introduced | Where the bug begins. The value 0 means before any other version |
| fixed | The first version that contains the fix |
| last_affected | The last known vulnerable version at publication |
| limit | An upper bound, mostly for Git ranges |
An introduced of 0 followed by a fixed of 1.0.2 means everything before 1.0.2 is affected.
Why fixed is safer
The schema text says it is strongly recommended to use fixed instead of last_affected where possible. The reasoning is that last_affected can produce false negatives when the next release is assumed to contain the fix but does not. If you wrote last_affected 1.0.1 and then 1.0.2 shipped with the bug still there, users of 1.0.2 get no warning.
For Git ranges, the schema says to list every cherry-picked fix as its own fixed event so other branches are not wrongly flagged.
Range types
- SEMVER: versions follow SemVer 2.0.0 precedence, and ranges should not overlap.
- ECOSYSTEM: versions are uninterpreted strings in the ecosystem's own scheme. An enumerated versions list is recommended.
- GIT: introduced and fixed are full commit hashes and a repo is required. A versions list is still required, since evaluating the range needs the commit graph.
A version counts as affected if it lies in any one range or appears in the versions list.
Practical advice
- List versions explicitly as well as ranges for non-semver ecosystems, so tools do not need special logic.
- Do not mix a package-level severity with a top-level one.
- Use the alias field for other IDs of the same flaw. See GHSA, CVE and OSV identifiers.
- If you withdraw an entry, set the withdrawn timestamp and explain in the summary.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that the useful output is a specific fixed version, which is what the fixed event provides.
Quick check
What does introduced 0 mean?
The vulnerability exists before any other version, so every version up to the fixed event is affected.
When is a versions list needed?
For ECOSYSTEM and GIT ranges the schema recommends or requires one, because tools cannot always evaluate those ranges alone.
Safeguard's SBOM and dependency scanning matches your components against advisory ranges. Try a free scan.
Sources
Last reviewed: 19 October 2026.
