A real SBOM covers every build the supplier ships, lists direct and transitive components with versions and identifiers, names its author and timestamp, and matches your own spot checks. A for-show SBOM is a one-time export with gaps, missing relationships and no refresh. Test it against the lockfile, the container image and the release date.
What a usable SBOM contains
The US Commerce Department's NTIA report on minimum elements sets a baseline of seven data fields: supplier name, component name, component version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. If a file you receive lacks several of these, it cannot be mapped to vulnerability or license data, and it is not much use to you.
The same report also asks for practices, not only fields. It lists frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes. In plain terms: how often is it regenerated, how deep does it go, what does the supplier admit it cannot see, and how do you get corrections.
Five checks you can run in an afternoon
- Count the components. Ask your own engineers for the lockfile or image of a product you already know. A service with hundreds of installed packages and an SBOM of thirty entries is listing only top-level dependencies.
- Look for relationships. If every component sits in a flat list with no parent, you cannot tell which transitive package came from which direct one.
- Check the timestamp against the release. An SBOM dated months before the version it describes was probably not generated from that build.
- Pick three components and verify them. Find them in the shipped artifact. Mismatched versions are a sign the SBOM came from a manifest, not from the build output.
- Ask for the known unknowns. A mature supplier will say what the SBOM misses, such as vendored C libraries, bundled binaries or a base image layer. A supplier who claims it misses nothing deserves a second look.
Manifest SBOM versus build SBOM
| Source | Strength | Weak spot |
|---|---|---|
| Manifest or lockfile | Fast, easy to automate | Misses vendored code and OS packages |
| Built image or artifact | Shows what actually ships | Needs a scan per build |
| Hand written list | Cheap | Out of date almost at once |
Neither source is wrong. The question is whether the supplier can tell you which one produced the file in your hands.
Try it yourself
Open the demo and look at how a dependency inventory shows direct and transitive packages together. Notice how much larger the transitive layer is than the list a developer would write by hand.
Click through it at your own pace, or open it full screen.
What to do with the answer
If the SBOM fails two or more checks, do not argue about the file. Ask for a regenerated one tied to a named release, and agree the refresh frequency in writing. Treat that as a contract item, because the NTIA report says these arrangements should be specified in any policy, contract or arrangement that asks for SBOMs. This is not legal advice, so have counsel word it.
Safeguard generates SBOMs and runs dependency scanning with reachability analysis, and you can run a free scan on your own project to see what a build based inventory looks like.
Quick check
Is a CycloneDX file better than an SPDX file?
Neither is a quality guarantee. Both can carry the seven baseline fields. Judge the content and freshness, not the format.
Should I ask for an SBOM for every release?
The NTIA report says a new SBOM should be created when a component is updated with a new build or release. Ask what the supplier can sustain, and write the frequency down.
Sources
Last reviewed: 19 October 2026.
