govulncheck is the Go team's vulnerability scanner. It reports a vulnerability only when your code transitively calls the affected function, which keeps results short and focused on code paths you actually use. Install it with go install and run govulncheck ./... from your module root.
Where the data comes from
The Go team collects reports from the National Vulnerability Database, the GitHub Advisory Database and directly from package maintainers. The Go Security team reviews and curates each entry. Reports use the Open Source Vulnerability format and are served from vuln.go.dev and through an API. pkg.go.dev, govulncheck and editors with the Go extension read that database.
What reachability means here
Most dependency scanners flag any module version listed in an advisory. govulncheck goes further. It analyzes which functions in your code call, directly or through other code, the vulnerable function. If your module imports the package but never reaches the affected function, it is not reported as affecting you.
That changes how you read the output. A finding means a call path from your code to the problem exists, and the report can show it.
Running it
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...
You can also see results in an editor through the Go extension. For continuous integration, a common approach is to add govulncheck ./... as a pipeline step. Check the current govulncheck documentation for its exit code behavior before you make it a blocking gate.
What the database does not do
Three details from the Go documentation matter when you set expectations:
- No severity ratings. Entries are not labeled low, medium or critical, because impact depends on context. They describe what the issue is and how it can be triggered.
- Some code is excluded. A report may be left out if the vulnerable code is not in an importable Go package, for example when it is in an installable command.
- Curated, not exhaustive. Another report in the database may already cover an issue, so entries can be merged.
Treat govulncheck as one signal among others, and pair it with checks for the parts of your stack it is not built to cover.
A simple routine
- Run govulncheck locally before a release.
- Run it in CI on pull requests and on a schedule, since new reports appear after you merge.
- For each finding, read the call path, then upgrade the module or change the code.
- Record accepted risks with a reason and a date.
Safeguard's SBOM and dependency scanning and reachability analysis apply the same idea across a wider set of ecosystems, which helps when your estate is not only Go. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does govulncheck scan every module in go.mod?
It checks your code against the database and reports where your code reaches a vulnerable function. A module that is present but never called is not reported as affecting you.
Why are there no severity scores?
The Go team says impact depends on how the code is used, so entries describe the issue instead of assigning a rating.
Sources
Last reviewed: 19 October 2026.
