Kubernetes Supply Chain Security: From SBOM to SLSA Level 3
Signed images alone don't stop supply chain attacks. Here's how to move a real Kubernetes platform from ad-hoc scanning to SLSA Level 3 in one quarter.
RAZR Advisory
8 min read
The gap between "we scan images" and a secure supply chain
Container scanning catches known CVEs in base layers. It does nothing for:
- Compromised build agents injecting malicious code
- Dependency confusion in private registries
- Tampered artifacts between build and deploy
The SLSA ladder, in practice
- Level 1 — build is scripted (you already do this)
- Level 2 — hosted, tamper-resistant build service with provenance (GitHub Actions with attestations)
- Level 3 — hardened build platform, non-falsifiable provenance, isolated builds
- Level 4 — two-party review, hermetic + reproducible builds
Most teams should target Level 3 — Level 4 is aspirational for a few high-value services.
The 90-day plan
Weeks 1–3: Visibility
- Generate SBOMs for every image with
syft - Store them alongside the image in your registry (OCI referrer)
- Sign images with
cosignusing keyless OIDC
Weeks 4–8: Provenance
- Emit SLSA provenance from CI using
slsa-github-generator - Verify provenance in an admission controller (Kyverno or Sigstore policy-controller)
- Block unsigned images with a
ClusterPolicy
Weeks 9–12: Hardening
- Move builds to ephemeral, single-use runners
- Isolate secrets — no long-lived registry credentials in workflows
- Add a weekly reproducibility check on 3 critical images
What "done" looks like
A developer pushes code. CI produces a signed image with in-toto attestations. The cluster refuses to schedule anything that doesn't verify against your policy. No human in the loop.