How to Validate an SBOM Beyond Passing the JSON Schema

An SBOM can pass its JSON schema and still be unusable for a firmware vulnerability review. Validate its structure first, then ask whether component identities, dependency links and release coverage match the product you actually ship.

This tutorial uses two deliberately synthetic CycloneDX fixtures. They describe invented demo packages, not a Cenitia product or a customer's firmware. Use the review worksheet and download the weak fixture and improved fixture.

Keep three different checks separate

Schema validation asks whether the document conforms to the selected format version. Semantic checks ask whether references and identities make sense. Coverage checks compare the document with independent build and release evidence.

Passing the first two cannot establish the third. A perfectly structured document can omit an entire bootloader or vendor binary. Conversely, an unknown version may be an honest gap that needs investigation rather than a reason to invent a version string.

The fixtures use CycloneDX 1.7 and its official JSON schema. Our structural run disables JSON Schema format checks, so it is not exhaustive format validation. Pin the format and validator in your run record. Do not silently validate an older document using a newer schema and call the result equivalent.

Inspect identity before running vulnerability matching

Look for a product identity, release version and relationship to the firmware artefact. Then inspect each component's name, version, supplier or provenance and identifiers where applicable. Preserve local modifications and vendor patches in supporting evidence.

Package names alone are ambiguous. A demo component called netlib does not identify a particular upstream project, build option or vulnerability exposure. A package URL or other identifier can improve matching, but a guessed identifier creates false confidence.

Document unresolved identities in a gap register with an owner. If a binary has no trustworthy version information, retain its hash and supplier reference and explain the limitation. “Unknown” is useful when it is specific and actionable.

Use a weak fixture to expose your assumptions

The weak fixture is intentionally small: a product and one library with a vague identity. It can meet schema requirements while lacking a useful component version and an explicit dependency graph.

The improved fixture identifies a fictional firmware release and two fictional components, with consistent references and a root dependency relationship. Its package URLs use the generic package type because these are demo identities. They are not assertions that matching public packages exist.

Our companion validator checks schema validity, duplicate component references, unresolved dependency references, missing versions and the root dependency entry. It is an editorial demonstration, not a universal SBOM certification tool. Some valid SBOMs legitimately use different structures or identity strategies.

Compare the SBOM with independent release records

These are our recommended comparison inputs. The applicable legal scope and disclosure obligations need a separate assessment. A schema pass is not a finding of CRA conformity.

Record the result so another engineer can repeat it

Keep the input hashes, generation command, tool version, schema URL and digest, validator version, raw output and reviewed exceptions. Run the checks in the release process and keep the output with the release, rather than validating whichever file happens to be on a laptop later.

The demonstration runner and actual local results are included in the editorial verification record. Its negative checks are intentional: the weak fixture should pass structure while producing quality warnings. The improved fixture should resolve those demonstrated warnings without being described as complete product coverage.

Decide what happens when a check fails

Structural errors normally return to the generator or document author. Identity gaps go to the component owner. Coverage gaps may require a different extraction method or supplier evidence. State whether each gap blocks release and who can approve an exception.

For format background, see our SPDX and CycloneDX comparison. The synthetic fixtures cannot prove coverage of any actual device.

CRA applicability and timing

Most CRA product obligations apply from 11 December 2027; manufacturer Article 14 reporting applies from 11 September 2026. Check the product scope, role and specific transitional provisions before treating a future requirement as a current duty. See the Commission manufacturer guidance and reporting guidance.