Indirect dependencies not added BOM file while generation BOM using Cyclonedx

[super3programmer]

I used cyclonedx-gomod to generate a BOM file, but some internal dependencies were not included. Although most indirect dependencies were added, the following two were not:

github.com/stretchr/objx v0.5.0 (indirect) google.golang.org/appengine v1.6.7 (indirect)

[nscuro]

Please ensure that you run go mod tidy to keep bloat out of your go.mod file.

Then, keep in mind that go.mod does not differentiate between dev/test, and runtime dependencies. cyclonedx-gomod mod will not include test dependencies per default, but you can opt-in to that by passing the -test flag.

If you're using cyclonedx-gomod app, the output will be even more restricted, because it will only include modules that are actually compiled into your application. Please consult the respective command's help text for details: https://github.com/CycloneDX/cyclonedx-gomod?tab=readme-ov-file#subcommands

It all comes down to the fact that cyclonedx-gomod does not simply parse your go.mod file. It instead relies on the Go itself to tell it what the true dependencies are.

[super3programmer]

Hello @nscuro, After running 'go mod tidy', I generated the BOM file using the cyclonedx-gomod app. However, the BOM file is missing two specific components. While I understand that cyclonedx-gomod relies on Go for this process and it includes all other indirect components, I am puzzled as to why these two components are excluded. Do you have any suggestions or insights on this issue?

[nscuro]

When you use app, the BOM will be generated based on what Go would compile into the application, given the currently applicable build constraints. Build constraints include the platform, but also build tags etc.

For example, some modules are only required on macOS, so when you run cyclonedx-gomod app on Windows, you won't see those.

Another reason could be that some modules are only needed by code that you application never calls, hence they'll be omitted.

Or your codebase has multiple binaries (e.g. cmd/app1, cmd/app2), so when you're generating a BOM for app1 you won't be seeing modules that only app2 depends on.

There's a multitude of reasons that all are results of how Go's module system and build process works. go.mod and go.sum do not reliably tell you what gets shipped when you build a binary.

If you always want all modules to be included, use cyclonedx-gomd mod. Please read the command's help text.