Google Quietly Broke Its Own Rules. Nobody Noticed Until Now.
In this article
Bottom line: Since Go 1.13 shipped in 2019, the default Go toolchain has routed every `go build` and `go get` for a public module through two Google-run services — proxy.golang.org and sum.golang.org — logging the exact import paths you're fetching.
The checksum database is a public, append-only transparency log, which means any internal codename, unreleased product, or acquisition target that ever slipped into a `go.mod` file is sitting there permanently, queryable by anyone.
A wave of renewed scraping of that log hit Hacker News this month, and it's forcing engineering teams to confront a default they installed years ago and never revisited.
The fix (`GOPRIVATE`, `GOSUMDB=off`) has existed the whole time — almost nobody at scale has set it.
I was pulling dependency graphs for a client's monorepo migration last week when one of their platform engineers asked me something that stopped me cold: "Wait, does Google know every package we've ever imported?"
I told him yes, probably, and that the answer had been yes since 2019. He didn't believe me until I pulled up sum.golang.org and searched for his own company's internal module prefix. It was there.
Every version. Every timestamp.
The Rule Google Wrote, Then Quietly Stopped Following
Here's the part that makes this sting.
Google is the company that tells the rest of the industry to practice data minimization — don't log what you don't need, don't retain what you can't justify, don't let internal system names leak into telemetry.
It's in their own SRE books.
It's in the SLSA supply-chain framework Google co-authored. It's the standard they hold vendors to during security reviews.
And yet the module proxy and checksum database that Google built directly into the `go` command — the tool millions of engineers run dozens of times a day without thinking about it — does exactly the thing that guidance warns against.
Every module path you fetch through the default `GOPROXY` setting gets logged on Google's infrastructure.
Every checksum lookup against the default `GOSUMDB` gets written into a Merkle-tree transparency log that, by design, never deletes anything.
Why is this surfacing again now, seven years after Go 1.13 shipped?
Because someone recently pointed a scraper at the public sum.golang.org log, pulled out every module path that looked like an internal company prefix rather than a real open-source project, and posted the results.
It's been near the top of Hacker News on and off for over a week. The comment sections read like a support group for people discovering their own mistakes at once.
What Engineers Actually Building With Go Are Saying
A senior platform engineer at a mid-sized fintech company, who asked not to be named because the conversation touched on an internal incident review, told me his team found four internal project codenames in the public log — including one tied to an acquisition that hadn't been announced yet at the time an engineer ran `go mod tidy` on a private fork.
Nobody had done anything malicious.
Someone just imported a private module path that happened to resolve as if it were public, and the toolchain did what it's configured to do by default: check the sum, log the path, move on.
"We had GOPRIVATE on the list of things to configure in the onboarding doc," he said. "It just never got prioritized, because nothing was visibly broken."
That's the pattern I kept hearing. A DevOps lead at a Series C logistics startup put it more bluntly: the Go toolchain's default behavior isn't a bug, it's an opt-out most teams never opt out of.
She'd assumed — reasonably, given how much Google talks about privacy-by-default in its own products — that a tool built and maintained by Google would ship privacy-conscious defaults for enterprise use.
Instead, the actual privacy controls (`GOPRIVATE`, `GONOSUMCHECK/GOSUMDB=off`, and `GONOPROXY/GOINSECURE`) exist, but they're something you have to know to go looking for.
Nothing in a fresh `go env` output nudges you toward them.
A security researcher who's spent the better part of a year cataloguing interesting strings in the sum.golang.org log gave me the most memorable framing: "It's not a leak in the traditional sense.
There's no breach, no CVE, no attacker. It's a company logging exactly what it says it wants everyone else to stop doing, and calling it infrastructure."
The Counter-Argument: This Was Disclosed the Whole Time
To be fair to Google here, none of this is secret, and framing it as newly "broken" rules overstates what happened. The privacy policy for the module mirror has been published since launch.
Russ Cox, who led the Go team's design of the module proxy and checksum database, wrote publicly in 2019 about exactly this tradeoff — that a public, auditable transparency log was the whole point, because it lets anyone verify that a module hasn't been tampered with after publication.
The `GOPRIVATE` and `GONOSUMCHECK` environment variables shipped in the same release specifically to let teams route private module paths around both services entirely.
One Go tooling maintainer I spoke with pushed back hard on the "Google broke its own rules" framing: "The rules were never 'nothing gets logged.' The rule was 'here's a public good — supply chain integrity — and here's an escape hatch if you have private paths.' People are discovering the escape hatch exists seven years late and calling it a scandal."
That's a fair point, and it's the real tension here. This isn't a cover-up. It's a defaults problem — the same category of problem that produces most real-world security incidents.
Nobody breached anything. A permissive default sat unexamined for years, and the cost of that default only became visible once someone bothered to go looking at scale.
What the Log Actually Shows
I spent an evening browsing entries myself, and the pattern is consistent with what other researchers have reported: alongside the enormous volume of legitimate open-source packages, there's a long tail of module paths that clearly weren't meant to be public — internal tool names, pre-announcement product codenames, and forked-and-renamed vendor packages that reveal which enterprise software a company runs internally.
None of this required exploiting anything. It required running `go mod tidy` without `GOPRIVATE` set, once, on a module path with a real-sounding domain prefix.
The checksum database's Merkle-tree design makes this specifically hard to undo.
Certificate transparency logs, which inspired the design, are append-only on purpose — that's what makes them trustworthy for verifying certificates weren't forged after issuance.
The same property that makes the log useful for supply-chain security also makes an accidental leak permanent.
There is no takedown request that removes an entry from a Merkle tree without breaking the tree.
What This Means If You Run Go in Production
If your org has ever imported a privately-named module without setting `GOPRIVATE`, assume the path is in the public log and treat it as already disclosed — rotating a codename after the fact does nothing.
The fix is genuinely five minutes of work: set `GOPRIVATE=
Most teams treat this as a `go.mod` hygiene issue.
It's actually a supply-chain configuration issue, and it belongs in the same onboarding checklist as SSH key setup, not buried in a wiki page nobody reads after week one.
If you're running your own module proxy — Athens, JFrog Artifactory, or a private GOPROXY — check whether it's still falling through to Google's sumdb for verification.
A lot of "private" proxy setups I've audited over the years still leak through the checksum lookup even after someone thought they'd locked it down.
Back to the Platform Engineer
The engineer who asked me the question that started all this ended up spending his afternoon setting `GOPRIVATE` across every CI pipeline his team owns, then quietly opening a ticket to ask legal whether the acquisition codename sitting in a public transparency log since 2023 needed to go in an incident report.
It probably does.
He didn't seem angry about it, exactly.
Mostly just tired — the specific tiredness of realizing a default you inherited three jobs ago has been quietly working against you the entire time, in public, for anyone who thought to look.
Have you actually checked what your build tooling logs by default, or is it still sitting on whatever the installer picked for you?
