SLSA + Sigstore: Software Supply Chain Security Architecture (2026)

In late 2020, attackers slipped a backdoor into a build server and shipped it to eighteen thousand organizations through a signed, trusted update. The code was legitimately signed. The vendor’s key was never stolen. The compromise happened between the source and the signature, inside the build itself. That is the gap software supply chain security exists to close, and it is why signing an artifact is no longer enough on its own.

The problem has only sharpened since. Dependency-confusion uploads, typosquatted packages, and poisoned transitive dependencies now arrive faster than any human review can catch them. A signature proves who released a binary. It says nothing about whether the build that produced it was clean.

This is where SLSA and Sigstore fit together. SLSA gives you verifiable evidence of how an artifact was built. Sigstore gives you a practical, keyless way to sign and prove that evidence. Together they form a chain you can verify automatically at deploy time.

What this covers: the threat model, the SLSA build levels, in-toto attestations, keyless signing with Fulcio and Rekor, cosign verification, and enforcing all of it in CI/CD and Kubernetes admission control.

Context and Background

The modern attack surface is not your code. It is everything your code depends on and everything that touches it on the way to production. A single service pulls hundreds of transitive dependencies, runs through a shared build platform, and lands in a registry that dozens of clusters trust implicitly.

Three attack classes dominate. The first is build tampering, the SolarWinds pattern, where the compromise happens inside a trusted build system and rides out on a valid signature. The second is dependency substitution: typosquatting a popular package name, or dependency confusion, where an attacker publishes a higher-versioned internal package name to a public registry that your resolver checks first. The third is direct compromise of a maintainer account or a leaked signing key.

Traditional signing addresses only the last mile. If you sign a binary with a long-lived private key, you have proven that whoever holds that key released it. You have not proven the build was reproducible, isolated, or free of injected steps. Worse, long-lived keys are themselves a liability. They sit in CI secrets, leak into logs, and outlive the people who created them.

The industry response splits the problem into two verifiable claims. Provenance answers “how was this built and from what source.” A signature answers “has this exact artifact been modified since.” You need both. Provenance without a signature can be forged; a signature without provenance tells you nothing about build integrity. SLSA standardizes the provenance claim. Sigstore makes the signature claim cheap and keyless.

Why did this become urgent now rather than a decade ago? Three forces converged. Regulatory pressure, notably the US executive order on cybersecurity and its downstream NIST guidance, made supply-chain evidence a procurement requirement rather than a nice-to-have. The explosion of open-source dependencies pushed the attack surface far outside any single organization’s control. And the tooling finally matured: signing an artifact used to demand a hardware security module and a key ceremony, and now it is a single command that leaves no secret behind. When the cost of proof drops to near zero, proof stops being optional.

It also helps to name what these controls do not do. They are detective and preventive, not curative. Provenance and signatures let a verifier refuse a bad artifact; they do not scan for vulnerabilities or fix insecure code. They sit alongside dependency scanning, reproducible builds, and least-privilege CI credentials as one layer in a defense-in-depth posture. Treating them as a silver bullet is a mistake; treating them as a foundational, machine-checkable layer is exactly right.

This pairing also complements, rather than replaces, the software bill of materials. An SBOM enumerates what is inside an artifact. Provenance describes how it came to be. If you are still building out that inventory layer, our companion guide on SBOM architecture and formats covers the SPDX and CycloneDX side in depth. For the framework itself, the canonical source is the SLSA specification at slsa.dev.

The reason this layered approach has become the accepted baseline for software supply chain security is that no single control ever stopped these attacks. Scanners miss zero-days. Code review misses obfuscated payloads. Signatures alone missed SolarWinds. What changed is the shift from trusting actors to verifying evidence. Instead of asking “do we trust this vendor,” a verifier asks “can this artifact prove, cryptographically, how and where it was built, and that it has not changed since.” That reframing is the whole game.

The SLSA + Sigstore Reference Architecture

The reference architecture for software supply chain security is a pipeline of verifiable claims: a hardened build produces an artifact plus an in-toto provenance attestation, Sigstore signs that attestation with a short-lived certificate issued from an OIDC identity, the signature is recorded in a public transparency log, and a policy engine at deploy time refuses anything whose provenance and signature do not verify against expected identities. Every step emits evidence, and every consumer checks it.

Figure 1: End-to-end software supply chain security chain from signed source commits through a hardened SLSA build, in-toto provenance generation, keyless signing via Fulcio, transparency logging in Rekor, publication to an OCI registry, and a verification and admission gate before deployment to the cluster. Each arrow carries a verifiable claim that the next stage can independently check.

Read the chain left to right. Source commits are signed and pushed. A build platform runs in a hardened, isolated environment and produces both the artifact and a provenance document describing exactly how it did so. That provenance is signed using a certificate Fulcio issues against the build’s OIDC identity. The signature and certificate are logged to Rekor, the transparency log. The artifact and its attestations are pushed to an OCI registry. At deploy time, a verifier pulls the artifact by digest, fetches the attestations, checks the signer identity and the Rekor inclusion proof, and only then does an admission gate allow the workload into the cluster.

The elegance is that trust is never assumed. It is re-derived at each boundary from cryptographic evidence. A stolen registry credential cannot forge provenance. A tampered build cannot produce provenance that names an unexpected builder identity without the verification step catching it.

One detail carries disproportionate weight: everything is bound by content digest, not by name or tag. A tag like latest or v2.1 is mutable; anyone with registry write access can repoint it. A sha256 digest is the artifact’s fingerprint, and it changes if a single byte changes. Provenance names its subject by digest, signatures cover the digest, and verification pulls by digest. This is what makes the chain tamper-evident end to end rather than merely tamper-resistant. If you take one operational habit from this architecture, make it deploying by digest.

SLSA build levels and what each guarantees

SLSA, Supply-chain Levels for Software Artifacts, reached its stable v1.0 milestone and its build track has remained the backbone through subsequent point releases. The build track defines three ascending levels, each raising the bar on how trustworthy the provenance is.

Build L1 means provenance simply exists. The build process emits a provenance document naming the builder, the source repository, and the output artifact’s digest. There is no requirement that the build platform be trustworthy or that the provenance be signed. L1 is about visibility, not tamper resistance. It gives you a paper trail and catches accidental misconfiguration.

Build L2 requires that the build run on a hosted build platform that generates and signs the provenance. The signature means the provenance came from the platform, not from a developer laptop, and that it has not been altered in transit. L2 defeats casual forgery. An attacker can no longer hand-write a provenance file claiming a clean build.

Build L3 is the hardened tier. The build platform must provide strong isolation between builds, and the signing material used to sign provenance must be inaccessible to user-defined build steps. This is the level that would have mattered for SolarWinds-class attacks. Even if an attacker injects a malicious step, they cannot forge provenance that hides it, because the signing key lives outside their reach and the provenance faithfully records what ran.

It is worth understanding what the levels deliberately leave out. The SLSA build track says nothing about the security of your source code review process, your dependency hygiene, or whether your tests are any good. Earlier drafts of SLSA sketched source and dependency tracks, but the stable specification scoped its guarantees tightly to the build. That focus is a feature, not a gap: it lets the levels be precise and machine-verifiable. Do not read “we are Build L3” as “we are secure.” Read it as “our build integrity is strong, and we still need the rest of the program.”

Figure 4: The SLSA build-level progression. An artifact with no provenance is unverifiable; Build L1 means provenance exists and the build steps are documented; Build L2 adds a signature that proves the origin came from a hosted platform; and Build L3 adds a hardened, isolated build with unreachable signing keys, yielding non-falsifiable provenance. Each rung defends against a strictly larger class of attack than the one below it.

Keyless signing with Fulcio and Rekor

Sigstore’s central insight is that long-lived signing keys are the weakest link, so it removes them. Instead of a key you store and protect, keyless signing issues a certificate that lives for only a few minutes, tied to a verified identity rather than to a secret you keep.

The flow works like this. Your CI workflow obtains an OpenID Connect identity token from its provider, GitHub Actions or a cloud workload identity, for example. Cosign generates an ephemeral key pair in memory. It sends the OIDC token and the ephemeral public key to Fulcio, the certificate authority. Fulcio verifies the token and issues a short-lived X.509 certificate that binds the ephemeral public key to the OIDC identity, the workflow’s repository and trigger, for instance. Cosign signs the artifact, records the signature and certificate in Rekor, and then discards the private key. Nothing durable is left to steal.

Rekor is the transparency log, an append-only, tamper-evident record of signing events. When cosign uploads a signature, Rekor returns an inclusion proof and a signed timestamp. This matters because the Fulcio certificate is already expired by the time anyone verifies it. Rekor’s timestamped entry proves the signature was created while the certificate was valid. The root of trust for both Fulcio and Rekor is distributed through The Update Framework, or TUF, so clients bootstrap trust without hard-coding keys.

Verification and policy enforcement

Evidence is only useful if something refuses to proceed without it. Verification is where the whole chain earns its keep. A verifier does three things: confirms the artifact’s signature is valid, confirms the signer identity matches an expected pattern, and confirms the Rekor entry exists and proves timely signing.

The expected-identity check is the part teams underuse. It is not enough that an artifact is signed by some valid Sigstore identity. You must assert it was signed by the right one, your organization’s repository, on the main branch, via your release workflow. Combined with a provenance check that the build ran at the SLSA level you require, this closes the loop. Enforcement can live in the CI pipeline before promotion, and again at Kubernetes admission time through a policy engine, so no unverified image ever schedules.

Layering the two enforcement points is deliberate. The CI check gives developers fast, local feedback and stops a bad artifact before it is ever promoted, which is cheaper and clearer than a cryptic admission rejection hours later. The admission check is the backstop that cannot be skipped, catching anything that reached the registry through a path that bypassed CI. Neither alone is sufficient: CI-only enforcement is bypassable, and admission-only enforcement pushes failures too late in the lifecycle. Defense in depth applies to your own controls, not just to attackers.

Deeper Analysis: Signing, Attestation, and Verification

Provenance is expressed as an in-toto attestation. The in-toto attestation format, whose modern shape came from the ITE-6 proposal, has three layers. The outer layer is a DSSE envelope, Dead Simple Signing Envelope, which carries the payload and its signatures. Inside sits an in-toto Statement, the header, which names the subject, the artifacts this attestation is about, identified by digest, and a predicateType URI. The predicate is the payload body, and for SLSA build provenance the predicateType is https://slsa.dev/provenance/v1.

That structure is deliberately generic. The same envelope carries SBOMs, vulnerability scans, or test results simply by changing the predicateType. Verifiers dispatch on that URI to know how to interpret the body. A trimmed SLSA provenance predicate looks like this.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "ghcr.io/acme/payments",
      "digest": { "sha256": "e3b0c44298fc1c149afbf4c8996fb924..." }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa.dev/github-actions/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/heads/main",
          "repository": "https://github.com/acme/payments"
        }
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/acme/.github/workflows/release.yml@refs/heads/main" },
      "metadata": { "invocationId": "run-8842197-1" }
    }
  }
}

The subject binds the attestation to a specific artifact by digest. Change one byte of the artifact and the digest no longer matches, so the provenance no longer applies. The builder.id is what your verification policy pins against. If the builder is anything other than your expected release workflow, verification fails.

Generating this in practice is increasingly a one-line concern. On GitHub, artifact attestations produce a Sigstore-signed SLSA provenance bundle directly from a workflow, and the slsa-github-generator reusable workflows target Build L3. A minimal signing and attestation flow with cosign looks like the following.

# Keyless sign a container image by digest
cosign sign --yes \
  ghcr.io/acme/payments@sha256:e3b0c44298fc1c149afbf4c8996fb924

# Attach SLSA provenance as an attestation
cosign attest --yes \
  --predicate provenance.json \
  --type slsaprovenance \
  ghcr.io/acme/payments@sha256:e3b0c44298fc1c149afbf4c8996fb924

On the GitHub-native path, generating a signed attestation during a build is a single step, and verification uses the GitHub CLI against a pinned identity.

# In a workflow, generate provenance for a built image
# uses: actions/attest-build-provenance@v2
#   with:
#     subject-name: ghcr.io/acme/payments
#     subject-digest: sha256:e3b0c442...
#     push-to-registry: true

# Verify from anywhere, pinning the source repo
gh attestation verify oci://ghcr.io/acme/payments@sha256:e3b0c442... \
  --owner acme

Verification with cosign directly is where you assert the expected identity explicitly. This is the command that actually enforces your policy, and the two flags matter more than any others.

cosign verify \
  --certificate-identity-regexp "https://github.com/acme/.+/.github/workflows/release.yml@.+" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/acme/payments@sha256:e3b0c44298fc1c149afbf4c8996fb924

Without --certificate-identity-regexp, you accept a signature from any Sigstore identity on earth, which is close to accepting no signature at all. The issuer flag ties the identity back to a trusted OIDC provider. Get these two right and forgery requires compromising your OIDC identity itself, a much higher bar than stealing a file.

A subtle point trips up teams new to keyless verification. The Fulcio certificate that signed the artifact expired minutes after issuance, so a naive certificate-validity check would fail every time. Verification instead trusts the Rekor entry: cosign confirms the signature is recorded in the transparency log with a timestamp that falls inside the certificate’s brief validity window. This is why Rekor is not optional plumbing but a load-bearing part of the trust model. The transparency log is what lets an expired, ephemeral certificate still prove a valid signing event long after the fact.

There is also a useful monitoring dividend. Because every signing event is public in Rekor, you can watch the log for signatures claiming your identity or your artifacts. An unexpected entry, a signature from a workflow you did not run, is an early warning that your OIDC identity may be compromised. Transparency is not only for verifiers downstream; it is a detection surface for you.

The following table maps the SLSA build levels to what each actually guarantees and the rough effort to reach it, which helps prioritize where to invest.

SLSA Build Level	Core guarantee	What it stops	Typical effort
L1	Provenance exists, unsigned	Accidental misconfiguration, missing paper trail	Low, emit provenance from existing CI
L2	Provenance signed by a hosted platform	Hand-forged provenance, in-transit tampering	Medium, move to hosted signed builds
L3	Hardened, isolated build with unreachable signing keys	Injected build steps forging clean provenance	Higher, adopt L3 generators or hardened runners

Most teams find L2 achievable within a sprint on a managed CI platform, while L3 is the meaningful jump because it defends against a compromised builder rather than a compromised file. The relationship to SBOMs is complementary and worth restating precisely: the SBOM tells you what components are inside the artifact, and the provenance tells you how the artifact was produced. Both are attestations, often signed by the same Sigstore machinery, and a mature pipeline emits both.

Figure 2: The keyless signing sequence. A CI workflow requests an OIDC identity token, cosign generates an ephemeral key pair, Fulcio issues a short-lived certificate binding that key to the OIDC identity, cosign signs the artifact digest and submits the signature and certificate to Rekor, receives an inclusion proof, and finally discards the private key so no durable signing secret remains.

Figure 3: Verification at deploy time. The verifier pulls the artifact by digest, fetches its provenance and signature, verifies the signer identity against an expected pattern, checks the Rekor inclusion proof, and passes the result to a policy gate that either allows admission and deployment or denies and blocks the image from entering the cluster.

At admission time in Kubernetes, this logic moves into a policy engine. Kyverno verifies GitHub artifact attestations natively using its SigstoreBundle verification type, because GitHub attestations are themselves Sigstore bundles. The Sigstore policy-controller and OPA Gatekeeper offer equivalent controls. A Kyverno policy pins the same identity and issuer you used at the command line, so the cluster refuses any image not signed by your release workflow, turning verification from a one-time check into a continuous, non-bypassable control.

Trade-offs, Gotchas, and What Goes Wrong

Keyless signing removes key management but does not remove trust management. You have traded the problem of protecting a long-lived key for the problem of protecting your OIDC identity and pinning verification policies correctly. A misconfigured identity regexp that matches too broadly is a silent bypass, and it is the single most common real-world failure.

Rekor availability and dependency are real considerations. If your verification requires an online Rekor lookup and the public instance is degraded, deploys can stall. Mature setups verify against Rekor inclusion proofs bundled with the artifact rather than making a live call on every admission, and some organizations run a private Sigstore stack for control and availability.

Provenance can also tell the truth about a compromised builder. SLSA guarantees the provenance faithfully describes the build, not that the build platform itself is uncompromised. If an attacker owns your L3 builder, the provenance will honestly attest to a malicious build. Provenance raises the cost of attack and localizes trust to the build platform; it does not make the build platform infallible.

Verification bypass is the quiet killer. Signing everything while enforcing nothing is theater. If a single namespace exempts the admission policy, or developers can push directly to a trusted registry path, the whole chain is moot. Developer friction is the other side of that coin: overly strict policies that block legitimate hotfixes push teams to carve out exceptions that never get closed.

Finally, monorepo and polyglot builds strain the model. One repository producing dozens of artifacts across languages needs per-artifact provenance and careful subject-digest hygiene, and not every ecosystem’s build tooling emits clean provenance yet. Expect gaps at the edges.

Running your own Sigstore stack is a trade-off worth weighing explicitly. The public good instances of Fulcio and Rekor are free and well operated, but they are shared infrastructure with their own availability and rate limits, and some regulated environments cannot depend on external services in their release path. Self-hosting gives you control, air-gap compatibility, and predictable capacity, at the cost of operating a certificate authority and a transparency log, rotating their trust roots, and distributing those roots through TUF. For most teams the public instances are the right starting point; graduate to a private stack only when a concrete compliance or availability requirement forces it.

There is also a cultural failure mode that no tool fixes. Software supply chain security programs stall when they are owned by a central security team that bolts controls onto pipelines developers do not understand. Provenance and signing succeed when they are invisible defaults in the golden path, generated automatically by shared workflows rather than hand-rolled per team. If verifying an artifact is harder than shipping an unverified one, engineers will route around the control, and every exception you grant erodes the guarantee for everyone.

Practical Recommendations

Treat software supply chain security as a maturity ladder, not a switch. The failure mode is trying to reach L3 everywhere at once and stalling; the winning move is getting cheap wins broadly first, then hardening what matters most.

Start by emitting provenance everywhere, even unsigned L1, so you have visibility. Then move your build to a hosted platform that signs provenance to reach L2, which most managed CI already supports. Reserve the L3 investment, hardened runners or the slsa-github-generator, for your highest-risk artifacts first: anything internet-facing or handling money or credentials.

On the signing side, adopt keyless by default and pin verification to specific identities from day one. A signature you do not verify against an expected identity is decoration.

Sequence the rollout to build trust before you build walls. Run policies in audit or warn mode first, logging what would have been blocked without actually blocking it, so you can find the artifacts that lack provenance and fix the pipelines rather than breaking production. Only flip to enforce once the audit log is clean. This staged path turns software supply chain security from a disruptive mandate into a measurable, incremental program that engineering teams can actually adopt, and it gives you the evidence to show auditors that enforcement is real rather than aspirational.

Use this checklist:

• Emit SLSA provenance for every build; start at L1 and climb.
• Sign artifacts keyless with cosign; discard ephemeral keys.
• Always pass --certificate-identity-regexp and --certificate-oidc-issuer on verify.
• Attach both an SBOM and provenance attestation to each artifact.
• Reference artifacts by digest, never by mutable tag.
• Enforce verification at CI promotion and again at Kubernetes admission.
• Deny by default; allow exceptions only with expiry dates.
• Prefer bundled Rekor inclusion proofs over live lookups for availability.

For the cluster-side signing detail, our guide on container image signing with cosign and Kubernetes walks the admission-control setup end to end, and pairing this with GitOps and progressive delivery gives you a verified, auditable path from commit to production.

Frequently Asked Questions

What is the difference between SLSA and Sigstore?

SLSA is a framework that defines what trustworthy build provenance looks like and grades it in levels. Sigstore is a set of tools, Cosign, Fulcio, and Rekor, that sign and verify artifacts and attestations without long-lived keys. SLSA tells you how strong your provenance claim is; Sigstore is how you sign and prove that claim. They are complementary, and a full pipeline uses both together.

Is keyless signing actually secure without a private key?

Yes, because the key still exists, just briefly. Cosign generates an ephemeral key pair, uses it within minutes, and discards the private half. Trust rests on the OIDC identity that Fulcio certifies and the Rekor transparency log’s timestamped record proving the signature was made while the short-lived certificate was valid. The attack surface shifts from protecting a stored secret to protecting your identity provider, which is generally a stronger position.

Do I need an SBOM if I already have SLSA provenance?

Yes, they answer different questions. Provenance describes how an artifact was built, its source, builder, and parameters. An SBOM, in SPDX or CycloneDX format, enumerates what components are inside it. You need provenance to trust the build and an SBOM to respond to a new vulnerability in a dependency. Mature pipelines emit both as signed attestations, frequently using the same Sigstore signing machinery.

What SLSA level should my organization target?

Aim for L2 broadly and L3 for high-risk artifacts. L1 gives visibility but no tamper resistance. L2, signed provenance from a hosted platform, defeats forged provenance and is achievable on most managed CI within a sprint. L3, hardened isolated builds with unreachable signing keys, defends against a compromised builder and matters most for internet-facing services or anything touching money, secrets, or customer data.

How do I verify attestations at Kubernetes admission time?

Use a policy engine. Kyverno verifies GitHub artifact attestations natively through its SigstoreBundle verification type, and the Sigstore policy-controller and OPA Gatekeeper offer equivalent enforcement. Configure the policy to pin the expected certificate identity and OIDC issuer, matching what you used with cosign. The cluster then rejects any image not signed by your release workflow, making verification a continuous control rather than a one-time check.

Can provenance be faked or bypassed?

Signed provenance is hard to fake but the system can still be bypassed operationally. At L2 and above the provenance is signed, so it cannot be hand-forged. However, provenance honestly describes even a compromised builder, so an attacker who owns your L3 build platform produces truthful but malicious provenance. The more common failure is verification that is too loose or not enforced at all, an identity regexp that matches everything, or an exempt namespace.

Further Reading

• SBOM software bill of materials architecture (2026) – the inventory layer that complements provenance.
• Container image signing with cosign on Kubernetes (2026) – admission-control setup end to end.
• GitOps with Argo CD and progressive delivery (2026) – a verified path from commit to production.
• SLSA security levels specification – the authoritative build-track definitions.
• Sigstore documentation – Cosign, Fulcio, and Rekor reference and guides.
• in-toto attestation framework – the attestation and DSSE envelope specification.

By Riju — about