How does the Go checksum database protect the supply chain? What does go mod verify actually check?

sum.golang.org is an append-only, Merkle-tree transparency log (Trillian) of go.sum lines for every public module version. The first time anyone in the world downloads mod@v, its hash is recorded permanently. Your go command verifies downloaded hashes against the log using inclusion and consistency proofs. So even if a proxy, or the author (by force-pushing a tag), serves different bytes to you, the mismatch is detected: "SECURITY ERROR: verifying module: checksum mismatch".

Layers of protection:

1. go.sum in your repo pins hashes for your team.
2. The checksum DB pins them for the whole ecosystem (trust on first use, globally).
3. The proxy caches immutable copies, so deleted repos stay buildable.

go mod verify
# all modules verified
# checks that module-cache zips / extracted dirs still match the hashes
# recorded at download time (detects local cache tampering)

govulncheck ./...   # separate tool: reports vulns in code paths you actually call

Gotchas: go mod verify does not re-contact the network or compare against go.sum from scratch. It checks the local cache. A malicious but consistently served version (typosquatting) is not caught by checksums. For that you need review, govulncheck, and pinning. Mentioning govulncheck's call-graph reachability is a strong senior signal.