Add support for dependency graph

[nscuro]

CycloneDX supports dependency graphs.

Coincidentally, Go's go mod graph command provides a module graph in pretty much the same structure:

$ go mod graph
github.com/CycloneDX/cyclonedx-gomod github.com/CycloneDX/[email protected]
github.com/CycloneDX/cyclonedx-gomod github.com/google/[email protected]
github.com/CycloneDX/cyclonedx-gomod golang.org/x/[email protected]
github.com/CycloneDX/[email protected] github.com/bradleyjkemp/cupaloy/[email protected]
github.com/CycloneDX/[email protected] github.com/stretchr/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
github.com/bradleyjkemp/cupaloy/[email protected] github.com/davecgh/[email protected]
github.com/bradleyjkemp/cupaloy/[email protected] github.com/pmezard/[email protected]
github.com/bradleyjkemp/cupaloy/[email protected] github.com/stretchr/[email protected]
github.com/bradleyjkemp/cupaloy/[email protected] github.com/stretchr/[email protected]
github.com/stretchr/[email protected] github.com/davecgh/[email protected]
github.com/stretchr/[email protected] github.com/pmezard/[email protected]
github.com/stretchr/[email protected] github.com/stretchr/[email protected]
github.com/stretchr/[email protected] gopkg.in/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
github.com/stretchr/[email protected] github.com/davecgh/[email protected]
github.com/stretchr/[email protected] github.com/pmezard/[email protected]
github.com/stretchr/[email protected] github.com/stretchr/[email protected]
github.com/stretchr/[email protected] gopkg.in/[email protected]
gopkg.in/[email protected] gopkg.in/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]

An MVP implementation could simply take this output, convert <path>@<version> expressions to package URLs and be done with it.

Will have to figure out how to deal with replacements though. We currently treat replaced modules as ancestors in the replacement component's pedigree. However, the module graph will still reference the replaced module, not the replacement.

[nscuro]

Basic dependency graph support is done, as can be seen in this example BOM. Won't close this issue unless I have a good solution for replacements though.

[nscuro]

The graph provided by go mod graph contains multiple versions of the same module (e.g. golang.org/x/net in the output above). We need to rewire the graph so that it lines up with the module list returned by go list -json -m all. Roughly speaking, Go will use the latest version of a module if multiple versions are in the graph.

[nscuro]

As per golang/go#40513, dependencies of replacements are evaluated, but attributed to the replaced module in the module graph. Addressed this by rewiring the all references to the replacement instead.

[nscuro]

Delivered with v0.2.0 ✔