Add support for dependency graph visualization

When working with dependencies, it’s important to understand how they’re introduced. Since CycloneDX 1.2, dependency graphs are part of the core spec. For previous spec versions, there is a dependency graph extension.

The graph as included in CycloneDX BOMs is, while simple and minimalistic, hard to parse for humans. cyclonedx-cli should include a command that visualizes the graph in some sort of tree structure.

For example, executing for mvn dependency:tree for Alpine produces the following output:

us.springett:alpine:jar:1.8.0-SNAPSHOT
+- commons-io:commons-io:jar:2.6:compile
+- org.apache.commons:commons-lang3:jar:3.10:compile
+- org.apache.commons:commons-collections4:jar:4.4:compile
+- org.glassfish.jersey.core:jersey-client:jar:2.29.1:compile
|  +- jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:compile
|  +- org.glassfish.jersey.core:jersey-common:jar:2.29.1:compile
|  |  +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile
|  |  +- org.glassfish.hk2:osgi-resource-locator:jar:1.0.3:compile
|  |  \- com.sun.activation:jakarta.activation:jar:1.2.1:compile
|  \- org.glassfish.hk2.external:jakarta.inject:jar:2.6.1:compile
+- javax.servlet:javax.servlet-api:jar:4.0.1:provided
+- org.glassfish.jersey.containers:jersey-container-servlet:jar:2.29.1:compile
|  +- org.glassfish.jersey.containers:jersey-container-servlet-core:jar:2.29.1:compile
|  \- org.glassfish.jersey.core:jersey-server:jar:2.29.1:compile
|     +- org.glassfish.jersey.media:jersey-media-jaxb:jar:2.29.1:compile
|     \- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile
|        \- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile
...

The main focus should be on terminal output. For the future, it may also be helpful to transpile CDX’s dependency graph into the DOT language, which would allow generation of graph images with GraphViz.

[nscuro]

Good to see that you have automatability in mind from the very beginning. I think JSON is a great choice.

[msymons]

I understand that the CLI does not know what Maven is. Or npm, etc It only cares about the BOM. However, a BOM can still end up containing multiple versions of the same component. eg:

pkg:maven/org.apache.httpcomponents/httpclient@4.5.12?type=jar
pkg:maven/org.apache.httpcomponents/httpclient@4.5.13?type=jar

Dependency resolution in the build has meant that only one of these versions is actually valid (used). But both end up in the BOM. As it happens, one version has a vulnerability (CVE-2020-13956) and one (the newer) does not. Furthermore, tools such OSS Index are not yet reporting the vulnerability. This means that vulnerability alerting in (say) Dependency-Track would not help highlight that an older version of a component is still trying to sneak in.

Hence, all I am seeking is a means of quickly spotting (visualizing) when such dependency version clashes have occurred. Because spotting them is half the battle. Fixing such a clash is pretty easy once they are spotted.

I have BOMs with over 3000 lines (300 components) and manually checking for clashes is a pain.

I see this functionality as being useful for when someone is double checking output from an earlier stage in a DevSecOps pipeline and the someone (me, in this case) is not a developer or might not have access to build logs, etc.