SLSA Build Levels

What Are SLSA Build Levels?

SLSA — Supply-chain Levels for Software Artifacts — is a framework for describing how trustworthy the process that produced an artifact is. Its Build Levels run from L0 to L3, each adding guarantees about what an attacker could not have done to the build.

The distinction SLSA exists to make is between knowing who published something and knowing how it was made. A signature establishes publisher identity. It says nothing about whether the build that produced the artifact could have been tampered with, which is precisely the gap modern supply chain attacks exploit.

Because the levels are defined publicly and uniformly, they let a buyer compare two suppliers' claims without taking either at face value.

How the Build Levels Differ

The levels are defined at slsa.dev. Each is cumulative, and each rules out a specific class of attack:

• Build L0 — no guarantees. Provenance may not exist at all.
• Build L1 — the build process is documented and provenance is generated, though not verified. Rules out accidental misattribution and undocumented builds.
• Build L2 — the build runs on a hosted platform that signs provenance. Rules out a developer forging provenance from a workstation.
• Build L3 — the build platform is tamper-resistant: builds are isolated from one another, provenance is non-falsifiable, and secrets are unavailable to build steps. Rules out one build influencing another, and an insider forging provenance.

The step that carries the most weight commercially is L2 to L3. At L2 you are trusting that a platform was used correctly; at L3 the platform itself prevents the attack.

What SLSA Levels Do and Do Not Tell a Buyer

SLSA describes build integrity. It is routinely over-read as a statement about the software itself, which it is not.

What a level does and does not establish:

• It does establish that the artifact came from the stated source, built by the stated builder.
• It does establish that the provenance record cannot easily be forged at L3.
• It does not establish that the source code is free of vulnerabilities.
• It does not establish that dependencies pulled into the build were themselves trustworthy.

A SLSA L3 artifact built from vulnerable source is a trustworthy record of an untrustworthy input. The level is about the chain of custody, not the cargo.

How to Verify SLSA Provenance in Production Environments

Provenance is only useful if something checks it. Practical steps:

• Require provenance as a signed attestation attached to the artifact, not a claim on a web page.
• Verify at admission, so an image failing policy never reaches a cluster rather than being flagged afterwards.
• Pin the expected builder identity in policy, since provenance that merely exists proves far less than provenance naming the builder you expect.
• Check the source repository and ref in the attestation match what you believe you are deploying.
• Record the verification result so an assessor can see the check ran, not just that the capability exists.

How Hardened Container Images Use SLSA

For an image provider, the build level is one of the few claims a customer can independently verify, which is why it appears in procurement conversations rather than only in engineering ones.

Echo states that its images are built on controlled build infrastructure at SLSA L3 and ship signed and attested, with an SBOM, provenance data and VEX delivered alongside (echo.ai/product).

As with any supplier claim, the attestation rather than the statement is the thing to check — a level asserted in marketing copy and a level evidenced in a verifiable attestation are different artifacts. The broader argument for verifying rather than trusting is in zero trust software supply chain.

FAQs

What is the practical difference between SLSA L2 and L3?

At L2, provenance is generated and signed by a hosted build platform, which stops a developer fabricating it locally. At L3 the platform itself is hardened: builds are isolated, secrets are unreachable from build steps, and provenance cannot be falsified even by someone with access to the build system. L3 removes insider forgery.

Does SLSA L3 mean the software has no vulnerabilities?

No, and conflating the two is a common mistake. SLSA describes the integrity of the build process — where the artifact came from and whether that record can be trusted. It says nothing about whether the source code or its dependencies contain vulnerabilities. A tamper-proof build of vulnerable software is still vulnerable software.

How do we verify a vendor's SLSA claim?

Ask for the provenance attestation for a specific image, not a statement of policy. Verify its signature, check that the builder identity matches the one the vendor names, and confirm the source repository and reference are what you expect. If a vendor cannot supply a verifiable attestation on request, treat the claim as unevidenced.

Where should provenance verification happen?

At admission, so a non-compliant artifact never reaches a running cluster. Verifying at build time catches your own mistakes; verifying at deployment catches everything, including artifacts that entered through a path you did not anticipate. Many organisations do both, with admission control as the enforcement point.

Is SLSA a certification?

No. There is no central body that awards a SLSA level, which is why the framework is useful rather than bureaucratic. A producer states the level their build process achieves and supplies provenance supporting it; a consumer verifies that provenance. The guarantee comes from the verifiable artifact, not from an authority's endorsement.