go.sum is a file of cryptographic hashes for the module versions your Go project depends on. Each line has a module path, a version and an h1: hash. Go compares downloads against these hashes, so a module that changes after publication triggers a security error. Commit it next to go.mod.
The line format
Per the Go modules reference, each line has three space separated fields: module path, version, and hash. The hash is h1: followed by a base64 SHA-256 value. Today h1 is the only supported algorithm.
A typical module has two lines:
example.com/m v1.0.0 h1:AAAA...
example.com/m v1.0.0/go.mod h1:BBBB...
If the version ends in /go.mod, the hash covers only that module's go.mod file. Otherwise it covers the module's zip contents. Go needs the go.mod hash separately because it reads dependency go.mod files to work out the module graph, even for modules whose code it never builds.
What go.sum is and is not
| Question | Answer |
|---|---|
| Does it pin versions? | No. Versions come from go.mod. |
| Does it verify downloads? | Yes, it records hashes that must match. |
| Can it hold several versions of one module? | Yes. |
| Who edits it? | go get and go mod tidy |
The Go team's own supply chain write up says checksums are only changed by go get and go mod tidy, so a build does not quietly rewrite them.
If an entry is missing, the go command may check the checksum database and then add the hash, unless GOPRIVATE or GONOSUMDB covers the module or GOSUMDB is off. That is why a first fetch of a new dependency is the moment trust is established, and why the checksum database matters.
Review a go.sum diff
- Run
git diff go.sumon any pull request that touches dependencies. - Match every added line to a go.mod change. A new module with no matching require line deserves a question.
- Look for removed lines for a version you did not intend to drop.
- Check that a version you already used did not get a different hash. That should never happen for a normal release.
- Run
go mod tidyand confirm it produces no further changes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive dependencies are listed, the same set go.sum has to cover.
Where Safeguard fits
Safeguard reads go.mod and go.sum as part of SBOM and dependency scanning and applies reachability analysis to the findings. You can try a free scan on a repository.
Quick check
Why are there two lines per module?
One hash covers the module zip and the other covers its go.mod file, which Go reads when building the module graph.
Is go.sum a lockfile?
No. Versions are chosen by go.mod. go.sum records the expected hash for each version used.
Should go.sum be committed?
Yes. The Go documentation says to include both go.mod and go.sum in your repository.
Sources
Last reviewed: 19 October 2026.
