Validate an SBOM in five steps: confirm it parses against the format schema, check the format version, sample the seven NTIA data fields, compare its contents to the real artifact, and confirm it matches the release you run. Fifteen minutes here prevents months of acting on bad data.
Step 1: does it parse?
Run the file through a validator for its stated format. CycloneDX and SPDX both publish schemas. A file that fails basic validation cannot be processed by automation, which is the point of using a standard format. The NTIA report names SPDX, CycloneDX, and SWID tags as formats supporting automation.
Step 2: which format version?
Formats change. CycloneDX lists version 1.7 as current on its overview page, and SPDX is standardized as ISO/IEC 5962:2021. Check that the version in the file is one your tools can read. Old versions may parse but lose features.
Step 3: sample the data fields
Pick thirty components and check supplier, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. Missing versions and identifiers are the most damaging, since they stop matching. Details in how to check a supplier SBOM.
Step 4: compare to the artifact
Take a handful of components from the file and verify them against the software itself: the lockfile, the image, or the package. Also go the other way. Pick a few dependencies you know are in the product and look for them in the SBOM. A valid file that omits known dependencies is not usable.
Step 5: does it match the release?
Check the product version and the timestamp. The NTIA report says a new build or release calls for a new SBOM. An SBOM for a different version is evidence about something else.
Record the outcome
Mark each SBOM accepted, accepted with gaps, or returned. For gaps, list what is missing and request a fix by a date. Keep the validation notes with the file.
Automate what you can
Steps 1 to 3 can run in a pipeline the moment an SBOM arrives. Steps 4 and 5 need judgment, but a script can compare version numbers.
When to push back
If a supplier refuses to fix missing versions or says nothing about known unknowns, treat that as a vendor risk signal. See known unknowns explained.
Safeguard can ingest SBOMs as part of its SBOM and dependency scanning. The free scan at https://gold.safeguard.sh/scan shows what the output looks like.
A short intake checklist
Write the five steps as a form: file received, schema valid, format version supported, fields sampled, artifact compared, release matched. Whoever receives an SBOM fills it in and files it with the vendor record. This takes the process out of one person's head and makes it repeatable. It also gives you a paper trail if a customer or auditor asks how you handle supplier SBOMs.
Quick check
Is schema validation enough?
No. It proves structure only. Check the content against the real software.
Sources
- NTIA, The Minimum Elements For a Software Bill of Materials
- CycloneDX specification overview
- SPDX overview
Last reviewed: 19 October 2026.
