SBOM readiness checklist

More SBOMs are produced than ever, and more are rejected than ever - by auditors, procurement reviewers, and regulators’ technical staff. The rejection reasons are consistent, and they all come down to treating the SBOM as a compliance document rather than an engineering artifact. This checklist covers the properties that make an SBOM trustworthy enough to hand over.

Score your current SBOM practice against it before a customer or regulator does.

Generation

• Is the SBOM generated from the real build - the actual dependency resolution that produced the artifact - rather than assembled by hand?
• Is generation automated as a build or pipeline step, so every release produces one without manual effort?
• Does the SBOM match the artifact it describes? Spot-check the SBOM against the shipped build; one mismatch discredits the whole document.

Completeness

• Does the SBOM include the complete transitive dependency graph, not just top-level dependencies?
• Are dependency relationships recorded, so you can tell how a component got in and what to change to remove it - not just a flat list?
• Are components inside binaries, archives, and container images resolved, not only those in clean manifests?
• Is vendored code - source copied directly into the repository - inventoried, with its own identity?

Honesty

• Are components the tooling could not fully resolve declared as known-unknowns, rather than silently omitted?
• Does the SBOM carry a standards-correct indication of whether the inventory is complete or partial?

Format and validation

• Is the SBOM emitted in a standard format - CycloneDX or SPDX - and does it pass schema validation?
• Does it meet the field-level requirements of the strictest specification you sell into, so the vaguer mandates are covered by construction?
• Can you produce whichever format a given consumer asks for, from the same underlying inventory?

Provenance and identity

• Does each component carry unique identifiers and, where it matters, hashes?
• Does the SBOM record its own provenance - which tool and version produced it, from what inputs, and when?
• Are findings and components identified so that the same entry keeps its identity across re-scans?

Lifecycle

• Are SBOMs stored per release, rather than produced once and discarded?
• When a new vulnerability is disclosed, can you answer which shipped builds contain the affected component - in minutes, from stored inventories, without re-scanning?
• Are the SBOMs your suppliers give you ingested and monitored, not filed and forgotten?

The one that matters most

Every mandate is drifting from “produce a document” toward “operate a capability” - the SBOM as the living substrate for vulnerability management across shipped versions. If your program clears the lifecycle section, the rest tends to follow.

The rejection reasons in detail are in why auditors reject your SBOM, the format decision is covered in CycloneDX vs SPDX, and if you want to see complete, build-generated SBOMs produced offline, request a demo.