When people say “software supply chain security,” most engineers nod and quietly hope someone else is handling it. The phrase sounds like compliance theater. It is not. A supply chain attack means an adversary compromises something you depend on (a base image, a build step, a package, a CI runner) so that malicious code ends up in your production system without anyone writing it there on purpose. The famous incidents of recent years were exactly this shape.
The good news is that the cloud native ecosystem has built practical, open tools to defend against it. Three names come up constantly: SLSA, Sigstore, and in-toto. They solve different parts of the same problem, and together they form a coherent story. Here is that story without the jargon.
The core question: can you trust this artifact?
Every artifact you deploy (a container image, a binary, a package) arrives with an implicit claim: “I am what you think I am, and I was built the way you expect.” Supply chain security is about making that claim explicit and verifiable. You want to answer three questions:
- Who produced this, and can they prove it? (signing)
- How was it built, and from what? (provenance and attestation)
- What level of rigor did that build process meet? (a framework to measure against)
Signing, attestation, and a framework. Sigstore, in-toto, and SLSA line up against those three questions.
SLSA: the yardstick
SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is not a tool. It is a framework, a set of levels that describe how tamper resistant your build process is. Lower levels ask for basic provenance: a signed statement of how an artifact was built. Higher levels demand that builds run on hardened, isolated infrastructure where even the person who wrote the pipeline cannot quietly inject something into a specific build.
The value of SLSA is that it turns a vague goal (“be more secure”) into a ladder you can climb and measure. You can say “our releases are SLSA level 3” and that sentence means something specific and checkable, rather than being a marketing adjective.
Sigstore: signing without the key management nightmare
Signing artifacts proves who produced them. The historical blocker was key management: nobody wanted to hold a long lived private signing key. Sigstore removes that blocker with keyless signing. Instead of a key you keep, you authenticate with an identity (an OIDC account or a CI workload identity), receive a short lived certificate bound to that identity, sign in that brief window with an ephemeral key, and record the signature in a public transparency log called Rekor.
The result: no long lived secret to leak, verification tied to a specific identity, and a public audit trail. In practice you sign with cosign sign and verify with an explicit identity assertion:
cosign verify $IMAGE \
[email protected] \
--certificate-oidc-issuer=https://accounts.google.comThat verification is a real gate. If anything other than your release identity signed the image, it fails. (One footnote from contributing to cosign: keyless has been the default since v2, so ignore any older guide that still tells you to set COSIGN_EXPERIMENTAL.)
in-toto: proving the steps in between
Signing tells you who produced the final artifact. But a supply chain is a sequence of steps: fetch source, run tests, build, package, push. in-toto, a CNCF graduated project, secures that whole chain. It lets you define the expected steps and who is allowed to perform each one, and it produces signed attestations at each step. At the end, you can verify that the artifact you are about to run actually went through every required step, performed by the authorized party, in the right order.
Think of it as a chain of custody for software. Sigstore signs the box; in-toto proves the box went through every checkpoint it was supposed to, and nobody skipped a step or swapped the contents along the way.
How they fit together
These are layers, not competitors:
- in-toto produces attestations about how an artifact was built (provenance and step by step custody).
- Sigstore signs those attestations and the artifact, binding them to a verifiable identity and recording them publicly.
- SLSA is the yardstick that says how rigorous the whole process needs to be to earn a given trust level.
In a modern setup, your CI builds an image, generates SLSA provenance and in-toto attestations describing exactly how it was built, signs all of it keyless with Sigstore, and pushes it. At deploy time, a Kubernetes admission controller verifies the signature and the attestations before the workload is allowed to run. A malicious image with no valid provenance from your pipeline simply never starts.
Why this belongs to everyone, not just security teams
For a long time this felt like specialist work. It is becoming table stakes. The tooling is open source, the flows integrate with the cloud native systems teams already run (OIDC identities, ephemeral workloads, declarative admission policy), and regulators and customers are increasingly asking for provenance by default.
If you want to start, start small. Sign one of your images keyless and verify it with an identity constraint. Generate provenance for one build and read it. Add one admission policy that requires a signature. Each step is independently useful, and together they turn “we hope our supply chain is clean” into “we can prove it.”
Takeaways
- Supply chain security answers three questions: who made this, how was it built, and how rigorous was that process.
- SLSA is the framework (the yardstick), Sigstore does identity based signing without long lived keys, and in-toto attests to the steps in between.
- They compose: in-toto attests, Sigstore signs, SLSA measures, and a Kubernetes admission controller enforces at deploy time.
- Start small and real: sign one image, verify with an identity, add one policy. The tooling is open and cloud native friendly.