SBOM validation: completeness, format conformance and quality scoring

A valid SBOM is not necessarily a useful one. Validation has four layers: format conformance, field completeness, accuracy and quality. This explainer defines each and the baselines they are measured against.

Why validation matters

SBOMs arrive from many generators and suppliers, and their quality varies. CERT-In lists validating the SBOM to ensure its integrity among supplier objectives ^[1], and SEBI expects SBOMs for all core and critical software ^[2]. An SBOM that fails silently, for example by missing a lockfile ecosystem, gives false assurance. Validation has four layers.

1. Format conformance

Does the document conform to the schema of the format and version it declares? CycloneDX CLI validates against CycloneDX versions up to 1.7 and can return a non-zero exit code on errors ^[3]. SPDX tools-python validates SPDX 2.2 and 2.3 documents in several serialisations ^[4]. Conformance is necessary but weak: an empty component list can be valid.

2. Field completeness

Does each component carry the fields your baseline requires? Baselines differ:

The NTIA Conformance Checker tests SPDX documents against NTIA and FSCT minimums ^[9]. Completeness should be measured per component, since one component missing a supplier is a different problem from all of them missing one.

3. Unknowns versus omissions

An empty field can mean "does not exist", "unknown" or "withheld". The NTIA report asks authors to state explicitly where dependency information is unknown ^[10]. CISA's framing document distinguishes missing from inapplicable data and says redaction should occur only when contractually required ^[6], and the 2026 elements require withheld data to be distinguishable from unknown data ^[7]. Validators should treat declared unknowns differently from silent gaps.

4. Accuracy

Does the SBOM describe the artefact it claims to? Checks include matching the declared hash against the delivered artefact, comparing component counts against an independent analysis of the same image or binary, and confirming versions against lockfiles. CISA notes that analysed SBOMs can be used to verify SBOMs from other sources ^[11]. Signature verification confirms the SBOM came from its stated author; CycloneDX CLI supports signing and verifying BOMs ^[3].

Quality scoring

Quality scores summarise usefulness. sbomqs scores SPDX and CycloneDX SBOMs from 0 to 10 across categories including identification, provenance, integrity, completeness, licensing and structure, and runs compliance profiles such as NTIA and BSI TR-03183-2 ^[12]. Scores are most useful as a pipeline gate (for example, reject supplier SBOMs below a threshold) and as a trend per supplier. They do not replace accuracy checks.

Where to validate

• At generation, in CI/CD, so failures block a release.
• At intake, before a supplier SBOM enters your inventory.
• Periodically, because time-sensitive fields such as vulnerabilities, patch status and EOL date go stale ^[1].

For step-by-step commands, see how to validate an SBOM; for field detail, see the CERT-In 21 fields.

How IntelliXBOM helps

IntelliXBOM validates CycloneDX and SPDX SBOMs against configurable required-field policies, including CERT-In's list, on generation and on intake. It flags missing and stale fields, keeps validation results with each SBOM version, and includes them in timestamped compliance evidence.