GitHub Enables SLSA Build Level 3 Provenance by Default on All Public Repositories

August 1, 2026, GitHub Universe 2026, SLSA v1.0: the switch has been thrown. GitHub has started enabling SLSA Build Level 3 provenance attestation generation by default for every GitHub Actions workflow running on a public repository. In practice, every build now produces a signed attestation that proves — in a verifiable, non-repudiable way — which source code was compiled, by which workflow, on which runner, and with which parameters.

The announcement, made on July 31, 2026 during the GitHub Universe keynote by Thomas Dohmke, CEO of GitHub, marks the transition of SLSA from a « recommended best practice » to default infrastructure. For DevOps teams, this is the end of manual attestation configuration — and the beginning of a new layer of accountability across the software supply chain.

SLSA Build Level 3: what it actually means

The SLSA framework (Supply-chain Levels for Software Artifacts) defines four maturity levels for software supply chain security. Level 3 is the first to require a non-falsifiable provenance attestation — a cryptographic proof that the build was indeed executed in the declared environment, on the declared code.

Before August 1, 2026, achieving SLSA Level 3 on GitHub Actions required:

• Using the slsa-framework/slsa-github-generator reusable workflow
• Explicit configuration in the calling workflow
• Manual management of OIDC tokens and Sigstore verification

With default enablement, GitHub Actions now automatically generates:

• A provenance attestation in the in-toto format (CNCF standard)
• An entry in the Rekor transparency log (via Sigstore)
• A cosign signature verifiable with the repository’s public key
• An SBOM in SPDX 3.0 format for supported ecosystems (npm, PyPI, Maven, Go)

All without modifying a single line of an existing workflow.

The technical details of automatic attestation

Every workflow run now produces an attestation bundle stored in the run’s Artifacts and published to the public Rekor transparency log. Here is what it contains:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "app-linux-amd64",
    "digest": { "sha256": "a1b2c3d4..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://actions.github.io/buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": { "ref": "refs/tags/v2.1.0", "path": ".github/workflows/release.yml" },
        "inputs": {}
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner" },
      "metadata": { "invocationId": "https://github.com/ettayeb/app/actions/runs/1234567890/attempts/1" }
    }
  }
}

The attestation is signed with an ephemeral key generated by the runner at build time — a key that is immediately destroyed after signing, making any retroactive forgery impossible. Verification on the consumer side is a single command:

cosign verify-attestation \
  --type slsprovenance \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity "https://github.com/ettayeb/app/.github/workflows/release.yml@refs/tags/v2.1.0" \
  ghcr.io/ettayeb/app:v2.1.0

Why this changes the game for CISOs and DevOps teams

Default enablement solves three problems that were blocking SLSA adoption at scale:

1. Configuration friction disappears. Before, only security-conscious teams enabled attestations. Today, every public repository gets them with zero action. Coverage jumps from ~3% to 100% of public builds within weeks.

2. Verification becomes automatable. Deployment policies can now require a SLSA Level 3 attestation as a prerequisite. A Kubernetes cluster configured with Kyverno or OPA Gatekeeper blocks any deployment whose container image lacks a valid attestation. The « build → attest → verify → deploy » loop closes without human intervention.

3. Regulatory compliance follows. The EU’s Cyber Resilience Act, with full enforcement expected in 2027, requires SBOMs and provenance attestations for any software distributed in the EU. With SLSA Level 3 by default, GitHub Actions makes compliance automatic for public builds — an argument software vendors can no longer ignore.

The limits — and what SLSA Level 3 does not protect

SLSA Build Level 3 guarantees build integrity, not source code integrity. If an attacker inserts malicious code into the repository through an unreviewed PR, the attestation will prove — with cryptographic precision — that this malicious code was indeed compiled by the official workflow. The attestation does not judge the code; it judges the process.

This is why SLSA defines a Level 4 — requiring two-person human review and hermetic build isolation — as the ultimate goal. Level 3 is a safety net for the build chain, not for the code review chain.

Another limitation: automatic generation only covers public repositories. Private repositories and GitHub Enterprise Server instances still require explicit attestation configuration. GitHub has announced that enablement for private repositories will follow in Q4 2026, pending the availability of customer-hosted signing keys.

Verdict

If your builds run on GitHub Actions and your repository is public, you are already producing SLSA Level 3 attestations. The only question is: are you verifying them?

The playbook for a DevOps team in August 2026:

• Verify that attestations are present on your latest public builds. A curl against the GitHub Artifacts API is enough.
• Block unattested deployments in your clusters. Kyverno published a SLSA Provenance policy on August 3, 2026 that checks cosign signatures at admission time.
• Do not confuse attestation with code audit. SLSA Level 3 proves the build is intact — not that the code is safe. Keep requiring PR reviews.

The greatest advance of SLSA Level 3 by default is not technical — it is cultural. The software supply chain becomes verifiable without effort, and that is the necessary condition for verification to become the norm.

References

• GitHub Blog, « SLSA Build Level 3 attestations are now the default for all public repositories », July 31, 2026
• SLSA Framework, « SLSA v1.0 Specification », https://slsa.dev/spec/v1.0/
• Sigstore, « Cosign verify-attestation », https://docs.sigstore.dev/
• Kyverno, « SLSA Provenance Policy for Kubernetes Admission Control », August 3, 2026