Transitive Dependencies not showing in Dependency-Graph

[almitte]

Current Behavior:

Transitive dependencies where the child node (second hierarchy level) is inside the "components" of the parent node (first hierarchy level) are not being displayed in Dependency-Graph. Error was noticed after using hierarchical Merge with CycloneDX-Cli, as only the first hierarchy level (the primary-components of the merged SBoMs) are showing in Dependency-Graph in Dtrack, but no second hierarchy level components.
Not working Code:

Result:

Working Code:

Result:

Dependencies:

Steps to Reproduce:

Add a child node to "components" of a first hierarchy level parent node and add this child node to "Dependencies" as well.
Also merge two valid SBoMs using the CycloneDX-Cli with the --hierarchical Setting. (Resulting SBoMs Dependency-Graph in Dtrack only displays first hierarchy level components.)

Expected Behavior:

Dependency-Graph should display transitive dependencies.

Environment:

• Dependency-Track Version: latest
• Distribution: Docker
• BOM Format & Version: JSON, 1.4
• Database Server: SQL-Server

Additional Details:

(e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

[stevespringett]

This is a frontend issue.

Duplicate of DependencyTrack/frontend#85

[roadSurfer]

I am a bit confused about if this should this be fixed or not. It's marked as duplicate, DependencyTrack/frontend#85 is closed, but I am hitting the issue in 4.7.0 after running a hierarchical merge.

[roadSurfer]

To illustrate what I am seeing, I created two simple BOMs for foo and bar, and uploaded those to DT. Both of these displayed fine:

I then ran a hierarchical merge to create a BOM for foobar: docker run --rm -v <bom_location>:/tmp/target --name cyclonedx cyclonedx/cyclonedx-cli:0.24.2 merge --input-files /tmp/target/bom_foo.xml /tmp/target/bom_bar.xml --input-format xml --output-file /tmp/target/bom_foobar.xml --output-format xml --hierarchical --group tld.domain --name foobar --version 0.0.1-SNAPSHOT
Uploading that to DT shows the problem (although the BOM itself seems fine):

Note how there is no expansion of the foo and bar dependencies when expected.

boms.zip

Edit: Swicthing to JSON does not seem to help.

Edit 2: Navigating to a component (e.g. commons-lang3) and then clicking on the "Show in dependency graph" icon under the name does not work either.

[roadSurfer]

Looking in the DB (postgres in this case), I can see that direct_dependencies is empty for foo. This to me implies that the fault lies somewhere withing the ingestion of the BOM.

[stevespringett]

@almitte Closing this issue as the navigation down to transitive dependencies was resolved in v4.7.

@roadSurfer the issue you're experiencing is due to both of your direct dependencies not having any dependences of their own.

Neither of these dependencies have any dependencies defined in the BOM

tld.domain.foo@0.0.1-SNAPSHOT:pkg:maven/tld.domain/foo@0.0.1-SNAPSHOT?type=jar
tld.domain.bar@0.0.1-SNAPSHOT:pkg:maven/tld.domain/bar@0.0.1-SNAPSHOT?type=jar

[roadSurfer]

@stevespringett - perhaps this is the wrong place, but I can see the dependencies defined on lines 5917 and 6199 of bom_foobar.xml from the Zip file.
(Note: There was a typo in the original zip where the PURL had jarr instead of jar, but fixing that did not alter behaviour.)

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.