What Go's Checksum Database Does and Does Not Guarantee
A Go build may fetch module content from a proxy, a version-control server, or a local cache. That flexibility saves time and works well in restricted networks, but it also creates a question: how does the go command know that a downloaded module is the same content other builds received? The checksum database is one part of the answer.
The trust model
The Go Modules Reference says modules may be downloaded directly from version-control repositories or from module proxies. When the go command downloads a module zip or go.mod file, it computes a cryptographic hash and compares it with a known value. The go.sum file records expected hashes for a module.
If the module is not already represented in go.sum, the command can consult the checksum database. The public service is sum.golang.org, controlled through GOSUMDB. This is why the Go project describes the checksum database as a way to use an otherwise untrusted proxy: the proxy supplies bytes, while the checksum service provides another source of truth for the module hash.
The boundary is easy to misunderstand. GOPRIVATE acts as a default for GONOSUMDB and GONOPROXY. A module matched by GOPRIVATE or GONOSUMDB is not checked against the public checksum database. Setting GOSUMDB=off has a similar consequence for checksum verification. The Go documentation states that in those cases the command accepts the hash and adds it to the module cache without verifying it.
What the database is good for
For public modules, the checksum database makes a proxy substitution visible. If a proxy serves different bytes under the same module version, the calculated hash should not match the published checksum. That property matters to CI runners, build caches, and dependency mirrors that are outside the application team's direct control.
The database does not decide whether a module is malicious. A maintainer can publish a bad release and generate a valid checksum for it. A compromised version-control account can also publish a new version with a new legitimate checksum. Checksum comparison establishes consistency with a recorded module version. It does not establish intent, code quality, or the absence of a backdoor.
Private modules need a separate policy. Disabling the public checksum database may be necessary when the module path must not be disclosed, but the organization still needs an internal control. Common options include a private proxy with controlled writes, immutable tag rules, artifact signing, reviewed source access, and an internal record of approved module hashes.
Review the exceptions
Inspect build images and CI variables for GOSUMDB, GONOSUMDB, GOPRIVATE, GOPROXY, and local GONOSUMDB exceptions. A narrowly scoped private namespace is easier to review than a broad wildcard. Check that the exception applies only to modules that truly require it and that the build fails closed when the private proxy is unavailable.
During dependency investigation, preserve the exact go.sum, module proxy response hashes, resolved versions, and build logs. Compare them across build hosts. A clean go.sum match answers a narrow integrity question. Analysts still need to review the module source, maintainer accounts, release history, and behavior of the code that was actually linked into the binary.
