A one page SBOM review worksheet has three parts: facts about the file, checks with a pass or follow up mark, and open questions for the supplier. Twelve short fields cover most reviews and take about fifteen minutes to fill in. File it next to the SBOM so the next reviewer can see what you checked.
Why a worksheet
Reviewing an SBOM from memory means every reviewer checks something different. A worksheet makes the review repeatable and creates a record you can show a customer, auditor, or colleague. It also helps when the same supplier sends a new version next quarter, because you can compare answers.
Keep it to one page. If a review needs more, attach notes.
Part 1: facts about the file
Record these before judging anything.
- Supplier and product. The name and version the SBOM claims to describe.
- Format and spec version. SPDX or CycloneDX, and the version string.
- Author of the data. The NTIA minimum elements report says this identifies the source of the SBOM data, which may be the software creator, an upstream supplier, or an analysis tool.
- Timestamp and identifiers. The creation time, plus any serial number or document version. CycloneDX 1.6 says each generated BOM should have a unique serial number and that the version should increase when a BOM is modified.
- Lifecycle stage. Source, build, post-build, or unknown.
Part 2: checks
Mark each one pass, follow up, or not applicable.
| # | Check | Mark |
|---|---|---|
| 6 | The described product and version match what was delivered | |
| 7 | Most components carry a PURL or other unique identifier | |
| 8 | Most components carry a version | |
| 9 | Dependency relationships are present beyond one level | |
| 10 | Gaps are declared, for example known unknowns or incomplete markers | |
| 11 | Supplier field is filled for third party components | |
| 12 | License fields are filled, or the gap is noted |
For the fifth check in part two, remember the NTIA guidance: the author should state when dependencies are fully enumerated, and the default reading should be that the data is incomplete.
Part 3: open questions
Write each question as a full sentence a supplier can answer in one line. Examples:
- Which lifecycle stage does this file reflect, and can you provide a post-build one?
- Can you add versions for the 14 components that lack them?
- Does this SBOM include transitive dependencies for the Java services?
Add a due date and an owner for each.
Filing and reuse
Store the worksheet with the file, named by supplier, product, version, and date. When the next SBOM arrives, copy the previous worksheet and update only what changed. Two reviews in a row with the same open questions tell you something about the supplier.
A few habits help:
- Keep the original file untouched and note any edits you made for analysis.
- Record the tool you used to read it, with its version.
- Record who reviewed it and when.
What the worksheet is not
It is not a risk rating. It tells you about the quality and scope of the data. Judging the risk of the components inside is a separate step, using vulnerability and license data and the context of how you use the product.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, plus compliance and evidence automation for records like this. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should a review take?
Around fifteen minutes for a first pass on a typical file. Large products with many gaps take longer, mostly because of the questions to send back.
Should the worksheet be shared with the supplier?
Share the open questions. Keep internal notes and marks as your own record unless your process says otherwise.
Sources
Last reviewed: 19 October 2026.
