SBOM quality checklist: how to validate the SBOMs your suppliers send

The three layers of SBOM quality

Layer	Question	What checks it	What it cannot tell you
Valid	Does the file parse, and does it follow the schema of the format and version it declares?	Schema validators	Whether any field is filled with something useful
Usable	Are the fields you need there, and can a tool use them: identifiers that match advisories, licenses, hashes, relationships?	Field checks, compliance profiles and quality scores	What is missing from the file
Complete	Does it list everything in the software you received?	Comparison with the build, or with an analysis of the delivered binary	Nothing that reads only the SBOM can answer this

Most receiving teams stop at the first layer. "The file validates" is the start of the check, not the result. The third layer is SBOM completeness.

The frameworks in one minute

Name the framework in every request and every piece of feedback, so the bar is a published one and not your opinion.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 July 2021). Seven data fields (supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data, timestamp), automation support in SPDX, CycloneDX or SWID tags, and practices: frequency, depth, known unknowns, distribution and delivery, access control, accommodation of mistakes. Hashes, licenses, lifecycle phase and signatures are listed as recommended, beyond the minimum.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 July 2026, after a draft on 22 August 2025). Replaces the NTIA elements. Written by 18 organizations from 14 countries, among them CISA, the NSA, the FBI, Germany's BSI and Japan's METI and NCO. It has 17 data fields, ten of them new: SBOM author signature, data format name, data format version, generation context, tool name, tool version, SBOM version, component hash value, component hash algorithm and component license. "Supplier name" becomes "Component Producer". Its practices are coverage, explicitly identifying unknown information, machine-processable data, accommodation of updates, frequency, and distribution and delivery. The document phrases each element with "should" and says it does not create new requirements; buyers make it binding by writing it into contracts.
• BSI, TR-03183-2 version 2.1.0 (20 August 2025), Germany. The strictest of the three, written with MUST: JSON or XML, CycloneDX 1.6 or later or SPDX 3.0.1 or later, one SBOM per software version, recursive dependency resolution with the completeness of each dependency list stated, a SHA-512 hash of each deployable component, the component's filename, distribution licenses as SPDX identifiers, and package URL or CPE "if it exists". It also says an SBOM must not contain vulnerability information; that belongs in a VEX document or an advisory.
• International alignment. A Shared Vision of SBOM for Cybersecurity (3 September 2025) is signed by 18 organizations from 15 countries. G7 work on SBOMs is about AI systems ("A shared G7 vision on SBOM for AI", 2025, and "SBOM for AI – Minimum Elements", May 2026) and sets no requirements for embedded supplier SBOMs.
• Automotive. Auto-ISAC published an SBOM Informational Report on 11 February 2025.

The checklist

How to read the cells: Required means the document says must. Minimum element means it is in that document's minimum list (NTIA's baseline, or CISA's "should" elements). Recommended means the document lists it beyond the minimum. Not mentioned means the document does not ask for it. How to test each check, and the feedback line to send, follow in the next section.

SBOM-level checks

Check	Why it matters	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Parses and validates against its declared schema	A file your tools cannot read is not an SBOM	Required: SPDX, CycloneDX or SWID tags	Practice: machine-processable SPDX or CycloneDX	Required: JSON or XML
2. Spec version meets your floor	Old versions cannot carry fields you need	Not mentioned	Minimum element: data format name and version; avoid deprecated versions	Required: CycloneDX 1.6+ or SPDX 3.0.1+
3. SBOM author	Someone answers for the content	Minimum element: "Author of SBOM Data"	Minimum element: "SBOM Author", the organization, not the tool	Required: "Creator of the SBOM", email or URL
4. Timestamp	Tells you which SBOM is current	Minimum element	Minimum element	Required; UTC recommended
5. Tool name and version	Tells you what the SBOM can be trusted to cover	Not mentioned	Minimum element	Not mentioned
6. Generation context	A source scan and a build record of the same release differ	Recommended: lifecycle phase ("source", "build", "post-build")	Minimum element: "before build", "build" or "after build"	No field; the content must match what was available during the build
7. SBOM version or serial number	Tells a correction apart from the original	Not mentioned	Minimum element: "SBOM Version"	Required if the format has one: "SBOM-URI"
8. Author signature	Shows the file came from the supplier unchanged	Recommended: signing is encouraged	Minimum element: "SBOM Author Signature"	Informative only: "ideally" signed
9. Top-level component matches what you received	The SBOM of the wrong release is worse than none	Minimum element: primary components	Minimum element: the target component	Required: the primary component, the root of the tree

Component-level checks

Check	Why it matters	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Component name	The first thing every match uses	Minimum element	Minimum element	Required; the filename if there is no name
11. Version: no latest, unknown or empty values	Advisories apply to version ranges	Minimum element	Minimum element; say so if unknown	Required; the file date if there is no version
12. Producer or supplier	Tells two components with the same name apart, and says who fixes it	Minimum element: "Supplier Name"	Minimum element: "Component Producer"	Required: "Component creator", email or URL
13. Package URL wherever the ecosystem has one, CPE where it does not; both well-formed	Without an identifier (package URL, CPE), nothing can be matched to a vulnerability database	Minimum element: "Other Unique Identifiers", such as CPE, SWID or PURL, if they exist	Minimum element: at least one identifier, such as CPE or PURL; include all	Required if it exists: CPE or purl
14. Hash value and algorithm, matching the file you received	Proves this SBOM describes this binary	Recommended	Minimum element: hash of the executable artifact, with an algorithm approved by an authority such as NIST	Required: SHA-512 of the deployable component
15. License as SPDX identifiers or expressions, no blanket NOASSERTION	Your license specialist judges copyleft and other obligations from it	Recommended	Minimum element; SPDX identifiers when possible	Required: distribution licenses, SPDX identifiers first
16. Dependency relationships, and whether the list is complete	Shows what pulled a vulnerable package in, and whether to trust the gaps	Minimum element; say when direct dependencies are fully listed	Minimum element	Required, with the completeness of each list stated
17. Filename	Ties the entry to a file on the device	Not mentioned	Not mentioned	Required
18. Executable, archive and structured properties	Says what kind of file each component is	Not mentioned	Not mentioned	Required

Coverage checks

Check	Why it matters	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Transitive depth, not just the top level	Most vulnerable code arrives indirectly	Top level required; transitive recommended	Coverage practice: include transitive dependencies; no minimum depth	Required: recursive resolution
20. Known unknowns stated	An SBOM that states its gaps can be trusted for what it lists	Required practice	Practice: unknown and withheld information marked	Required through the completeness statement
21. One SBOM per delivered software version	The version you run is the one that matters	Required: a new SBOM for each build or release	Practice: frequency	Required
22. Corrections sent as a new SBOM	An error fixed silently cannot be traced	Practice: accommodation of mistakes	Practice: accommodation of updates	Required: an updated SBOM when errors are corrected
23. Plausibility: no duplicates, a component count that fits the product, operating system packages present for a Linux-based device	The cheapest probe of completeness	Not mentioned	Coverage practice: multiple instances listed separately	Multiple instances must be listed separately

How to test each check, and what to tell the supplier

Check	How to test it automatically	Feedback line for the supplier
1, 2. Schema and spec version	A schema validator for the declared format and version; then compare specVersion (CycloneDX) or the SPDX version with your floor	"The file fails schema validation for CycloneDX 1.6 at the paths listed. Please regenerate it with a generator, and validate it before sending."
3 to 7. Author, timestamp, tool, context, version	Required metadata present: in CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber and version; in SPDX the creation information	"The SBOM does not state the tool that produced it or the generation context. Both are CISA 2026 Minimum Elements."
8. Signature	A signature is present and verifies against the key the supplier published	"Please sign the SBOM, or send a detached signature, as the CISA 2026 element SBOM Author Signature describes."
9. Top-level component	The name and version of metadata.component (CycloneDX) or the described root element (SPDX) match the part number and software version you received	"This SBOM describes version 5.2.0; we received 5.3.0. Please send the SBOM for 5.3.0."
10, 11. Name and version	No empty names; no empty, latest or unknown versions unless declared unknown	"14 components have no version. Please give the exact version, or mark it as unknown."
12. Producer	A supplier, manufacturer or author on each component	"Components have no producer, which the CISA 2026 element Component Producer asks for."
13. Identifiers	Every purl parses with a package URL library under ECMA-427; every CPE is valid CPE 2.3 syntax and exists in the NVD CPE dictionary	"No component has a package URL or CPE, so none can be matched against vulnerability databases. Please add a purl for every package from a package manager."
14. Hashes	A SHA-512 entry on each deployable component; compute sha512sum of the file you received and compare	"The SBOM has no hashes. BSI TR-03183-2 asks for the SHA-512 of each deployable component."
15. Licenses	License IDs or expressions that resolve against the SPDX license list; count NOASSERTION and empty values	"92% of components carry NOASSERTION as license. Please give SPDX license identifiers."
16. Dependencies	A dependencies graph (CycloneDX) or dependency relationships (SPDX); a completeness statement, such as CycloneDX compositions with an aggregate value	"The SBOM is a flat list. Please include dependency relationships and state whether each list is complete."
17, 18. Filename and file properties	The properties BSI TR-03183-2 defines for each format are present	"Please add the filename and the executable, archive and structured properties, as BSI TR-03183-2 v2.1.0 requires."
19 to 23. Coverage	Depth of the dependency graph, duplicate detection, a component count compared with similar products, expected components by product type	"The SBOM lists no kernel, bootloader or base system packages for a Linux-based display. Please send the SBOM of the full image."

The percentages and counts in the feedback lines are examples. Put the real numbers in, and name the framework and version every time.

What a passing score still misses

A file can validate, score 9 out of 10 and still miss half the product. Quality scores read the fields that are there; they cannot see the components that are not.

Worked example. A supplier sends the SBOM of a Linux-based display. It is valid CycloneDX 1.6, every component has a version, a package URL, a license and a SHA-512 hash, and the dependency graph is well formed. It lists the display application and 40 libraries. It does not list the Linux kernel, the bootloader or any base system package. Every field check passes. The SBOM is useless for kernel CVEs, which a Linux device has to be monitored for, because the kernel is not in it.

How a receiving team can probe completeness:

• Compare against a binary analysis of the delivered firmware. Some OEMs use it as a stand-in SBOM until the supplier's SBOM is good enough, and as a cross-check after.
• Check for expected components by product type. A Linux image has a kernel, a C library and an init system; an industrial controller has its protocol stacks.
• Ask for the generation context and the tool. A source scan cannot see what the build fetched.
• Ask whether the SBOM came from the build that produced the software you received. That is the question that decides the third layer.

Small SBOMs can be legitimate. A bare-metal ECU with proprietary firmware and a vendor calibration may honestly have two components. Accept that when the SBOM says so and states its known unknowns, rather than penalizing it for its size.

Tools that automate the checks

Checked on GitHub on 11 November 2026. None of these repositories is archived.

Tool	What it checks	What it does not	Status
CycloneDX CLI	Schema validation of CycloneDX 1.0 to 1.7, JSON or XML; --fail-on-errors for CI	SPDX, field quality, framework profiles	v0.33.1, July 2026
sbom-utility	Schema validation of CycloneDX 1.2 to 1.7 and SPDX 2.1 to 2.3 JSON, with custom schema variants	SPDX 3, XML, framework profiles	v0.19.2, June 2026
SPDX tools-java	Verify for SPDX 2.0 to 2.3 and 3.0.1	CycloneDX, framework profiles	v2.0.7, June 2026
SPDX tools-python	pyspdxtools -i: full validation of SPDX 2.2 and 2.3	Reading SPDX 3, whose support is experimental	v0.8.5, March 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 and 3.0 against NTIA 2021, CISA FSCT3 and BSI TR-03183-2 v2.1.0; also a web version	CycloneDX; CISA 2026 is an open request	v6.0.0, October 2026
sbomqs	A 0 to 10 score across identification, provenance, integrity, completeness, licensing, vulnerability and structure; compliance profiles for CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 to v2.1.0, FSCT v3 and OpenChain Telco	See missing components	v2.1.3, October 2026; CISA 2026 profile since v2.1.0, fixed in v2.1.2
sbom-scorecard	A weighted score of spec compliance, generation information, and package identifiers, versions and licenses	Framework profiles	0.0.7, April 2023, the last release

Only sbomqs checks the CISA 2026 Minimum Elements so far. Check each tool's release notes before you rely on a profile: in sbomqs 2.1.1, the CISA 2026 flag ran the 2021 check by mistake. For BSI TR-03183-2 v2.1.0 in sbomqs, use --bsi-v21 or --bsi; --bsi-v2 checks v2.0.0.

A minimal intake step for a supplier's CycloneDX SBOM:

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

For SPDX, use sbomcheck -s spdx3 -c bsi supplier-sbom.json from the NTIA Conformance Checker. Read the compliance report and reject the file on the checks your requirement makes mandatory; return it to the supplier with the feedback lines above.

Writing it into supplier requirements

A checklist the supplier never saw is not a requirement. Put it in the contract annex:

• The framework and version: for example "BSI TR-03183-2 v2.1.0" or "CISA 2026 Minimum Elements". Name one; do not write "industry standard".
• The format and minimum spec version: for example CycloneDX 1.6 or later, or SPDX 3.0.1 or later, JSON.
• The fields you add on top, such as SHA-512 hashes or package URLs for every package.
• Delivery: one SBOM per delivered software version, before or with the software.
• The validation the supplier runs before sending, named by tool and profile.
• The feedback loop: who receives the feedback, and how fast a corrected SBOM is due.

The supplier's side of the same agreement is in the SBOM guide for suppliers. For a software vendor answering a one-off request, see customer SBOM requests.

Fixing a failed SBOM (for suppliers)

• Hand-written files. Use a generator or an SBOM library, never a text editor.
• Missing package URLs. Generate them from the package manager or the build, not by hand. A typed purl is a guessed purl.
• Missing licenses. Take the declared license from the package metadata, as an SPDX identifier.
• No hashes. Compute them over the files you actually deliver, at the end of the build.
• The wrong release. Generate the SBOM in the release build, and name it after the version.
• Top level only. Use a method that resolves transitive dependencies.

The most reliable way to fix completeness and identifiers together is to generate the SBOM from the build that produced the delivered software. See build-time SBOMs and SBOM best practices.

Where good SBOMs come from, and how CRACI fits

For suppliers who build on GitHub Actions, CRACI replaces the GitHub-hosted runners and records the SBOM during the build, so it lists what the build actually pulled in.

• Every package with a package URL, and every component with its declared license.
• Transitive dependencies, at every depth the build reached.
• A completeness state for every job, which answers the known unknowns question per build: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.
• Exported as CycloneDX or SPDX; the SBOM API returns CycloneDX 1.7 JSON.

For a whole engineering organization, see standardizing SBOM generation, and for embedded Linux, why scanners miss what is in Yocto builds.

For OEMs, third-party SBOMs can be added to CRACI, so components you buy in are monitored for new vulnerabilities alongside your own builds. See SBOM management tools for how that compares.

When CRACI is not the answer

• Validating and scoring the SBOMs you receive. CRACI does not offer an SBOM validator or quality score. Use the tools above.
• Suppliers without CI, or whose code is generated by model-based tools with no package fetching. A build recorder adds little; a validated SBOM from a generator library is the realistic answer.
• Firmware you only receive as a binary. Binary analysis answers that.
• Signed SBOMs, the CISA 2026 author signature. CRACI does not sign SBOMs.

SBOM quality and validation: frequently asked questions

How do I check the quality of an SBOM a supplier sent me?

Test three layers. Validate the file against its schema, check the fields against a named framework such as BSI TR-03183-2 or the CISA 2026 Minimum Elements, then probe completeness: compare it with a binary analysis of what you received and check for the components the product type must contain.

What fields must an SBOM contain?

It depends on the framework you name. CISA's 2026 Minimum Elements list 17 fields, including author, timestamp, tool, generation context, and per component the name, version, producer, identifiers, hash and license. BSI TR-03183-2 adds a SHA-512 hash, the filename and file properties, and requires them.

What changed between the NTIA minimum elements and CISA's 2026 Minimum Elements?

CISA's 2026 list replaces NTIA's seven fields with 17. New are the author signature, data format name and version, generation context, tool name and version, SBOM version, component hash value and algorithm, and component license. Supplier name became Component Producer, and depth became coverage.

What does BSI TR-03183-2 require in an SBOM?

Version 2.1.0 requires CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML, one SBOM per software version, recursive dependencies with their completeness stated, and per component the creator, name, version, filename, licenses, SHA-512 hash and file properties, with a package URL or CPE if one exists.

Does an SBOM need hashes? Which algorithm?

NTIA recommended them; CISA 2026 makes the hash a minimum element with an algorithm approved by an authority such as NIST; BSI TR-03183-2 requires SHA-512 of each deployable component. Ask for SHA-512 and compare it with the file you received.

Do I need both a CPE and a PURL?

Not always. Ask for a package URL wherever the ecosystem has one, and a CPE where it does not, as for many commercial or embedded components. CISA 2026 asks for at least one identifier and all that are known; BSI requires each if it exists.

How do I validate a CycloneDX or SPDX file?

For CycloneDX, cyclonedx-cli validate with --fail-on-errors, or sbom-utility. For SPDX, the Verify command of SPDX tools-java, or pyspdxtools for SPDX 2.2 and 2.3. Then run a framework profile with sbomqs or the SPDX NTIA Conformance Checker.

What is a good SBOM quality score?

There is no standard threshold, and no benchmark we would quote. A score measures the fields present, not completeness: a file can score 9 out of 10 and miss half the product. Set pass criteria per check in your supplier requirement instead, and track the score as a trend.