Technical Deep Dive
The slsa-github-generator is architecturally a set of composite GitHub Actions that wrap the build process. At its core, it uses three main actions: `generate-builder`, `generate-attestations`, and `sign-attestations`. The `generate-builder` action creates a unique builder identity tied to the specific GitHub Actions workflow run, including the repository, commit SHA, and workflow file path. This identity is then used by `generate-attestations` to produce an in-toto attestation in the form of a DSSE (Dead Simple Signing Envelope) payload.
The signing mechanism leverages Sigstore's Fulcio certificate authority for keyless signing. Instead of managing long-lived signing keys, the generator requests a short-lived certificate from Fulcio, which is bound to the GitHub Actions OIDC token. This token proves the builder's identity to Fulcio, which then issues a certificate that chains back to the Sigstore root of trust. The signed attestation is then uploaded to Rekor, Sigstore's transparency log, creating a public, immutable record.
From an engineering perspective, the generator enforces SLSA Level 3 requirements by ensuring the build is ephemeral and isolated. Each build runs in a fresh GitHub Actions runner, and the generator verifies that the build script is defined in the source repository, not injected at runtime. However, it does not enforce hermetic builds (no network access) — that remains the responsibility of the workflow author.
A key technical detail is the use of the `actions/attest` action under the hood, which was recently made generally available by GitHub. This action handles the attestation generation and signing, but the SLSA generator adds an extra layer of validation and structure specific to the SLSA specification.
Performance and overhead: Adding provenance generation adds approximately 30-60 seconds to a typical build workflow, mostly due to the Sigstore signing and transparency log upload. For most CI/CD pipelines, this is an acceptable trade-off.
Data table: SLSA Generator vs. Manual Provenance Generation
| Aspect | SLSA GitHub Generator | Manual Sigstore + in-toto |
|---|---|---|
| Setup time | ~10 minutes (add action to workflow) | 2-4 hours (write custom scripts, manage certificates) |
| SLSA Level achieved | L3 (with hermetic build) | L1-L3 depending on implementation |
| Key management | None (keyless via OIDC) | Requires key rotation, secure storage |
| Transparency log | Automatic (Rekor) | Must be configured manually |
| Verification complexity | Low (one command) | Medium (multiple tools) |
| GitHub-specific coupling | High (only GitHub Actions) | Low (works with any CI) |
Data Takeaway: The SLSA generator dramatically reduces the barrier to entry for SLSA compliance, but at the cost of platform lock-in. Organizations with multi-cloud CI strategies may prefer manual approaches despite the higher setup effort.
Key Players & Case Studies
The primary maintainer of the slsa-github-generator is the SLSA project itself, which is hosted by the OpenSSF (Open Source Security Foundation). Key contributors include individuals from Google, Chainguard, and GitHub. Notably, Chainguard's team has been instrumental in implementing the Sigstore integration, as Chainguard's own product (Chainguard Enforce) uses similar attestation mechanisms.
Google has been a major driver behind SLSA, having developed the framework internally before open-sourcing it. The company uses similar provenance generation for its own internal builds and for Google Cloud's artifact registry.
Case study: Sigstore adoption
Sigstore, the underlying signing infrastructure, has seen rapid adoption. As of early 2025, over 10 million signatures have been recorded in the Rekor transparency log. The npm registry now uses Sigstore to sign all packages published to the public registry, a move that was enabled by the same OIDC-based keyless signing the SLSA generator uses.
Comparison table: Provenance generation tools
| Tool | Platform Support | SLSA Level | Key Management | Transparency Log |
|---|---|---|---|---|
| slsa-github-generator | GitHub Actions only | L3 (with hermetic) | Keyless (Sigstore) | Rekor (automatic) |
| in-toto attestations | Any CI | L1-L4 | Manual or Sigstore | Optional |
| Tekton Chains | Tekton CI | L3 | Keyless (Sigstore) | Rekor (automatic) |
| Witness (by in-toto) | Any CI | L2-L3 | Keyless or key-based | Optional |
| Docker Content Trust | Docker builds | L1 | Manual keys | No |
Data Takeaway: The SLSA generator is the most opinionated and easiest-to-use tool for GitHub users, but Tekton Chains offers similar functionality for Kubernetes-native CI environments. Witness provides more flexibility but requires more configuration.
Industry Impact & Market Dynamics
The rise of supply chain attacks has made provenance generation a critical requirement for enterprise software procurement. The US Executive Order on Cybersecurity and the EU Cyber Resilience Act both mandate software bill of materials (SBOM) and provenance for government software. This regulatory pressure is driving adoption of tools like the SLSA generator.
Market growth: The software supply chain security market was valued at approximately $4.5 billion in 2024 and is projected to grow to $12 billion by 2028, according to industry estimates. Provenance generation tools represent a small but fast-growing segment of this market.
Adoption curve: As of May 2025, the slsa-github-generator repository has over 574 stars and is used by several prominent open-source projects, including the Kubernetes release process, the Sigstore project itself, and various Google-maintained libraries. However, adoption among enterprise private repositories is harder to measure.
Data table: Supply chain attack trends
| Year | Number of reported supply chain attacks | Average cost per incident (USD) |
|---|---|---|
| 2021 | 150 | $1.2M |
| 2022 | 220 | $1.8M |
| 2023 | 310 | $2.5M |
| 2024 | 450 (estimated) | $3.1M |
Data Takeaway: The frequency and cost of supply chain attacks are accelerating, creating strong tailwinds for provenance tools. However, the market is still fragmented, and no single tool has achieved dominant market share.
Risks, Limitations & Open Questions
The most obvious limitation is the GitHub-only dependency. Organizations using GitLab CI, Jenkins, or CircleCI cannot use this generator directly. While the SLSA framework is platform-agnostic, the generator's tight integration with GitHub Actions OIDC tokens means porting it to other platforms would require significant re-engineering.
Another risk is the reliance on Sigstore's infrastructure. If Sigstore's Fulcio or Rekor services experience downtime, attestation generation and verification could be blocked. While Sigstore has a high uptime record, it is a centralized point of failure. The project is working on federation and offline verification modes, but these are not yet mature.
Hermetic builds: The generator does not enforce hermetic builds. A workflow can still make network calls during the build, which could introduce dependencies that are not captured in the provenance. This means a determined attacker could still inject malicious code if they can compromise a network dependency. The generator only attests to what was in the source repository and the builder identity, not the full dependency tree.
Verification gap: While the generator produces attestations, the ecosystem for verifying them is still nascent. Tools like `slsa-verifier` exist, but they are not yet integrated into common package managers or deployment tools. Without widespread verification, the attestations provide limited security benefit.
Open question: Will the industry converge on a single attestation format? Currently, in-toto, SLSA, and SPDX all have overlapping but different schemas. The SLSA generator produces in-toto attestations, but some consumers expect SPDX SBOMs. Interoperability remains a challenge.
AINews Verdict & Predictions
The slsa-github-generator is a well-engineered tool that solves a real problem: making SLSA compliance accessible to the average developer. Its keyless signing approach eliminates the most common friction point in cryptographic signing — key management. For organizations already on GitHub, it is the most practical path to achieving SLSA Level 3.
Prediction 1: Within 18 months, GitHub will natively integrate provenance generation into its Actions platform, making the SLSA generator obsolete for most use cases. The `actions/attest` action is a step in this direction.
Prediction 2: The lack of multi-platform support will become a critical bottleneck. We predict the SLSA project will release a platform-agnostic generator using the in-toto attestation format that works with any CI system, possibly by abstracting the OIDC token exchange into a plugin architecture.
Prediction 3: Verification tooling will catch up faster than expected. By 2026, major package registries (npm, PyPI, Maven Central) will require SLSA attestations for all new packages, driving adoption of the generator and similar tools.
What to watch: The next major release of the generator should include support for generating attestations for container images (OCI artifacts), which currently requires separate tooling. Also watch for integration with GitHub's Dependabot to automatically verify attestations of dependencies.
Editorial judgment: The SLSA generator is a necessary but insufficient step. It makes provenance generation easy, but the harder problem of verification and policy enforcement remains unsolved. Organizations should adopt it now to build the habit of attestation, but they must also invest in verification infrastructure to realize the security benefits.