Check whether your code calls the vulnerable function, upgrade with go get module@fixed-version, run go mod tidy, test, and release. For a library, that raises your minimum version in go.mod, which Go's resolver then respects for every user who depends on you. Confirm the fix with a second scan before you ship.
Step 1: Find out if you are affected
The Go documentation describes govulncheck as a tool that analyzes your code and surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions. Its data comes from the Go vulnerability database, built from sources including the NVD and the GitHub Advisory Database, plus direct submissions from maintainers, and curated by the Go Security team.
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...
If it reports nothing for the advisory in question, your code does not call the vulnerable symbol. You can still upgrade, but you have time to plan it.
Step 2: See what is available
The Go module documentation shows how to discover updates for all dependencies:
go list -m -u all
go list -m -u example.com/theirmodule
These list each dependency and the latest version available.
Step 3: Upgrade to a fixed version
Use the first version that contains the fix, named in the advisory. To go to a specific version:
go get example.com/theirmodule@v1.3.4
To take the latest:
go get example.com/theirmodule@latest
Choose the smallest jump that includes the fix. It lowers the chance of breaking changes.
Step 4: Tidy and test
go mod tidy
go test ./...
go mod tidy adds missing modules needed by imported packages and removes unused ones. Review the diff in go.mod and go.sum before you commit. A large unexpected change deserves a look.
Step 5: Re-run the check
Run govulncheck again to confirm the finding is gone. If it persists, the vulnerable version may still be pulled in through another dependency. Find which one with go mod graph and upgrade that module in turn.
Step 6: Release
If your library is affected, publish an advisory and a patch release, with the raised minimum noted in the release notes. If you are not affected, a normal release is enough, and a short statement helps users whose scanners flagged you.
When there is no fixed version
If upstream has not released a fix, your options are the same as in any ecosystem: wait, replace the module, or remove the call. The Go docs show that go get example.com/theirmodule@none removes a dependency, and warn it may also downgrade or remove other dependencies that rely on it. Check the result before you commit.
A quick table
| Task | Command |
|---|---|
| Check reachability | govulncheck ./... |
| List updates | go list -m -u all |
| Upgrade one module | go get module@version |
| Clean up | go mod tidy |
Quick check
Does a library's go.mod minimum protect users?
Go resolves to the highest minimum required across the module graph, so raising yours raises the floor for projects that depend on you, unless they require something higher already.
Is govulncheck output the same as a general scanner?
No. It reports only vulnerabilities whose vulnerable functions your code can call, so it shows fewer, more relevant results.
Safeguard's reachability analysis applies the same idea across ecosystems and can open fix pull requests, which are off by default. Try the free scan.
Sources
- Go documentation, managing dependencies: https://go.dev/doc/modules/managing-dependencies
- Go documentation, vulnerability management: https://go.dev/doc/security/vuln/
Last reviewed: 19 October 2026.
