Where SLSA fits
The previous section described rung 3 of the verification spectrum — reproducible OS and firmware — as largely out of reach on cloud infrastructure today. Cloud providers control the firmware and most don't publish reproducible builds of it.
So how do you get meaningful guarantees about what's running without rebuilding OVMF from source?
SLSA (Supply-chain Levels for Software Artifacts) is the practical answer for the application layer. It doesn't solve firmware verification. It doesn't touch the OS. But it locks the one layer you do control — your application — in a way that hardware attestation can then anchor to a root of trust.
What SLSA actually is
SLSA is a framework for proving provenance: where a software artifact came from, how it was built, and what went into it. At its core is a signed provenance document that records:
- The source repository and commit that triggered the build
- The build environment (platform, runner, tool versions)
- The exact dependencies used (checksums, not just version names)
- The hash of the output artifact
Anyone with the provenance document and the artifact can verify the hash matches and trace the artifact back to specific source code. At higher SLSA levels, the build environment itself is hardened — no single person can tamper with a build, and the provenance is generated by the build platform, not the developer.
What SLSA leaves open
SLSA proves the application. It says nothing below that line.
| Layer | SLSA covers it? |
|---|---|
| Your application binary | Yes — hash, source, dependencies |
| Your OS kernel and init system | No |
| UEFI / OVMF firmware | No |
| Paravisor / hypervisor | No |
| CPU / TDX module | No |
This is not a limitation unique to SLSA — it's an inherent property of any supply chain framework that operates at the software level. The layers below the application require either reproducible builds (hardware-intensive) or vendor endorsements (trust delegation).
A valid SLSA provenance document tells you the application binary is what the source says it is. It tells you nothing about the environment that binary runs in. Pair it with hardware attestation to cover both.
Combining SLSA with hardware attestation
This is where it gets useful. Hardware attestation gives you a signed measurement of the entire boot chain. SLSA gives you a signed record of what the application binary is. The two complement each other cleanly:
- Attestation proves that something ran on genuine TEE hardware with these measurements
- SLSA provenance proves that the application binary in those measurements traces to specific reviewed source
To bind them together, hash the provenance document and include that hash in the attestation quote's report_data field. The Intel PCK certificate chain then proves that hash was bound to a genuine TDX measurement — on that specific hardware, at that specific moment.
application source code
→ build (SLSA-compliant, hardened environment)
→ binary + provenance.json
→ SHA-256(provenance.json)
→ placed in report_data when requesting TDX quote
→ quote signed by Intel attestation key
→ verified via Intel PCK certificate chain
A verifier who receives the quote, the binary, and the provenance document can independently confirm the entire chain: genuine hardware → known measurements → specific application build → specific source. This is a strong guarantee that doesn't require firmware reproducibility.
When generating your attestation quote, always bind something meaningful into report_data — a hash of your provenance document, a public key, a nonce. A quote with empty or zero report_data is structurally valid but semantically empty: it proves the TEE is genuine but binds nothing about your application. This failure mode is subtle and easy to miss — the quote verifies successfully, but the application binding is absent.
SLSA levels in a CoCo deployment
| Level | What you get | What it requires |
|---|---|---|
| SLSA 1 | Provenance exists and is machine-readable | Any CI system generating a provenance document |
| SLSA 2 | Provenance is signed by the build service | A signing step in CI (e.g., Sigstore/cosign) |
| SLSA 3 | Build environment is hardened; provenance is unforgeable | Isolated build runners, no developer access to build infrastructure |
| SLSA 4 (deprecated, now track-based) | Two-party review, hermetic builds | Strict process controls, reproducible builds preferred |
For most CoCo deployments, SLSA 2 or 3 is the realistic target. SLSA 3 matters most when the application handles sensitive data and the build pipeline is itself a potential attack surface. At SLSA 3, an attacker who compromises a developer's machine cannot inject a backdoor into a shipped artifact — they'd have to compromise the build platform itself.
The honest scope
SLSA at any level does not:
- Verify the OS the application runs on
- Verify the firmware or paravisor
- Replace hardware attestation
- Prevent runtime tampering after the application starts
Used correctly — SLSA for application provenance, hardware attestation for boot chain integrity, measurement pinning to connect the two — it closes the application-layer gap that would otherwise require full firmware reproducibility to address.