Your Go binary runs in production. But can you prove it was built from the exact source you reviewed, on infrastructure you trust, without a single artifact swapped along the way? Most teams cannot. SLSA Level 3 changes that.
Why SLSA Level 3 Matters for Go
SLSA (Supply-chain Levels for Software Artifacts) Level 3 requires hardened builds, non-falsifiable provenance, and isolation between build steps. For Go projects, this means reproducible builds where go build yields identical binaries every time, provenance attestations signed by the build platform (not your CI keys), and verification gates before deployment.
The Go Reproducibility Baseline
Go 1.21+ enables reproducible builds by default when you control the module cache and build environment. Pin the toolchain, disable CGO, and fix timestamps.
Generating SLSA Provenance with GitHub Actions
The slsa-framework/slsa-github-generator action produces in-toto attestations signed by GitHub's OIDC identity, not a long-lived key you manage.
This emits myapp.intoto.jsonl containing the build definition, materials (Go modules, source commit), and a Sigstore bundle. The signature chains to GitHub's OIDC issuer, verifiable without secrets.
Verifying at Deploy Time
Policy engines like cosign and kyverno enforce provenance before admission.
Go Module Transparency with OSS Rebuild
Google's OSS Rebuild independently reproduces Go modules from source and publishes SLSA Level 3 provenance to the go.transparency.dev log. Your CI can cross-reference this log to detect compromised upstream modules before they enter your build.
Putting It All Together
1. Pin Go toolchain and enable reproducible flags in every workflow. 2. Run slsa-github-generator on every release tag. 3. Publish provenance alongside artifacts to your registry. 4. Enforce policy verification in staging and prod clusters. 5. Monitor OSS Rebuild logs for dependency anomalies.
"Provenance without verification is just metadata. Verification without policy is just noise.
— SLSA Working Group
✦
Start today: add the generator action to your next release workflow. The binary you ship tomorrow will carry proof it hasn't been tampered with — proof your incident response team will thank you for.









