Skip to main content
View Markdown ↗

Copy this page

Select and copy the Markdown below, then paste it into your LLM.

Support matrix

Pick where you build to see which SLSA and ALPS levels CI/lock reaches there today, which are planned, and which cannot be reached. A Supported result links to its setup guide. Every verdict is generated from a machine-checked model of SLSA v1.2 and ALPS, not written by hand, and pushgate.dev shows the same matrix.

  • Supported works in released CI/lock today; links to its setup guide
  • Planned tracked work; links to its entry below
  • Not planned the model refutes it; the reason is shown
  • 1 holds under a named reading of the spec (see Notes)

GitHub Actions

GitHub-hosted runner (Linux or macOS) 5 supported 1 planned 6 not planned

The best result across CI/lock modes. The mode is named under each result.

SLSA Source

  • L1 Not plannedSource sideThe source host issues no Source VSA or source provenance.
  • L2 Not plannedSource sideThe source host issues no Source VSA or source provenance.
  • L3 Not plannedSource sideThe source host issues no Source VSA or source provenance.
  • L4 Not plannedSource sideThe source host issues no Source VSA or source provenance.

ALPS

Results by CI/lock mode

Other CI

Kubernetes

Developer machines and agents

macOS with cilockd

Windows with cilockd

Source repositories

Full matrix: every environment, best result
EnvironmentSLSA BuildSLSA SourceALPS
SLSA Build L0SLSA Build L1SLSA Build L2SLSA Build L3SLSA Source L1SLSA Source L2SLSA Source L3SLSA Source L4ALPS 0ALPS 1ALPS 2ALPS 3
GitHub Actions
GitHub-hosted runner (Linux or macOS) (see note 1)
GitHub-hosted runner, signing in a reusable workflow (see note 1)
GitHub self-hosted runner (see notes 1,2)
GitHub-hosted runner (Windows) (see note 1)not evaluatednot evaluatednot evaluatednot evaluated
Other CI
GitLab.com hosted runners (see note 1)
GitLab self-managed
Buildkite hosted agents (see note 1)not evaluatednot evaluatednot evaluatednot evaluated
CircleCI cloud (see notes 1,2)not evaluatednot evaluatednot evaluatednot evaluated
Jenkinsnot evaluatednot evaluatednot evaluatednot evaluated
Azure DevOps Microsoft-hosted agentsnot evaluatednot evaluatednot evaluatednot evaluated
AWS CodeBuild (on-demand)not evaluatednot evaluatednot evaluatednot evaluated
Google Cloud Buildnot evaluatednot evaluatednot evaluatednot evaluated
Kubernetes
Kubernetes pod (EKS, GKE or AKS) (see notes 1,2,3)not evaluatednot evaluatednot evaluatednot evaluated
Kubernetes pod with a cilockd sidecarnot evaluatednot evaluatednot evaluatednot evaluated
Developer machines and agents
Pushgate (an agent pushes from a workstation)
Developer workstation (macOS or Linux)not evaluatednot evaluatednot evaluatednot evaluated
Linux workstation with a TPMnot evaluatednot evaluatednot evaluatednot evaluated
macOS with cilockd
macOS 27, Apple silicon, MDM-managednot evaluatednot evaluatednot evaluatednot evaluated
macOS 27, Apple silicon, unmanagednot evaluatednot evaluatednot evaluatednot evaluated
Intel Macnot evaluatednot evaluatednot evaluatednot evaluated
Windows with cilockd
Windows 11, TPM and Secure Boot, Intune-managednot evaluatednot evaluatednot evaluatednot evaluated
Windows 11, TPM and Secure Boot, unmanagednot evaluatednot evaluatednot evaluatednot evaluated
Windows Server 2025 on Azure Trusted Launch (self-hosted runner)not evaluatednot evaluatednot evaluatednot evaluated
Windows without a TPM, or with Secure Boot offnot evaluatednot evaluatednot evaluatednot evaluated
Source repositories
GitHub repository that only Pushgate can push tonot evaluatednot evaluatednot evaluatednot evaluatednot evaluatednot evaluatednot evaluatednot evaluated
GitHub repository that also accepts direct pushesnot evaluatednot evaluatednot evaluatednot evaluatednot evaluatednot evaluatednot evaluatednot evaluated

Planned work

Isolated provenance workflow
A reusable GitHub workflow signs the provenance in a job the build steps cannot reach. It is the separate-signer mode, which would bring SLSA Build L3 to GitHub Actions. The workflow and the L3 verifier are not merged yet, and the provenance format fix is open.
ALPS 2 boundary attestation
A trusted observer outside the agent records the sandbox that was applied, so a verifier can check it. Designed, not built.
cilockd on Linux
A signing daemon outside the build or agent, with a TPM-held key and a measured daemon identity.
cilockd on macOS
A signing daemon whose key is attested by Apple App Attest, through a helper app the agent cannot drive.
cilockd on Windows
A signing daemon whose key lives in a VBS enclave, with a TPM quote of the boot state.
Platform keyless signing beyond GitHub Actions
The platform certificate authority accepts GitHub Actions, GitLab.com, Buildkite and CircleCI workload identities. No guide documents platform keyless signing on GitLab.com, Buildkite or CircleCI yet, so ALPS 1 there is listed as planned until one does.
Pushgate Source VSA
Pushgate verifies every push it gates but does not yet issue a SLSA Source VSA for it. Designed, not built.

Notes

  1. Holds under interpretation I1: provenance that a CI/lock step writes on the build platform's own workers, signed with the job's workload identity, counts as generated by the control plane (SLSA Build L2, Authentic). GitHub publishes this reading for its own artifact attestations. Under the strict reading, no environment reaches Build L2 today.
  2. Holds under interpretation I2: the organization that operates self-hosted workers or a cluster is the build platform, and its build steps are the tenants.
  3. Rests on a property that no vendor document or code confirms: k8s_pod.issuer_uniform.

Not shown: the draft SLSA Build Environment and Dependency tracks. The Source track is evaluated only where CI/lock collects source-side evidence.

Generated from formal/slsa-tracks/matrix.json (sha256 be858e073977), a Lean 4 model of SLSA v1.2 (Build, Source) + working draft (BuildEnv, Dependency); ALPS 0.1. Each cell is a theorem. Supported cells were checked against shipped code on main at cbc65c7e41 on 2026-09-25.

How to read it

  • Best available shows, for each level, the best result across CI/lock's modes and names the mode. Pick a mode to see that mode alone.
  • Inline means CI/lock signs inside the build job or agent session it observes. Code in that job can use the same signing identity, which is enough for ALPS 1, and for SLSA Build L2 once cilock emits the SLSA v1 provenance type (it emits v1.0 today; that fix is tracked in the matrix above), and is why no inline result reaches Build L3 or ALPS 3. The separate-signer and cilockd modes move the signer out of the build's reach.
  • A level is a claim a verifier makes, not one CI/lock makes about itself. What proves a level lists the policy that checks each one.

Reference generated from the product documentation. Match commands and support details to your installed release.