Value

Today, we parse go.mod files and catalog the packages listed therein. However, this is not a complete list of software dependencies had by a given project, it's just a list of modules required by the project's "main module".

If users are to understand a project's complete set of project dependencies, we should consider surfacing the "build list", which is an exhaustive set of dependencies that a Go project has (i.e., the entire dependency graph). This list can be viewed by running the command go list -m all from a Go project's root directory.

Implementation considerations

1. Go computes a set of required modules (i.e. generating the build list) using an approach called "MVS". It's important to note that one implication of this approach is that not all dependencies are identifiable using just a static analysis. Instead, the Go tooling issues multiple queries across a network (including to hosts like: GitHub (or other git providers), the checksum database, etc.) in order to discover indirect dependencies, and to select a single version of each Go module, even when multiple versions of a given Go module are cited throughout the dependency graph. Currently, Syft's analysis is entirely static. Should Syft start incorporating analysis that depends on these network queries? Always? Never? Sometimes (i.e. config value)?