Explore using cyclonedx gomod as a library

[sambhav]

What would you like to be added:
CycloneDX gomod exposes a fairly comprehensive way of generating accurate sboms for go based projects in 3 modes, app, mod and bin.

Explore if this is something that can be utilized by syft to improve its output or not.

The app mode in particular might be useful during build time sbom generation.

Why is this needed: More accurate go sboms

Additional context:

This functionality is still pending release at CycloneDX/cyclonedx-gomod#114

cc: @nscuro for his amazing work on this.

[nscuro]

Thanks @samj1912! Happy to answer any questions regarding cdx-gomod, or discuss improvements that may be necessary for it to be a viable option for Syft 🙂

[coderpatros]

I think this is a great idea. @nscuro had to do a lot of work digging into the technical details of how go projects can be built to be able to accurately generate a BOM. Makes sense to me to leverage the work that's already been done.

[wagoodman]

Hey! I'm highly interested in options here for integration between these two projects 👍

I want to start by framing some of philosophies that Syft has today (and where they may be going in the future). Today Syft trys to be a self-contained static analyzer in a few different ways:

• there is no shelling out to execute other code or utilities
• we don't pull down state or resources via the network (the only exception to this today is checking for the latest available version of syft)
• we try to limit our dependence on disk state where possible
• syft is distributed as a static binary with no dependence on shared libraries or CGO functionality

That being said there are some facets that I think will change in the future, and most of the conversation on "how" has not happened yet. We want to elevate syft's functionality to be able to use external state to enrich or validate what is found statically. For instance, reaching out to maven.org to pull package dependency information to get a point-in-time transitive dependency list for a java package.

This would necessarily mean lifting or changing some of the restrictions we have in place today (such as accessing a network to get package state and leveraging state on disk more often). My instinct, if we were to go this direction, is to make such changes opt-in: users of syft would continue to use it as a static analyzer but can enable other more "dynamic" functionalities via configuration or CLI flags.

This context relates to cyclonedx-gomod in a couple of ways:

• there is a dependency on shelling out to go to get the necessary information
• much of the results depend on searching a gomod cache directory, which implies two things: a) heavy reliance of on disk state, and b) requiring the network to build this state

I took a small look to see what it would take to get the go mod * functionality without shelling out... it looks like it would mean copying out a large portion of go's internal source code, which is not ideal (but a possible path). This, coupled with the fact that the network would be needed to build the go mod cache, leads me to conclude that an integration with cyclonedx-gomod would be a good first candidate for exploring "opt-in + dynamic" capabilities in syft.

Happy to chat further on this @samj1912 @nscuro @coderpatros 👍

[nscuro]

Totally agree that Syft's core should stay true to the philosophies listed. Having tools with minimal runtime dependencies is super useful (and even required in some environments).

I'd be happy to assist in figuring out how external tools can be integrated with Syft, with cdx-gomod being a potential guinea pig for experiments. 😄

[luhring]

I think we should revisit this... Now that people are using Syft in more parts of the SDLC, it'd be really useful to have the additional support for more use cases in the Go ecosystem.

[kzantow]

This is a good idea and we had a look at this library, however we are leaning towards implementing the ability to shell-out to individual tools appropriate to an ecosystem, such as go and mvn. I'm going to close this issue in favor of: #1562 but please reopen if you feel this is a superior solution!