The problem: You have an SBOM that opens without an error, but you do not know whether it is valid, whether it is complete, or whether the component list can actually be used.
Validation is two different questions
The first question is structural: does the document match the schema for the specification version it declares? The second is practical: can each component be identified and versioned well enough for an advisory feed to match it? A file can pass the first and fail the second, which is why “valid” is not a useful answer on its own.
Keep the results separate. A schema error means the document is malformed; fix it before reading quality findings, because those findings may be computed from an incorrectly parsed tree. A quality finding means the document is well-formed but not fully usable.
Step 1: identify the format and the declared version
| Format | Accepted by the free validator | Notes |
|---|---|---|
| CycloneDX JSON 1.4 | Yes | Older fields may be rejected by later schemas, and the reverse. |
| CycloneDX JSON 1.5 | Yes | Common in current build tooling. |
| CycloneDX JSON 1.6 | Yes | Newer fields are only valid when 1.6 is declared. |
| SPDX 2.3 JSON | Yes | The SPDXID and relationship model differs from CycloneDX. |
| CycloneDX XML | No | Convert to JSON first; this build does not parse XML. |
| SPDX tag-value | No | Convert to SPDX JSON first. |
The declared version drives the schema check. A document that says 1.4 but uses a 1.6 field fails structurally, even though a newer tool would accept it. That mismatch is a generation problem, not a validator problem.
Steps 2–5: a validation order that finds the useful defects
- Validate the schema and fix structural errors at the reported path.
- Count the components and confirm the number is plausible for the build. Compare top-level and nested counts: a large nested tree that is not declared is a coverage problem.
- Check identifiers: purl first, then CPE. A component with only a name is structurally unmatchable, and no amount of scanning will fix that.
- Check versions: an exact release is required. Ranges, commit hashes, build dates and “unknown” are not exact versions.
- Resolve dependency references. Every dependsOn or relationship target should exist. Broken references usually mean the component was filtered out or renamed during generation.
Do this before the vulnerability scan
A scan against an inventory with missing identities will report fewer findings, not more. Fix the inventory first, then interpret the scan.
What a passing validation does not prove
- That the component list is complete for the firmware image. Validation checks what the document declares, not what the binary contains.
- That the components are free of vulnerabilities. That requires advisory matching and product context.
- That the product meets the CRA. Technical documentation, risk assessment and processes are outside a file check.
- That the supplier told the truth. Validation is a quality check on the document, not an audit of the supplier.
Scope and limits
- This guide covers document validation, not vulnerability scanning or binary composition analysis.
- The free validator accepts CycloneDX JSON 1.4–1.6 and SPDX 2.3 JSON only; XML and tag-value need conversion.
Sources
Next step
Validate a file and read the readiness reasons