Why bother with SLSA
Most attacks on software supply chains are not exotic. A leaked publish token, a malicious dependency, a backdoored build script. SLSA is the framework that names the controls that close those paths.
Level 3 is the practical target. It requires hosted, ephemeral build runners, signed builds, and verifiable provenance. You can get there in a sprint with the tools below.
The pipeline
Pull requests trigger a workflow on GitHub Actions hosted runners. The job authenticates to your cloud through OIDC, with no long lived secrets. Cosign signs container images keylessly against the OIDC identity. Syft generates an SBOM in CycloneDX. in-toto attestations capture the provenance.
Signed images and attestations are pushed to your OCI registry. A Kyverno admission controller in every Kubernetes cluster verifies the signature and provenance before scheduling a pod.
Hardening
There are a few small choices that matter.
- pin actions by sha, not tag
- reusable workflows owned by platform, called by app teams
- oidc trust scoped to repo and branch, not org
- workflow tokens minimum permission, defaulted to read
- sbom diff alerts on new transitive dependencies
Result
Production runs only images built by your pipeline, signed by your identity, with a provenance trail back to the commit. If an attacker pushes a tampered image to the registry, the cluster refuses it.
References
Official documentation and standards we draw on for this pattern.
SLSA framework
slsa.dev
Sigstore Cosign
docs.sigstore.dev
Syft (SBOM generator)
github.com
in-toto attestation framework
in-toto.io
Kyverno policy engine
kyverno.io
NIST Secure Software Development Framework
csrc.nist.gov
Links open in a new tab
Takeaway
A signed supply chain is one of the highest leverage investments a platform team can make. Three weeks of work, years of pay off.