To read an SBOM in five minutes, skip the component list at first. Check the format, who authored it, when it was made, what it describes, and whether the dependency data claims to be complete. Those five checks tell you whether the list is worth reading at all.
Why order matters
An SBOM can run to thousands of lines. Most people open it, scroll, and get lost. A better habit is to treat the file like an incoming document: confirm what it is before you read what it says.
The US Commerce Department's minimum elements report names seven data fields every SBOM should carry: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. Two of those describe the document itself, the author and the timestamp, and the dependency relationships shape the whole graph. Start there.
The five checks
| Minute | Check | What you want to see |
|---|---|---|
| 1 | Format and version | SPDX or CycloneDX, with a spec version you can parse |
| 2 | Author | A named tool or organization, not blank |
| 3 | Timestamp | A date close to the release you are asking about |
| 4 | What it describes | The product and version you actually received |
| 5 | Completeness | Dependency relationships present, with gaps stated |
Minute 1, format. CycloneDX files declare a bomFormat and specVersion. SPDX files declare an spdxVersion. If neither appears, you may have a generic CSV or spreadsheet, which is fine to read but harder to automate.
Minute 2, author. The NTIA report says the author field records the source of the SBOM data. It could be the software's creator, an upstream supplier, or a third party analysis tool. It is not the author of the software. Knowing which one you have changes how much you trust it.
Minute 3, timestamp. The timestamp records when the data was assembled. If the SBOM is eight months older than the release it claims to cover, ask whether it was regenerated.
Minute 4, subject. Find the top level component. In CycloneDX it sits under metadata.component. In SPDX, look at the package the document DESCRIBES. Confirm name and version match what you were sent.
Minute 5, completeness. Look at the dependency section. The NTIA report says that when a full graph is not listed, the author should state the "known unknowns," and that the default reading should be that the data is incomplete. A component with no listed dependencies and no statement about it is not proof that it has none.
What to do with what you find
If all five checks pass, read the component list next. Sort by supplier and look for items you recognize as risky: end of life runtimes, old crypto libraries, packages you have already banned. If one or two checks fail, do not reject the file. Write down the gap and ask the sender. A missing author field or an old timestamp is a question, not an accusation.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice which fields identify each component. Those are the same fields you check in an SBOM you receive.
Where Safeguard fits
If you want to compare what a vendor sent with what your own scan sees, Safeguard offers SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Do I need special software to read an SBOM?
No. Both common formats are text files, usually JSON, so a text editor works. A command line tool like jq makes searching faster, but it is optional.
What if the SBOM has no timestamp?
Treat it as a gap. The timestamp is one of the seven minimum elements, so ask the supplier to regenerate the file with one.
Sources
- The Minimum Elements for an SBOM, US Department of Commerce / NTIA
- CycloneDX 1.6 JSON reference
- SPDX 2.3.1 relationships between elements
Last reviewed: 19 October 2026.
