DevSecOps
Go Build Cache Poisoning Risks
The Go build cache makes builds fast and reproducible, but a poisoned cache can reuse malicious compiled output indefinitely while the source looks clean.
Nov 28, 20247 min read
Deep dives, practical guides, and incident analyses from engineers who build Safeguard. No fluff, no vendor FUD — just what you need to ship secure software.
The Go build cache makes builds fast and reproducible, but a poisoned cache can reuse malicious compiled output indefinitely while the source looks clean.
go generate is a seam where arbitrary commands run with the full privileges of the developer, and it does not show up in any manifest of trusted dependencies.
The Go toolchain directive can automatically download and run a different compiler version than the one your developers installed, which is convenient, reproducible, and worth understanding as a supply chain surface.
go.sum and the Go checksum database are among the most rigorous integrity mechanisms in any language ecosystem, and the verification patterns around them deserve to be understood and used well.
Module hijacking in Go is rare compared to npm, but it does happen, and the patterns worth watching are different from what you might expect from other ecosystems.
Go workspaces make multi-module development feel natural, but the go.work file introduces a new trust boundary that can quietly override pinned versions and bypass checksum verification.
Go's build model makes SLSA provenance more tractable than most ecosystems. Here is the practical guide for producing and verifying provenance on Go releases.
The Go module graph is comparatively small, which makes it one of the few ecosystems where visualizing dependencies is actually useful for security review rather than just pretty.
Mixing public and private modules through a Go proxy is where most teams get their configuration wrong, and the mistakes range from leaked module names to accepted unverified code.
Weekly insights on software supply chain security, delivered to your inbox.