← All posts
· 4 min read ·
CI/CDSecuritySLSAGitHub ActionsSupply Chain

SLSA Build Level 3 is Now Achievable Without a Platform Team

GitHub Artifact Attestations hit GA in January 2026 with SLSA Build Level 3 support. Here is a practical walkthrough of build provenance, SBOM attestation, and supply chain verification using only open-source tooling.

Security code and verification on dark background

For most of 2023 and 2024, implementing SLSA Build Level 3 required either a dedicated platform team with custom signing infrastructure or a commercial solution. As of January 2026, that changed: GitHub Artifact Attestations are generally available, Sigstore’s Rekor transparency log is the backend, and the whole thing works with one additional step in a standard GitHub Actions workflow.

This is worth understanding properly, not just adopting as a checkbox.

What SLSA Actually Guarantees

SLSA (Supply chain Levels for Software Artifacts) is a framework for supply chain integrity, not a product. The levels define provenance guarantees:

  • Level 1: A provenance document exists describing how the artifact was built.
  • Level 2: The provenance is authenticated - signed by the build platform, not the developer.
  • Level 3: The build platform itself is hardened. The build runs in an isolated, ephemeral environment. The provenance cannot be forged even by a developer with push access.

Level 3 is the meaningful bar. Levels 1 and 2 are achievable by anyone who can write to a README - the provenance document can claim anything. Level 3 requires that the signing key is held by the build platform (GitHub Actions, in this case) and the signed statement is written to an append-only transparency log (Rekor) that cannot be selectively edited.

The Workflow Change

Add attest-build-provenance after your build step:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write      # required for OIDC signing
      contents: read
      attestations: write  # required to publish attestation

    steps:
      - uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938

      - name: Build
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker save myapp:${{ github.sha }} > myapp.tar

      - name: Generate SLSA provenance
        uses: actions/attest-build-provenance@6149ea5740be74af77f260b9db67e633f6b0a9a1
        with:
          subject-path: myapp.tar

The action requests an OIDC token from GitHub’s identity service, uses it to sign a provenance statement containing the artifact digest, source repository, branch, workflow name, run ID, and trigger event, and publishes this signed bundle to Sigstore’s Rekor transparency log. The artifact hash and its provenance record are cryptographically linked.

Verification

Consuming teams verify before deployment:

gh attestation verify myapp.tar \
  --repo myorg/myapp \
  --signer-workflow build.yml

This checks that the artifact hash matches a provenance record in Rekor, that the record was signed by GitHub Actions’ OIDC issuer (not a developer key), and that the provenance claims match the expected repository and workflow. If any of these fail, the command exits non-zero and deployment should halt.

You can make this a gate in a separate deployment workflow:

- name: Verify provenance before deploy
  run: |
    gh attestation verify ${{ env.ARTIFACT_PATH }} \
      --repo ${{ github.repository }} \
      --signer-workflow .github/workflows/build.yml
  env:
    GH_TOKEN: ${{ github.token }}

SBOM Attestation

The same mechanism works for SBOMs. Generate a CycloneDX or SPDX document and attest it alongside the build:

- name: Generate SBOM
  uses: anchore/sbom-action@f325610c9f50a54015d37c8d16cb3b0e2c8f4de5
  with:
    artifact-name: sbom.spdx.json
    output-file: sbom.spdx.json

- name: Attest SBOM
  uses: actions/attest-sbom@bd218ee8dde1af2bf0b526795b1d43e01d02da2e
  with:
    subject-path: myapp.tar
    sbom-path: sbom.spdx.json

The SBOM attestation links the dependency manifest to the artifact. A downstream team asking “what went into this image and can I trust that list?” now has a cryptographically verifiable answer rather than a file someone might have edited.

Code-to-Cloud Traceability

The January 2026 GA announcement introduced two new record types that extend provenance beyond the build step:

Storage Records - where the artifact was published after build (container registry, S3, npm). The record links the build provenance to the artifact’s location in its registry.

Deployment Records - where the artifact is running, whether it is internet-exposed, whether it handles sensitive data. These records are queryable via the GitHub REST API, enabling questions like “is this vulnerable artifact currently deployed to production?”

Combined with GitHub’s new production-context vulnerability filters, you can now answer: “of all the open CVEs in my dependency tree, which ones are actually running in internet-exposed production services right now?” - rather than triaging a flat list of hundreds of findings.

The Forensic Use Case

The tj-actions supply chain attack in March 2025 illustrated the forensic value of build provenance. Artifacts built before the compromise window have valid Sigstore provenance signed by GitHub Actions. Artifacts built during the attack window either have no provenance or provenance signed by a credential that was demonstrably compromised at that timestamp.

Without provenance, a security team investigating the blast radius needs to reconstruct runner logs, diff package versions, and make probabilistic judgements. With provenance, gh attestation verify gives a definitive answer: this artifact was built cleanly, or it was not.

What Level 3 Still Does Not Prevent

SLSA Build Level 3 proves that the build process was clean given a specific source commit. It does not:

  • Prove that the source commit itself is trustworthy (that is SLSA Source Level 3, a separate and harder problem)
  • Detect malicious code injected via a compromised dependency (the SolarWinds vector)
  • Prevent a developer with repository write access from pushing malicious source

It narrows the attack surface significantly. The build platform cannot be impersonated. The provenance cannot be forged after the fact. For supply chain attacks that exploit the build environment itself (as opposed to the source), Level 3 is a genuine control.

For most organisations not currently doing any build provenance, going from zero to SLSA Level 2 via attest-build-provenance takes thirty minutes and a workflow change. That is the right starting point.

← All posts