Trusting the Pipeline: Go Modules, Provenance, and SLSA 3
Recent high-profile incidents, from SolarWinds to Log4j, have made one thing painfully clear: the code you pull from a repository may not be the code a developer wrote. A malicious actor can tamper with artifacts at any point in the build or distribution chain. GitHub has been shipping dependency vulnerability alerts since 2017, but these attacks exploit a structural weakness—the lack of verifiable proof that a published artifact accurately reflects a specific source commit.
To close that gap, GitHub and the OpenSSF have partnered on tooling that makes build provenance practical for Go projects. The new approach combines GitHub Actions' native identity system with Sigstore's signing infrastructure. This not only authenticates who published a module, but also cryptographically links it to the exact repository, commit, and workflow that produced it. For teams aiming for SLSA Level 3 compliance, this automation handles the heavy lifting without requiring you to manage your own signing keys.
The Sigstore Toolchain Decoded
Sigstore is not a single tool but a trio of projects that work together to create and verify signed metadata:
- Cosign handles the actual signing of software artifacts.
- Fulcio is a certificate authority that issues short-lived certificates based on OpenID Connect (OIDC) tokens.
- Rekor acts as a public, transparent log that records signing events for later verification.
This stack supports the Supply-chain Levels for Software Artifacts (SLSA) framework, an end-to-end integrity model shaped by NIST's software development guidance. SLSA defines "provenance" as metadata about a build's origins: where it ran, who triggered it, and which source code was used. For consumers, that metadata becomes the basis for risk decisions about what they install and run.
How Pieces Fit Together
The key to this system is a reusable GitHub Actions workflow for Go modules. Each Action run executes on an isolated virtual machine, and that isolation is critical. The workflow requests an OIDC token that encodes run-specific details—not just the repository and commit, but also the precise workflow definition that generated the build.
Cosign takes that OIDC token and exchanges it with Fulcio for a short-lived certificate, eliminating the need for you to maintain long-term signing keys. It then signs the build and writes a record to the public Rekor transparency log. This record is what allows anyone—whether an internal deployment team or an external auditor—to verify both the artifact's signature and its build provenance.
This automated flow has a practical benefit for open-source maintainers: signing and provenance generation happen as part of the normal build process, with no extra infrastructure to operate. If your organization maintains private modules and doesn't want build details in a public log, you can substitute your own signing key so that all records stay internal.
A Model for Modern Builds
What makes this workflow significant is not just the Go support it adds, but what it represents. The combination of GitHub Actions and Sigstore offers a replicable blueprint for other package ecosystems. Any build system that can produce an OIDC-tied provenance claim can demonstrate integrity in a way that meets current NIST guidance and emerging SLSA requirements.
Getting Started with Verifiable Provenance
- Steps for implementing the reusable Go workflow are documented in the
slsa-github-generator-gorepository. - The pipeline generates provenance metadata in a standard format, viewable in a documented example.
- Consumers can verify that metadata by querying the Rekor transparency log with straightforward CLI commands.
The workflow is immediately available from the Actions tab of any GitHub repository, making supply-chain verification accessible to projects that previously lacked the resources to set up and maintain a signing infrastructure of their own.
