Start a new Go service by committing go.mod and go.sum, pinning the toolchain in CI, scoping GOPRIVATE tightly, leaving the checksum database on, scanning with reachability, and gating pull requests that change dependencies. These settings cost little on day one and are hard to retrofit.
The checklist
| Area | Setting | Why |
|---|---|---|
| Repository | Commit go.mod and go.sum | Go uses go.sum to verify downloaded modules |
| Toolchain | Pin in the build image, GOTOOLCHAIN=local in CI | Avoid surprise compiler changes |
| Checksum database | Keep GOSUMDB on | Same contents for every user |
| Private modules | Narrow GOPRIVATE pattern | Avoid skipping verification for public code |
| VCS tools | Consider GOVCS limited to git | Smaller fetch surface |
| Tools | Use the tool directive | Versioned dev tools |
| Scanning | Reachability aware scan on every PR | Fewer, better findings |
| Release | Record go version -m output | Trace what shipped |
Steps
- Create the module and commit both go.mod and go.sum with the first dependency.
- Choose the Go version and set the go line. Add a toolchain line for the patch release you test with. See go line vs toolchain line.
- In CI, use a base image with that Go version and set
GOTOOLCHAIN=local. - Configure
GOPRIVATEfor your own organization only. Read what each private module variable does. - Add a check that go.mod and go.sum are tidy. Run
go mod tidyand fail the job if files change. - Add vulnerability scanning on each pull request, using a tool that applies reachability. Compare with version matching as described in why govulncheck reports fewer issues.
- Add a review rule: go.mod, go.sum and CI configuration changes need a second reviewer.
- Write down who owns dependency updates and how often they run.
- At release, store the dependency list read from the binary with the release record.
What to avoid from the start
- Setting
GOSUMDB=offor wideGOINSECUREpatterns to get past a first error. See what each setting disables. - Committing local path replace directives.
- Installing developer tools with
@latestin scripts.
Why Go helps you here
Go has no install scripts, no package repository accounts and builds locked by the main module's go.mod, per the Go team's supply chain article. Those are real advantages. The remaining risk sits in what you import, how you update, and how you configure the toolchain, which is what the checklist covers.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request is held when a dependency finding crosses the policy.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policies and gates for pull requests. You can start with a free scan.
Quick check
Is go.sum needed if go.mod pins versions?
Yes. go.mod chooses versions, and go.sum records the hashes used to verify them.
Should CI allow toolchain downloads?
Preferably not. Pin the toolchain in the image and set GOTOOLCHAIN to local so changes are deliberate.
Sources
Last reviewed: 19 October 2026.
