Reviewers usually check an SBOM in this order: is it machine readable, who made it and when, does it cover transitive dependencies, are components identified uniquely, and are unknowns labeled. Fix those five points before sending and most follow up questions disappear.
The five fast checks
A reviewer opening your file is not reading component by component. They are scanning for signs the file is trustworthy and useful.
1. Is it in a standard format?
The 2026 CISA minimum elements guidance names SPDX and CycloneDX as the two data formats currently widely used, and says organizations should accept any widely used, interoperable, machine-processable format (see Sources). A PDF or spreadsheet is a different thing. If you send one, say what it is.
2. Who made it, and when?
Look for the SBOM author, a timestamp, and the tool name and version. These fields tell the reviewer how fresh the data is and what produced it. Missing metadata makes the file harder to trust.
3. How deep does it go?
The same guidance says an SBOM should include all components, including transitive dependencies, with no minimum depth. A list of only your top level dependencies is the most common reason a reviewer pushes back.
4. Can components be matched to advisories?
Components need identifiers that work as look up keys. Without identifiers a reviewer cannot map a new advisory to your file. This is the practical value of the identifier field.
5. Is unknown data labeled?
The guidance asks authors to state whether missing information is unknown or withheld. A blank is ambiguous. An explicit "unknown" is honest.
A pre send table
| Check | Question to ask yourself | Quick fix |
|---|---|---|
| Format | Is it SPDX or CycloneDX, and a current version? | Re-export from your tool |
| Metadata | Are author, timestamp, tool and version present? | Set them in the generator config |
| Depth | Are transitive packages listed? | Generate from lockfiles or the built artifact |
| Identifiers | Does each component have a package URL or similar? | Enable identifier output |
| Unknowns | Are blanks labeled? | Add a note to the cover message |
What reviewers do next
After the skim, many reviewers run the file through their own tooling and compare against current advisories. Expect questions about specific components. Prepare for them by knowing which of your findings are actually reachable in your code, and by keeping a short note on any that are not.
What not to do
Do not send a file you have not opened. Do not remove components to make the list look shorter. Do not bury caveats; put them in the cover message. The guidance notes that organizations may consider an SBOM incomplete if the author withholds essential component data.
A cover message that helps
Three short lines work well: what the file covers, when it was generated and by which tool, and what is known to be missing. Then a contact for questions.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, along with reachability analysis, can help you see which findings the reviewer is likely to raise and whether they are reachable. You can try it with the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list of findings shrinks when reachability is applied, which is the conversation a reviewer will want to have.
Quick check
Is a spreadsheet of dependencies an SBOM?
Not in the sense buyers mean. They usually want SPDX or CycloneDX so tools can process it. A spreadsheet can supplement but not replace it.
Should I remove internal package names before sending?
You can, but label the redaction. The guidance asks for withheld data to be identified as withheld, and for a way to ask about it.
Sources
Last reviewed: 19 October 2026.
