Often yes. A Go binary built in module mode carries information about how it was built, including the Go toolchain version and the set of modules used. Tools can read it from the file with the standard debug/buildinfo package. That makes an SBOM possible even when the image has no go.mod file.
What is embedded
The Go standard library documents the debug/buildinfo package as providing access to information embedded in a Go binary about how it was built. This includes the Go toolchain version and the set of modules used for binaries built in module mode. For the currently running program, the same data is available through runtime/debug.ReadBuildInfo.
You can see it yourself with the go version command and its module flag, pointed at a binary file. The output lists the module path, the main module and its dependencies with versions.
Why this matters in a container
A typical Go image built from scratch or from a static base has no package manager database and no source tree. A scanner that only reads operating system packages sees nothing. A scanner that reads build info from the binary can list the modules inside, and can also report the Go version, which matters because the standard library is part of every binary and ships fixes in toolchain releases.
That second point is easy to miss. A new Go release that patches the standard library does nothing for an existing binary. You must rebuild. Our post on a Go security release and rebuilding binaries walks through a recent case.
Things that change what is recorded
| Build choice | Effect |
|---|---|
| Module mode (normal today) | Module list and versions embedded |
| The trimpath flag | Removes file system paths from the executable, recorded paths start with module path and version |
| Version control stamping | Controlled by the buildvcs flag, which can include or omit VCS information |
The Go command documentation describes the trimpath flag as removing all file system paths from the resulting executable, so recorded file names begin with a module path and version rather than an absolute path on your build machine. It also describes the buildvcs flag, which you can set to false to always omit version control information. Both are worth using for cleaner, less revealing output.
A practical checklist
- Build with modules, and keep go.mod and go.sum committed.
- Add trimpath so builds do not leak your build machine paths.
- Keep the Go version current, and rebuild on every standard library fix.
- Generate an SBOM from the built artifact as well as from the source tree.
- Compare the two. A difference points to something built that you did not expect.
- Store the SBOM with the image, so you can answer "which services contain this module" later.
Where Safeguard fits
Safeguard scans Go modules from your repository and generates SBOMs, with reachability analysis to prioritise findings in code paths you call. Asset discovery helps you find which services carry an affected module. You can start with the free scan, and the interactive demo below shows the inventory view.
Try it yourself
Click through the demo and notice how components are listed with versions. Build info gives a scanner the same kind of list for a compiled Go program.
Click through it at your own pace, or open it full screen.
Quick check
Does stripping a Go binary remove its module list?
Stripping removes symbol information. The Go documentation describes build information as separate data embedded in the binary, so verify with your own binary and the go version command.
Does a scanner need the source to report Go module vulnerabilities?
Not if the binary was built in module mode and the tool reads its build info. Source based scanning of go.mod remains useful as well.
Sources
Last reviewed: 19 October 2026.
