Check whether an SBOM covers the released software
Compare an SBOM with packaged components and a defined acceptance profile. Track missing identities, versions, suppliers, relationships, and coverage gaps.
An SBOM can pass schema validation and still omit a library that ships in the product. Review syntax and coverage as separate checks. First identify the artifact digest and the inventory boundary. A document for the source repository cannot automatically stand in for a packaged release.
Define a local acceptance profile
Write down the fields your consumers need for advisory matching and release investigation. Distinguish local requirements from requirements of the selected format. For example, SPDX 2.3.1 makes package version optional in its package information section, even though an unresolved version can prevent a useful vulnerability match.
The August 2025 CISA minimum-elements PDF identifies itself as a public-comment draft, not a final government position. Do not label that draft a binding standard. This worksheet is a practical engineering check, not a compliance certification.
Review the document against independent evidence
Use package-manager output, archive contents, container package records, and build logs as comparison inputs. They have different blind spots; agreement between two views is useful, but not proof of exhaustive coverage.
| Check | Evidence to compare | Gap to record |
|---|---|---|
| Product identity | Released digest and platform | SBOM describes another artifact |
| Component identity | Package namespace and ecosystem | Name cannot be matched reliably |
| Version | Installed metadata or build revision | Version absent or ambiguous |
| Supplier | Verified distribution metadata | Supplier unknown, not guessed |
| Relationships | Resolved dependency graph | Missing parent or dangling reference |
| Coverage | Packaged files and embedded libraries | Unidentified binary or omitted layer |
Give each gap an owner, its likely operational effect, and the evidence needed to resolve it. Preserve unknown values rather than inventing supplier names or versions to make a validation report green.
Challenge the collection boundary
Choose samples that are easy for the generator to miss: a statically linked library, a vendored directory, an optional runtime module, or an architecture-specific package. Confirm that each sample is represented or explicitly excluded. Also check that development-only components are not presented as shipped components without explanation.
Reconcile duplicates carefully. Two versions of one package may genuinely coexist; collapsing them into one entry can hide the affected occurrence. After corrections, rerun schema and reference checks and retain the original comparison results. Approve the inventory only with a clear coverage statement and unresolved-gap list. That gives the next reviewer something more useful than a component count.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.