Use it for lookup, not for tracing. A flat list tells you which components are present, so you can search it when an advisory appears. It does not tell you which component pulled in which, so you cannot map paths or confidently say something is absent. Ask the supplier for relationship data or for a statement of known gaps.
What the standard asks for
The NTIA minimum elements report lists dependency relationship as one of seven data fields. It describes the field as characterizing how an upstream component is included in software, and the depth practice says an SBOM should list all top-level components with enough detail to find transitive ones. The same report adds that some use cases need complete or mostly complete graphs, such as proving that a given component is not on a network.
It also introduces known unknowns. If the full graph is not enumerated, the author must say so, and the default reading should be that the data is incomplete. A flat list with no statement is therefore ambiguous: either the supplier has no nested dependencies, or the nesting was dropped.
What you can still do with a flat list
- Search by name and version. If an advisory names a library, you can find it.
- Match against vulnerability data. Versions and identifiers are enough for a first-pass scan.
- Count and compare. A large list suggests transitive components were included even without links.
- Diff between releases. Added and removed components still show up.
What you cannot do reliably
| Task | Flat list | With relationships |
|---|---|---|
| Find where a component is present | Yes | Yes |
| Tell which direct dependency brought it in | No | Yes |
| Plan an upgrade to remove it | Hard | Easier |
| Say a component is absent | No | Only if complete |
| Judge which findings are reachable from top-level code | No | Partly |
Step by step
- Check whether the file is truly flat or whether your tool dropped the links. Open the raw file and look for a dependencies section in CycloneDX or relationships in SPDX.
- Ask the supplier whether relationships exist in a fuller export, or whether the generator they use does not produce them.
- Ask for a known unknowns statement: which components have complete dependency data, which do not.
- Record the limitation next to the supplier entry. Something like "flat list, no graph, received on this date" is enough.
- Lower the confidence you place in negative searches. A search that finds nothing in a flat list is weaker evidence than one that finds nothing in a complete graph.
Handling a vulnerable transitive component
If a flaw affects a component that sits deep in the supplier's product, a flat list leaves you unable to say who pulled it in. Ask the supplier directly. They have the build and can answer faster than you can reverse-engineer it.
Try it yourself
Click through it at your own pace, or open it full screen. Compare what you can learn from the inventory view with what a dependency path would add.
Safeguard's SBOM and dependency scanning cover the same ground for software you build, and the free scan is at gold.safeguard.sh/scan.
Quick check
Is a flat SBOM invalid?
Not necessarily. It can still list components, but it falls short of the dependency relationship field and of depth practices in the NTIA report.
Can we say a component is absent if it is not in a flat list?
Only with caution. The NTIA report notes that proving a negative needs a complete or mostly complete graph.
Sources
Last reviewed: 19 October 2026.
