Keep the dependency graph. A flat list answers "is this component present?", but the graph answers "which of our packages pulled it in and what is the shortest fix?". Both main SBOM formats can carry relationships, so a tool that drops them is throwing away the part you need during an incident.
What the formats can say
CycloneDX has a dependencies section for documenting dependency relationships. The specification says each entry defines the direct dependencies of a component or service, and that components with no dependencies of their own must still be declared as empty elements in the graph. That last rule matters, because it lets a reader tell "no dependencies" from "not recorded".
SPDX expresses the same idea through relationships between elements. Its relationship types include DEPENDS_ON, used when one package depends on the presence of another in order to build and run, and DEPENDENCY_OF for the reverse direction. The SPDX examples also show a root package with no dependencies expressed by relating it to NONE, and an unknown set expressed by NOASSERTION. Both are ways of being honest about what you do not know.
What a flat list cannot do
| Task | Flat list | With a graph |
|---|---|---|
| Confirm a vulnerable library is present | Yes | Yes |
| Find which direct dependency introduced it | No | Yes |
| Decide whether upgrading one package removes it | No | Yes |
| Tell direct from transitive | No | Yes |
| Spot a component that appears at several depths | No | Yes |
| Distinguish "no dependencies" from "unknown" | No | Yes, when the format's rules are followed |
During an advisory the practical question is rarely "is it there?". It is "who owns the package that brought it in, and what do we change?". That is a graph question.
How to test a tool
- Take a project where you know a transitive path, such as your app to a framework to a small utility.
- Generate an SBOM and open the relationships section.
- Confirm the path exists, with the right direction. A depends on B, not the other way round.
- Confirm leaf components are present with no dependencies, rather than missing.
- Confirm that a component used by two parents appears once, with two inbound edges, rather than as two unrelated entries.
- Round trip it: import the SBOM into a second tool and see whether the relationships survive.
Common failures
- Flat export. The tool builds a graph internally but writes only components.
- Wrong direction. Relationships reversed, which turns "depends on" into "is depended on by".
- Lost depth. Only direct dependencies are recorded, so transitive risk is invisible.
- Duplicate entries. The same package repeated at each depth with different identifiers.
Questions to ask a vendor
- Does the exported file contain the graph, and in which sections?
- Is the graph resolved from the build, or inferred from manifests?
- Does the tool show the path from your code to a vulnerable component in its interface?
Try it yourself
Click through it at your own pace, or open it full screen. Open a transitive component and look for the parent that introduced it.
Where Safeguard fits
Safeguard's dependency inventory shows direct and transitive components and uses reachability analysis to show whether vulnerable code is called. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a graph needed for compliance?
Requirements vary, so check the one that applies to you. For engineering, the graph is what makes remediation fast.
What does an empty dependency entry mean in CycloneDX?
That the component has no dependencies, as opposed to having none recorded.
Sources
Last reviewed: 19 October 2026.
