Treat a versionless SBOM component as an unknown, not as safe or vulnerable. Try to recover the version from other fields, ask the supplier, and report the item as unresolved until you can match it. Never let missing versions silently drop out of your vulnerability counts.
Why the version matters so much
Advisories describe affected ranges. In the OSV schema, a version counts as affected if it lies within a range or appears in the explicit versions list. Without a version you cannot run that test. A scanner has two choices: skip the component, which hides risk, or flag every advisory for the package name, which creates noise.
Where a missing version comes from
- The supplier's tool could not resolve it, for example from a vendored or copied file.
- The component was declared by name only, as a design intent.
- The file was edited or redacted before sharing.
- The package manager uses ranges and the generator recorded the range, not the resolved version.
Triage steps
- Count them. Report versionless components as a share of the whole file.
- Look elsewhere in the entry. A purl may carry the version after the at sign. Hashes, file names or download locations can also identify a release.
- Check for a sibling document. A supplier may have published a build or deployed SBOM that is more complete.
- Ask a specific question. "Which version of this component ships in release 5.2?" gets an answer. "Please improve your SBOM" does not.
- Set a fallback rule. For critical products, flag versionless components as unresolved findings with an owner and a due date.
- Recheck on the next revision. Close the item only when a version arrives.
A rule for each risk tier
| Component role | Handling |
|---|---|
| Internet facing or handles untrusted input | Unresolved finding, ask supplier within days |
| Internal library | Track as a data gap, ask at next revision |
| Test only | Note and move on |
Say it plainly to the supplier
You do not need to accuse anyone. Many versionless entries come from tooling limits. Attach the list of affected components, the products they sit in, and the format you can accept. The supplier can fix the generator once and benefit on every release.
Try it yourself
Click through it at your own pace, or open it full screen.
Scan the inventory for entries where the version column would be empty, and think about how you would route each one.
Where Safeguard fits
Safeguard's SBOM and dependency scanning works from resolved versions in your own code, which avoids this gap for what you build. For supplier files, you can run the free scan and review which components were left unmatched.
Quick check
Is a versionless component a finding?
It is a data quality issue. Record it as unresolved, and escalate based on how exposed the component is.
Can I guess the latest version?
No. Guessing creates false negatives and false positives. Ask the supplier or recover the version from a reliable field.
Sources
- OSV schema: how affected versions are determined.
- Package-URL introduction: purl as a package identifier.
Last reviewed: 19 October 2026.
