Verified Builds: SLSA Provenance and Sigstore Signing

A signed artifact proves who built it. A provenance attestation proves how. The two are different documents solving different halves of the same problem, and shipping one without the other leaves a gap large enough to drive a supply chain attack through.

The pattern will look familiar if you have implemented sender authentication: a certificate chain, a published verification key, a policy at the receiving end, and a set of failure modes that produce no error at all. Software supply chain attestation is the same architecture applied to build systems.

The two documents

Sigstore signs. Cosign produces a signature over an artifact, bound to an identity rather than to a long-lived private key. The identity comes from an OIDC token, typically the workflow identity of your CI job, and the ephemeral certificate is logged to a public transparency log. The claim is: this artifact was signed by this identity at this time.

SLSA describes. A SLSA provenance attestation is a signed statement, in the in-toto format, recording what built the artifact: the source repository and commit, the build platform, the entrypoint, and the parameters. The claim is: this artifact came from this source through this build.

You need both. A signature without provenance tells you a trusted identity vouched for a binary but not what went into it. Provenance without a signature is an unauthenticated text file.

The most common half-implementation is signing container images and calling it supply chain security. An attacker who compromises the build pipeline gets their artifact signed by your legitimate workflow identity. The signature is valid. It was always going to be valid. Provenance is what makes the compromise visible, and only if someone verifies it.

The SLSA levels, honestly

SLSA v1.0 defines Build levels 0 through 3. The numbering invites treating them as a maturity ladder to climb, and in practice the distance between them is very uneven.

Build L1 to L2 on a hosted runner is close to free. GitHub Actions artifact attestations and the SLSA generator reusable workflows both produce signed provenance from a few lines of YAML. That is the step almost every team should take this quarter.

Build L3 requires the platform itself to guarantee that a build cannot forge its own provenance, which means isolated, ephemeral build environments with signing keys the build steps cannot reach. If you run your own Jenkins, this is a project. If you use a hosted platform that implements it, it is a checkbox.

Step 1: Generate provenance in CI

Add attestation generation to your build workflow. On GitHub Actions, the artifact attestation action produces a signed in-toto statement bound to the workflow identity, published to the transparency log, and stored with the artifact.

The output records the repository, the commit SHA, the workflow file, and the trigger. That is the material you will later write policy against.

Step 2: Sign the artifact

Keyless signing with cosign, using the same workflow identity. No key to store, rotate, or leak, which removes the failure mode that killed most previous signing initiatives: nobody wanted to own the private key.

For container images, the signature and the attestation both live alongside the image in the registry, addressed by digest.

Step 3: Address by digest, never by tag

This step is short and it is the one that decides whether any of the rest matters.

A tag is a mutable pointer. Verifying a signature on myapp:latest verifies whatever latest points to at that instant, and an attacker with registry write access moves the pointer. Every verification step, every deployment manifest, and every policy rule must reference myapp@sha256:....

Step 4: Verify at admission, not at build

Verification that happens in the pipeline that produced the artifact proves nothing. The check has to run at the point of consumption: an admission controller in your cluster, a gate in the deployment step, or a policy engine in front of the registry.

Write the policy against the attestation contents, not just the signature validity:

• The signing identity is a workflow in a repository you own.
• The source repository matches an allowlist.
• The build was triggered from a protected branch or a tag, not an arbitrary pull request.
• The builder is the platform you expect.

A policy that only checks "is there a valid signature" accepts anything signed by anyone in the transparency log, which is everyone.

Step 5: Decide what happens on failure

Unlike agent verification, this one should fail closed in production, and that decision has to be made deliberately with a documented break-glass path. Teams that enable enforcement without a bypass procedure discover the gap during an incident, at the worst possible moment.

Run in audit mode first. Log every artifact that would have been rejected. Fix them. Then enforce.

The failure modes

The last row deserves attention. Verification tooling that degrades to "allow" when it cannot reach the log has the same property as an SPF permerror: a network problem becomes a security bypass, invisibly.

Where the boundary sits

Attestation covers artifacts you build. It says nothing about the dependencies you pulled in, which is the more common attack path. An SBOM inventories what is inside; provenance records how the outside was assembled. Neither substitutes for the other, and a team that has SLSA L3 on its own builds while pulling unpinned transitive dependencies has secured the wrong end.

Should you do it?

You ship containers or packages to customers

Yes. Get to Build L2 with signed provenance this quarter, then implement admission verification with a real policy. The generation half is a day of work. The verification half is the project.

You deploy only internally

Do the generation anyway, because it is nearly free on hosted CI and it turns incident forensics from archaeology into a query. Defer admission enforcement until you have an audit-mode baseline.

You are chasing a compliance requirement

Be precise about which level the requirement names, and be honest about whether it applies to your builds or to your inputs. Most procurement questionnaires ask about the former while the risk lives in the latter.

You self-host your build system

Build L3 is a genuine engineering program for you. Reaching L1 and L2 first is still worth doing and does not commit you to it.