A scanner takes your package name and version, finds advisories for that package, and checks whether your version falls inside an affected range, from the version that introduced the flaw to the one that fixed it. A miss happens when the name, version format or range data does not line up.
The structure of an advisory range
The OSV schema describes how affected versions are recorded. A range has a type and a list of events such as introduced and fixed. For the SEMVER type, the introduced and fixed values are semantic versions as defined by SemVer 2.0.0, with no leading v, and ordering follows the SemVer precedence rules. The schema also provides an ECOSYSTEM type for ecosystems with their own version ordering, and a GIT type for commit ranges. A version is affected if it is at or after an introduced event and before the next fixed event.
Where the comparison breaks
| Cause | What happens |
|---|---|
| Version string not parseable | Component cannot be compared, often skipped |
| Different ecosystem rules | Ordering differs, wrong verdict |
| Package name mismatch | Advisory never looked up |
| Advisory lists only some branches | Your branch looks unaffected or unknown |
| Fix backported by a distribution | Version looks vulnerable, fix is present |
The last row produces a false positive rather than a miss. The others lean toward misses.
Why the ecosystem matters
The OSV schema ties each advisory to an ecosystem and package name, and says ranges of type SEMVER should not overlap. A scanner must apply the ordering rules of the right ecosystem. A comparison written for one scheme, applied to another, can say a version is newer when it is older.
Checking one finding by hand
- Take the package and version from your lockfile.
- Query the advisory source for that package. See check a package version for known vulnerabilities with an OSV query.
- Read the introduced and fixed events.
- Place your version relative to them.
- Compare your verdict with the scanner's.
If you disagree, the cause is usually one of the table rows.
Reducing misses
- Use exact versions from lockfiles, not ranges from manifests.
- Keep scanner data sources current.
- Treat unparseable versions as unresolved rather than safe. See what does an unresolved component mean.
- Spot check a sample of findings and non findings against the source advisories.
Also remember that an in range version is a possible exposure, not proof the flaw is reachable in your code.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an affected version still needs a check on whether the issue applies to you.
Safeguard offers dependency scanning, reachability analysis and a free scan at gold.safeguard.sh/scan. Spot check any tool's verdicts against the advisory.
Quick check
What if my version is not listed at all?
It may be unaffected or the data may be incomplete. Check the advisory text and the project's own notes.
Does being in range mean I am exploitable?
No. It means the version is affected, and you still need to see whether the vulnerable code path is used.
Sources
Last reviewed: 19 October 2026.
