govulncheck and dependency hygiene: symbol reachability, go.sum integrity, and MVS without surprise upgrades
govulncheck reports only vulns your code actually reaches through the call graph — often a 10:1 cut over image scanners. go.sum pins content hashes while go.mod selects versions, MVS never upgrades without an explicit bump, and nightly scans catch new CVEs in old code.
The bulletin landed Friday at 4 p.m.: CVSS 9.8 in a YAML parsing library, and go mod graph confirmed it — three levels deep, pulled in by the config loader of an internal framework, present in all eleven services. The container scanner had already painted every dashboard red. Two teams on the floor canceled weekend plans and started emergency bumps across their repos. One engineer instead ran govulncheck ./... and read the output carefully: the finding was informational — the module was in the build, but the vulnerable symbol, the recursive alias resolver inside Unmarshal’s deep path, was not reachable from any call path in their code. They used strict typed decoding; the dangerous function never appeared in the call graph. She attached the trace output to the incident ticket, the security lead signed off, and the team shipped the upgrade in Monday’s regular release train — same fix, zero weekend. The other two teams shipped a hotfix at 2 a.m. and rolled one service back twice. The difference was not courage. It was knowing the difference between a dependency you have and a function you call.
Reachability, not presence
Have you ever had a scanner light up every dashboard with a CVSS 9.8, only to spend Friday evening arguing about whether your code actually uses that function? There is a better question to ask first — and Go’s toolchain asks it.
Container and SCA scanners answer a shallow question: which module versions appear in your artifact, and which CVE ranges do they intersect? govulncheck answers the question you actually triage by: can execution reach the vulnerable code? It builds a static call graph of your program, maps it against the Go vulnerability database (vuln.go.dev), where each report names the affected symbols — specific functions and methods — and reports a finding only when a call path exists from your code to one of those symbols. Everything else is demoted to informational.
$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ govulncheck ./...
=== Symbol Results ===
Vulnerability #1: GO-2022-0969
...
Example traces found:
#1: api/handler.go:42 handler.Process calls yaml.UnmarshalThe noise reduction is the entire value proposition: scanner output for a typical service lists dozens of module-level CVEs, and in practice the large majority are unreachable — teams commonly see on the order of a 10:1 cut in findings that demand action. Each real finding comes with a trace (the call chain from your function to the vulnerable symbol), which converts triage from “argue about a CVSS score” to “read a stack”. For deployed artifacts there is govulncheck -mode=binary, which checks a compiled binary using its symbol table — what is actually linked in, not what the source tree implies.
The honest caveats, because reachability is static analysis: calls through reflection, plugin, or code generation can hide paths, so “not reachable” means deprioritized, not ignored — the bump still happens, just on a schedule. And govulncheck only covers Go code; your C dependencies and base image stay the scanner’s job.
An image scanner reports 23 CVEs for a Go service; govulncheck reports 2 findings and 21 informational entries. What explains the difference?
Where it runs: every PR, and every night
Two triggers, two reasons. On every PR, because a new dependency or a new call into an old dependency can introduce reachability the moment it merges. And nightly on main, because the other input changes without you: new CVEs are published against code you have not touched in months. A repo that only scans PRs is blind between merges — exactly the window the Friday bulletin exploits. The CI shape is boring on purpose: govulncheck ./... as a PR gate that fails on symbol-level findings, the same command on a nightly schedule that opens a ticket instead of failing a build, plus -mode=binary against released artifacts if your deploy lags your merges.
▸Why this works
Why does the nightly run earn its keep when the code is frozen? Because a vulnerability report is a join between two tables — your call graph and the vuln DB — and both sides change independently. PR scans cover changes to your side. The DB side changes daily: the Go security team publishes new reports continuously, often for code that has been in your build for a year. The nightly scan is how a Tuesday disclosure becomes a Tuesday ticket instead of a customer-reported incident in week six.
go.mod selects, go.sum verifies
The two files protect against different attacks, and conflating them is how teams misjudge their exposure. go.mod is version selection: which module versions the build wants. go.sum is integrity: cryptographic hashes of every module version’s content, recorded the first time it enters the build. On every later download, the toolchain recomputes hashes and refuses to build on mismatch — if the same version of a module ever shows up with different bytes (compromised proxy, retagged repo, tampered mirror), the build fails loudly instead of compiling attacker code. First-time additions are verified too, against the public checksum database (sum.golang.org), a transparency log the proxy cannot silently rewrite. GOPRIVATE carves out your internal modules from that public lookup — keep its scope narrow, because everything it matches loses sumdb verification.
The proxy layer adds an availability-and-immutability guarantee: once proxy.golang.org caches a module version, that version is served immutably — upstream deletion or retagging does not change what builds see. The left-pad class of incident (a dependency vanishing and breaking the world) and the retag class (same tag, new content) are both structurally addressed, which is why turning the proxy off buys you nothing but risk.
MVS: boring by design
Go’s minimal version selection picks, for each module, the maximum of the minimums stated in go.mod files across the graph — never “latest available”. The security consequence deserves spelling out: publishing a new version of a module does nothing to your build. A malicious v1.9.9 pushed to a popular library sits inert until some go.mod in your graph explicitly requires it. Contrast npm-style ranges (^1.2.0), where the next clean install resolves to the freshest matching version — the exact mechanism behind several large supply-chain attacks, where the window between malicious publish and detection was enough to compromise thousands of CI runs. In Go that window simply does not exist; upgrades happen when a human runs go get.
The tradeoff is symmetric and must be managed: security fixes also wait for an explicit bump. MVS plus no scanning is how builds rot into unpatched staleness. The pairing that works is MVS for determinism plus govulncheck for urgency: bump on schedule normally, bump immediately when a reachable finding says so.
A CI build fails with a go.sum checksum mismatch for a module version that built fine last week. What does this actually indicate?
Fewer dependencies beat scanned dependencies
Every control above operates on the dependency graph you already have; the strongest control shrinks it. A dependency is a standing grant of execution rights in your process plus a permanent line in your audit budget — so the review question for a new direct dep is not “is it good code” but “is it worth auditing forever, and what does it drag in?” (go mod graph | wc -l before and after is a sobering diff.) For existing weight, go mod why -m <module> answers “why is this here” with the import chain, and go mod tidy keeps the requirement list honest. The module namespace adds one Go-specific sharp edge: module paths are URLs, mostly GitHub paths, and typosquatting lives one transposed letter away — github.com/sirupsen/logrus has a documented history of squatted misspellings. Import paths get the same review attention as the code that uses them.
- 01Explain the mechanism that lets govulncheck report 10x fewer actionable findings than an image scanner, and the two caveats that come with it.
- 02Walk through what go.mod, go.sum, the module proxy, and MVS each guarantee, in security terms.
The Go security toolchain triages by a sharper question than any version scanner can ask: not which modules are present, but which vulnerable functions your program can actually reach. Now when you see a scanner report with dozens of CVEs, your first move is govulncheck ./... — let the call graph separate the Friday fire drill from the Monday chore, and never silence a finding without a trace that says why it is unreachable. govulncheck builds a static call graph, joins it against the symbol-annotated Go vulnerability database, and fires only on findings backed by a concrete trace from your code — in practice cutting actionable alerts by an order of magnitude and turning Friday fire drills into scheduled Monday bumps. Its caveats are part of using it honestly: static analysis cannot see through reflection or plugins, so unreachable means deprioritized-with-a-ticket, and Go-only scope means image scanners keep their job for the OS layer. Run it twice: as a PR gate, because merges add reachability, and nightly, because the vuln DB changes against your frozen code. Beneath the scanner sits the integrity stack: go.mod selects versions, go.sum verifies that every downloaded module version matches its recorded content hash (mismatch fails the build — deleting the line to make CI green means trusting whatever is served right now), the checksum database makes first sightings publicly auditable, and proxy.golang.org serves cached versions immutably so retags and deletions upstream cannot reach you. MVS makes the whole graph deterministic — maximum of stated minimums, never latest — which closes the publish-and-wait attack window npm ranges leave open, at the symmetric price that security fixes also arrive only by explicit bump. And the control that beats all of it is subtraction: every dependency is a permanent audit obligation, go mod why names the chain that justifies each one, and import paths deserve the same typosquat-aware review as code.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.