Govulncheck has two main modes. Source mode analyzes your module and shows call stacks. Binary mode inspects a compiled executable using its symbol information, omits call stacks, and may report false positives for code that is in the binary but unreachable. Use source mode when you can and binary mode for artifacts you did not build.
Source mode
Source mode is the default. You run it from the module directory with the usual package pattern, for example the command below.
govulncheck ./...
It uses the Go version on your path as the build configuration. The default output gives a brief summary of how your code reaches a vulnerable function, and a flag for traces prints the full call stack for each finding. That call stack is the evidence a reviewer wants.
Binary mode
Binary mode takes a compiled file.
govulncheck -mode binary ./myapp
Per the documentation, it uses the binary's symbol information to find mentions of vulnerable functions, and the build configuration is the one used to build the binary. Output on binaries omits call stacks, because those need source code analysis.
The tradeoffs
| Source mode | Binary mode | |
|---|---|---|
| Needs source | Yes | No |
| Call stacks | Yes | No |
| False positives | Fewer | May report code that is present but unreachable |
| Good for | Your own repos in CI | Released artifacts, third party binaries |
Limits that apply to both
The documentation lists limits worth remembering. Calls through the reflect package are not visible to static analysis. Use of the unsafe package may cause false negatives. Interface and function pointer calls are handled conservatively. Binaries built with Go versions before 1.18 only report standard library vulnerabilities. There is no support for silencing findings.
A sensible setup
- Run source mode in pull requests for modules you own.
- Run binary mode against release artifacts, as a check that what shipped matches what you tested.
- When binary mode flags something source mode did not, inspect the difference rather than assume either is wrong.
- Record decisions in your own tracker, since the tool does not silence findings.
For the general idea behind the results, see what is a call graph.
Reading the output
In source mode, findings are grouped by whether your code calls the vulnerable function. Items you only import, without calling, are reported with less urgency than items with a call stack. Keep that distinction when you copy results into tickets. A ticket that says your code calls a named function through a shown path gets fixed faster than one that says a dependency has a CVE. Include the trace output in the ticket so reviewers can check it.
Quick check
Why does binary mode show no call stack?
The documentation says call stacks require source code analysis, and binary mode works from symbols.
Which mode is stricter?
Source mode is more precise. Binary mode can flag code that exists in the file but is never called.
Safeguard covers dependency scanning and reachability, and you can run a free scan to compare against your Go tooling.
Sources
Last reviewed: 19 October 2026.
