You cannot prove an SBOM is complete from the file alone. You can find out whether it is probably thin. Check dependency depth, whether the author declared known unknowns, whether component counts look plausible, how many components have dependency entries, and whether an independent scan agrees.
What the standards say about completeness
The NTIA minimum elements report treats completeness as a practice, not a field. It lists depth as one of the practices around SBOMs and says some uses need complete or mostly complete graphs, such as proving a given component is not on your network.
It also introduces known unknowns. When the full dependency graph is not listed, the author must say so explicitly. The data should distinguish a component with no further dependencies from one where dependencies are unknown, and the default reading should be that the data is incomplete.
That default is worth adopting. Assume incomplete until the file shows otherwise.
Five checks
1. Depth. Pick a component you know has dependencies, such as a web framework. Does the SBOM list what it pulls in? If the framework appears with nothing beneath it, transitive data is missing.
2. Known unknowns. In CycloneDX, look for compositions entries that state whether the assembly is complete. The 1.6 reference recommends them for indicating unknown graphs. In SPDX, check whether the author wrote anything about files analyzed or left comments on packages.
3. Plausible counts. A modern web service with a few dozen direct dependencies typically has hundreds of transitive ones. An SBOM listing 12 components for a large application deserves a question. Do not trust round numbers as proof either way, since this varies by ecosystem.
4. Dependency coverage. Divide the number of dependency entries by the number of components. A ratio near 1 means most components have an entry. A ratio near 0 means the graph is thin. Remember that an entry may be an empty array, which is a statement, not a gap.
5. Cross scan. Scan the delivered artifact yourself and compare. This is the strongest check because it uses independent data.
What gaps usually mean
| Symptom | Likely cause |
|---|---|
| Only top level packages | Generator read a manifest, not a lock file |
| No OS packages in a container product | SBOM made from source, not the image |
| Many components, no versions | Version resolution failed or was skipped |
| No entries for vendored code | Copied source was not detected |
| Duplicate components with different versions | Several build targets merged |
None of these is fatal. Each tells you what to ask.
What to do when it is incomplete
Do not discard the file. Use it for what it supports and record what it does not. Write down the specific gap, for example "transitive dependencies not captured for the Java services," and send that to the supplier. Then set a follow up date. Treat the answer as part of your supplier record.
For risk decisions, a thin SBOM is a floor, not a ceiling. Anything found by your own scan counts, whether or not it appears in the supplier file.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the inventory changes between runs. That drift is why a single supplier SBOM is a snapshot, not a guarantee.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, which gives you an independent inventory to compare against. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a bigger SBOM always more complete?
No. A large file can still miss a layer, and a small one can be accurate for a small product. Compare against the product, not against other files.
What does known unknowns mean?
It means the author flags which parts of the dependency graph are not fully listed, so readers do not assume they have none.
Sources
Last reviewed: 19 October 2026.
