Yes. In source mode, govulncheck analyzes the code using the Go version found on your PATH, so an older toolchain can show extra standard library findings. The fix is usually to build with a newer Go release, not to change a module requirement in go.mod.
What the tool says
The Go tutorial notes that if you are not using the latest version of Go, you may see additional vulnerabilities from the standard library. The sample output prints which Go version it used, so you can see which toolchain was in play.
The reference for the command adds that source analysis uses the Go version of the go command on your PATH. For binaries, it uses symbol information in the file instead.
The go line is not the toolchain
Two lines in go.mod are easy to mix up.
| Line | Meaning |
|---|---|
| go | The minimum Go version needed to use the module, and the language version enforced |
| toolchain | A suggested toolchain, used when the module is the main module and the local toolchain is older |
The Go toolchain documentation says a toolchain line takes precedence over the go line when the go command picks which toolchain to run. If it is omitted, the module is treated as having a toolchain matching the go line.
So raising the go line does not by itself prove you build with a patched standard library. What matters is which toolchain actually compiles the code, in CI and on release builds.
How to check
- Run the scan in the same environment that builds your release.
- Read the Go version the scan prints.
- If standard library findings appear, update the toolchain used by that environment, then rebuild.
- Re-run the scan against the new build.
For compiled binaries:
govulncheck -mode binary ./app
The reference notes binary output omits call stacks, because Go binaries do not contain detailed call information.
Reachable versus informational
The tutorial separates two kinds of result. Affected means a call stack from your code reaches a vulnerable symbol. Informational means the module is vulnerable and imported, but no call reaches it. Both are worth reading, but they call for different urgency.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability is applied, and note which findings drop to lower priority.
Quick check
Can a scan on my laptop differ from a scan in CI?
Yes, if the Go versions differ. Source scans use the go command on the PATH, so the toolchain affects the standard library results.
Does govulncheck let me silence a finding?
The command reference says there is no support for silencing findings. Track accepted risks in your own process.
Safeguard's reachability analysis separates vulnerable code that your project can reach from code it cannot, which helps order the work. The free scan shows a first result.
Sources
- Tutorial: Find and fix vulnerable dependencies with govulncheck
- govulncheck command reference
- Go Toolchains
Last reviewed: 19 October 2026.
