# SBOM review checklist: what to check before you trust one

> Use this checklist for an SBOM you produce for a release, or one a supplier gives you. Replace [brackets] and delete this note.

- **Software and version:** [name, version or commit]
- **SBOM file and format:** [file name, CycloneDX or SPDX, spec version]
- **Reviewed by:** [name]
- **Date:** [YYYY-MM-DD]

## 1. The file itself

- [ ] It is machine-readable: CycloneDX, SPDX or SWID tags, not a spreadsheet or a PDF.
- [ ] It validates against its format's schema.
- [ ] It names the exact software version or commit it describes, and that matches what you ship or receive.
- [ ] It has a timestamp, and it was made for this build. A new build or release needs a new SBOM.
- [ ] It names its author: the tool or organisation that produced the data.

## 2. The minimum fields, for every component

The NTIA minimum elements (2021) list these data fields. Check a sample of components, then check that none are missing them entirely.

- [ ] Supplier name.
- [ ] Component name.
- [ ] Version of the component.
- [ ] Other unique identifiers, such as a package URL (purl) or CPE.
- [ ] Dependency relationship: which component includes which.

## 3. Depth and gaps

- [ ] Every top-level component is listed, with its transitive dependencies.
- [ ] Where the dependency tree is incomplete, the SBOM says so. The NTIA calls these known unknowns: a gap that is stated is better than one that looks like nothing.
- [ ] Bundled, vendored or copied code is listed, not only what a package manager installed.
- [ ] Container base images and system packages are covered, if you ship a container.

## 4. Licenses

- [ ] Every component has a license, using [SPDX license identifiers](https://spdx.org/licenses/).
- [ ] Components with no license, or "NOASSERTION", are listed and followed up.
- [ ] No component is under a license on the [disallowed license list, e.g. AGPL-3.0 for distributed software].
- [ ] Dual-licensed components record which license you use them under.

## 5. Vulnerabilities

- [ ] The components are checked against a vulnerability database, with the date of the check.
- [ ] No known vulnerability of [high] severity or above, or each has a written exception with an owner and an end date.
- [ ] Where a vulnerable component isn't reachable in your use, that is written down, for example as a VEX statement, not just assumed.

## 6. What changed

- [ ] Compared with the previous SBOM for this software: components added, removed and changed are listed.
- [ ] Every added component has a reason, such as the pull request that added it.
- [ ] No license changed for an existing component without someone noticing.
- [ ] No version went backwards.
- [ ] New packages with names close to popular ones were checked for typosquatting. This matters more when a coding agent suggested the package.

## 7. Distribution and access

- [ ] The SBOM is stored with the release, where the people who need it can find it.
- [ ] Who may see it is decided. An SBOM tells an attacker what you run, too.
- [ ] There is a way to correct it. Mistakes in SBOMs happen, and the NTIA practices expect them to be fixed.

## Result

| Outcome                                 | Tick |
| --------------------------------------- | ---- |
| Accepted                                | [ ]  |
| Accepted with exceptions (listed below) | [ ]  |
| Rejected: [reason]                      | [ ]  |

Exceptions: [component, reason, owner, end date]

## Sources

- NTIA, [The Minimum Elements for a Software Bill of Materials](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom), July 2021.
- [CycloneDX specification](https://cyclonedx.org/specification/overview/) and the [SPDX license list](https://spdx.org/licenses/).

---

From https://aicodeops.dev/templates/sbom-review-checklist · Last updated 2026-10-24 · Licensed CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)