Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Go module hashes cover file names and contents, not zip encoding, so an independently rebuilt archive can match exactly.
- Because of that, pointing GOPROXY at a screened registry does not invalidate the go.sum entries you already have.
- Exact reconstruction proves an archive matches its source, not that the source is safe.
- The change itself is one environment variable, and the real risk sits in configuration drift.
In July 2026, researchers tied a wave of compromised maintainer accounts across npm, Packagist, and Go modules to a North Korea-linked campaign called PolinRider. The campaign published brand-new malicious packages too, but the part worth sitting with is what happened to established ones. Attackers got into accounts with years of clean history and pushed new versions from there.
A new module version pushed from a compromised maintainer account can pass Go’s integrity checks on first use. Both go.sum and the checksum database confirm you received exactly what was published. Neither has any opinion on whether what was published is safe.
Adding a screening layer to a build can introduce friction somewhere. New package identities to reconcile, versions to chase, lockfile changes nobody budgeted for. Go gets off comparatively lightly, and the reason is worth understanding, because it also explains what verification in Go can and cannot prove.
Why Go Module Archives Can Be Verified Exactly
A Go module zip holds source. Nothing gets compiled on the way in, and the archive layout follows a documented algorithm rather than whatever a publisher’s packaging script happens to do that day.
That has a consequence most people skip past. Go computes the module hash over the file names and the file contents inside the archive. The zip encoding, the compression method, per-file modification times, and other metadata are all ignored. So anyone with access to the version control history can rebuild the module and land on the same h1: checksum, even when the two zip files differ byte for byte.
Other ecosystems have more moving parts between a repository and a published artifact. Maven ships compiled JARs. Python wheels are build output. An npm tarball might be plain source, or it might be whatever a prepack script left behind. Reproducible build work has made real progress in several of these, so this is not a clean line between impossible and exact. It is that Go’s checksum was designed from the start to ignore packaging noise, which makes independent reconstruction unusually cheap to check.
What differs between vendors is whether anyone actually runs that comparison at registry scale, on every module, every time. A screening registry can pull the VCS history for a module path, build the archive per spec, and check it against what the public proxy served. A mismatch means the archive does not correspond to the source it claims to come from.
That distinction carries more weight than it first appears. Exact reconstruction tells you an archive matches its claimed source. It says nothing about whether the source itself is safe. PolinRider is the case in point, because the attackers modified the legitimate repositories directly, in some cases force-pushing over existing commits. A faithful rebuild from that source reproduces the malicious content just as faithfully. Reconstruction catches tampering between the repo and the archive. Catching bad code inside the repo is a separate job.
Note: For artifacts that need compilation, packaging scripts, or generated files, “rebuilt from source” also means reproducing those build conditions. Go’s checksum comes straight from the packaged source tree, which makes the comparison unusually straightforward to audit. Ask a vendor to show you a mismatch – not to describe one.
Why go.sum Keeps Working
If a registry reconstructs module archives, do the hashes change, and does every go.sum in the organization break?
No. Because the hash covers the file tree and ignores packaging details, a correctly reconstructed archive hashes to the same value the public proxy would have produced. Your existing go.sum entries validate against it, and the checksum database at sum.golang.org keeps agreeing.
That is why the switch needs no changes to go.mod or go.sum. It is not a migration path that happens to be short. There is nothing to migrate. Matching hashes are the expected outcome, and a divergence is a signal rather than an inconvenience.
One case breaks that symmetry, and it deserves a blunt answer rather than a footnote. Go treats a module path and version together as immutable. So if a registry serves patched contents for a version that already exists upstream, those contents cannot reuse the upstream checksum. An existing go.sum entry would reject the changed bytes outright, and the public checksum database would go on holding the upstream hash. Patched modules therefore need a documented delivery mechanism of their own, whether that is a distinct version, a distinct module path, or another controlled trust configuration. If post-EOL patching is part of why you are switching, confirm that mechanism with TuxCare before you plan the rollout. It is the one place where “nothing changes” stops being true.
The One Line
GOPROXY accepts any URL that implements the module proxy protocol, so pointing it at a screened registry is an environment variable change.
go env -w GOPROXY=<your SecureChain Go proxy URL>,direct
Use a comma before direct rather than a pipe, and know what each one actually buys you. With a comma, Go falls back to the next entry only after a 404 or 410. With a pipe, it falls back after any error, including a timeout, so a registry outage quietly routes your build around the thing you installed the registry for. Either way, direct means fetching straight from the version control source, and a comma still lets a 404 through to it. If the registry is meant to act as a gate rather than a suggestion, blocked modules should come back as something other than not found. Go’s own reference points at 403 for exactly this purpose.
This works whether GOPROXY points at SecureChain directly or at a repository manager like Artifactory or Nexus that is itself pointed at SecureChain. Same modules, same workflow either way.
For CI, set it in the environment rather than baking it into an image.
export GOPROXY=<your SecureChain Go proxy URL>,direct
export GOSUMDB=sum.golang.org
Leaving GOSUMDB explicitly on is deliberate. Checksum verification and registry screening answer different questions, and swapping proxies is not a reason to turn either one off.
Pro Tip: Set GOPROXY with go env -w on developer machines, and through CI environment variables on build agents. Then run go env GOPROXY on an actual runner to see what is really set. Base images sometimes ship their own value baked in, and that is usually what trips these rollouts up.
What Stays the Same and What Changes
| Item | Changes |
| go.mod | No |
| go.sum for upstream modules served as-is | No |
| go build, go test, go get | No |
| Vendored directories | No |
| Version selection behavior | No |
| Where archives are fetched from | Yes |
| Whether archives are screened before resolution | Yes |
Nothing in your build commands changes, and nothing in the repository changes. What moves is where the archive comes from and whether it gets checked before your build ever sees it. One caveat on that vendored row, though. A vendored build reads from vendor/ and never asks the proxy at all, so it gains nothing from the switch until you refresh the directory.
What Screening Adds Before Resolution
Go has no install-time hook equivalent to npm’s lifecycle scripts, which is normally a point in its favor. That does not make a module’s contents harmless. Malicious source still ends up compiled into your binary, and the tooling around a repository can open its own execution paths. PolinRider is a good example of the second kind. The payloads were obfuscated JavaScript loaders tucked into project assets, including fake .woff2 font files, rather than anything running from a Go init function.
That makes pre-resolution screening one of the earliest automated opportunities to stop malicious content before it reaches the build environment.
Three flavors of the problem show up, and they need three different answers.
A repojacked module path can serve a new malicious version through the legitimate path without violating any checksum Go already holds, because those checks authenticate module contents rather than repository ownership or intent. Rebuilding from that compromised VCS source does not help either, since the repository now belongs to the attacker. Screening the content for malware before resolution does.
A version published upstream after an account compromise is the PolinRider case. go.sum and the checksum database can authenticate it successfully, because they answer whether these are the same bytes rather than whether these bytes are safe. Screening is what closes that gap.
An abandoned module carrying a CVE is a different problem entirely. Nothing malicious got in. The maintainer just stopped fixing what was already there. Advisories will tell you about it, but closing it means keeping the module patched after its author has moved on, which is upkeep rather than screening. That is what Endless Lifecycle Support (ELS) covers.
The scale of the account takeover case is worth a look. Researchers found compromise traces in 80 Go modules among 108 unique packages hit across the campaign, with 162 malicious release artifacts in total, and tracked the activity as part of Contagious Interview, also known as Famous Chollima. Those modules were compromised through accounts with years of legitimate history rather than newly registered lookalike names, which is exactly what integrity verification alone cannot catch. A new version like that passes on first resolution because the hash faithfully authenticates whatever content is associated with that version, and a push from a long-trusted maintainer does not look suspicious on its face.
There is an uncomfortable wrinkle here for Go specifically. Because Go modules are commonly sourced straight from VCS tags or commits rather than uploaded separately to a registry, a repository compromise can propagate into the module ecosystem without the attacker needing a second set of credentials. Researchers noted that one compromised maintainer’s account showed no malicious releases in an ecosystem that requires a separate upload step, which may mean the attackers never got that far.
Abandonment is the quieter version of the same exposure. A recent analysis of 13.1 million open source packages put Go’s out-of-band share, weighted by dependent repositories rather than by package count, somewhere between 33.2% and 57.9%. The spread comes down to definition – the upper figure counts anything without a release in 730 days. The lower one also requires no repository commits in that window. Either way, the named Go examples land close to home: gopkg.in/yaml.v2, jwt-go, AWS SDK for Go v1. No registry architecture, screened or not, addresses that on its own. It takes ongoing patching, which is what the third case above is for.
Rolling It Out Without Breaking Builds
Four phases, and the ordering matters more than the speed.
| Phase | Action | What you learn |
| 1 | Set GOPROXY on one non-critical service | Whether any module path fails to resolve |
| 2 | Download and verify dependencies from an empty module cache | Whether modules served through the new registry authenticate against your existing go.sum |
| 3 | Roll to CI across all repositories | Which pipelines had GOPROXY hardcoded in an image |
| 4 | Restrict build agent egress to the registry and the checksum database | What was quietly bypassing the configuration |
Phase two produces the evidence a skeptical reviewer will actually ask for.
go clean -modcache
go mod download
go mod verify
Worth being precise about what each command proves. With an empty cache, go mod download forces the required modules through the new registry and authenticates them against your committed go.sum entries, or against the configured checksum database where a hash is not already recorded. go mod verify then confirms the cached contents have not changed since they were downloaded. Follow both with your normal build or test run, and the compatibility claim is validated against your project’s current dependencies in your own environment rather than in a vendor deck.
Phase four is where policy turns into enforcement. Until egress is closed, GOPROXY is a suggestion anyone can override to unblock a Friday deploy. Blocking proxy.golang.org on its own will not do it, because that trailing direct sends 404s off to GitHub and friends instead. Allowlist the registry and deny the rest. One check before flipping the rule – checksum verification still needs access to the checksum database, either directly or through a proxy that mirrors it, so confirm those lookups keep resolving instead of finding out during the first broken pipeline.
Pro Tip: Run phase four in staging long enough to exercise your normal build workflows before production. What surfaces is the real inventory of pipelines that were resolving directly without anyone knowing, and that inventory is far better as a list now than as an incident later.
Secure Your Go Supply Chain
If phases one and two have already passed in your own repos, against your own go.sum, that is the compatibility evidence a security review needs and you produced it yourself. What SecureChain for Go adds from there is continuous screening at every fetch rather than a one-time check, plus patching that continues after a module’s maintainer has moved on, delivered through a registry that speaks the same module proxy protocol your toolchain already expects. Before you lean on the post-EOL patching, confirm the documented versioning and checksum mechanism for patched Go modules so it can be built into the rollout.
Request a quote for SecureChain, or see how SecureChain compares to Chainguard.
FAQ
How do I change my Go module proxy?
Set the GOPROXY environment variable to the registry URL, using a comma before direct rather than a pipe. Running go env -w GOPROXY=… persists it on a developer machine. In CI, set it in the environment rather than in a base image.
Does switching Go module proxies break go.sum?
No, provided the registry serves the same module contents. Go’s module hash comes from file names and file contents rather than zip encoding details, so independently generated archives with the same file tree produce the same hash. Patched modules are the exception, since different content means a different hash by definition, and how that content gets versioned and authenticated depends on the registry’s patched-module delivery mechanism.
Can I keep the checksum database enabled?
Yes, and you should. GOSUMDB verification and registry screening answer different questions, and for upstream modules served as-is, the hashes agree by construction. Leave GOSUMDB=sum.golang.org enabled for those modules, and handle patched ones through whatever versioning and checksum mechanism your registry documents for them.
Do I need to change go.mod to use a different proxy?
No. go.mod records module paths and versions, and apart from any replace directives you have set, it has no say in where archives get fetched from. Proxy selection lives in environment configuration.
How can I verify the compatibility claim myself?
Clear the module cache with go clean -modcache, run go mod download through the new registry so Go re-fetches and authenticates everything against your existing checksums, then run go mod verify followed by your normal build or test suite. A clean pass means the modules you received match the hashes your project already trusted.
