No, go.sum is not a lockfile. It stores cryptographic hashes that the go command uses to check that downloaded modules have not changed. The versions your build uses come from go.mod and minimal version selection, so a Go project has no separate lock file that records the build list.
What each file does
| File | Job | Who writes it |
|---|---|---|
| go.mod | Declares minimum required versions of each module | You and the go command |
| go.sum | Records hashes for module zips and go.mod files | The go command |
| vendor/modules.txt | Records the vendored copy, when you vendor | go mod vendor |
The Go reference says it directly: unlike other dependency managers, the build list is not saved in a lock file. Minimal version selection is deterministic, and the build list does not change when new versions of dependencies are released, so Go computes it at the start of each module-aware command.
What go.sum actually holds
Each line has a module path, a version, and a hash. SHA-256 is the only supported algorithm, written with an h1 prefix. A version ending in /go.mod means the hash covers only that module's go.mod file. Otherwise it covers the module zip.
The file can list several versions of one module, because version selection may need go.mod files from more than one. It can also carry stale lines after an upgrade, and go mod tidy adds missing hashes and removes unneeded ones.
What happens when a hash does not match
The go command hashes each downloaded file and compares it with the line in the main module's go.sum. If they differ, it reports a security error, deletes the download and does not add it to the module cache. If a hash is missing, it can check the checksum database and then record it.
What this means for scanning
A scanner that wants the exact set of modules in your build should read go.mod, resolve the module graph, and treat go.sum as supporting evidence about integrity. Reading go.sum alone is a poor inventory: it can contain versions that are not in the build, and it says nothing about which version was selected.
To see the selected versions yourself, run this in the module directory:
go list -m all
That prints every module in the build list, one per line, with the selected version.
Should you commit go.sum
Yes, in practice. Without it, each machine must fetch and verify hashes again, and you lose the check against your recorded values. Treat go.mod and go.sum as a pair in code review.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and compare which component versions come from a manifest and which from resolved files. Note how a hash file would not give you that list.
Quick check
Do I need go.sum to be in version control?
Commit it. It records the hashes your builds are checked against, and reviewers can see when a hash changes.
Why does go.sum list more versions than my build uses?
Version selection may need go.mod files from several versions, and old lines can remain after upgrades until go mod tidy removes them.
Is there a way to get a lock-style list from Go?
Run go list -m all. It prints the build list with the selected version of every module.
Safeguard's SBOM and dependency scanning builds an inventory from your project files and checks it against known advisories. You can try it on a repository with the free scan.
Sources
Last reviewed: 19 October 2026.
