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.
• [ ] 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

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

Sources

• NTIA, The Minimum Elements for a Software Bill of Materials, July 2021.
• CycloneDX specification and the SPDX license list.