Between a developer's commit and a pod serving traffic, your code passes through source control, a CI runner, a build tool, a dependency resolver, a registry, and an admission pipeline. Each hop is an opportunity to inject something that was never in the source. The last few years turned that abstract risk concrete: SolarWinds showed attackers tampering with a build system to ship a backdoor to thousands of customers; the 2021 Codecov incident compromised a widely used CI helper; and the 2024 discovery of a deliberately planted backdoor in the XZ Utils compression library (CVE-2024-3094) revealed a patient, multi-year effort to subvert a dependency that ships in countless container images. Kubernetes clusters are downstream of all of it. Supply chain security for Kubernetes is about establishing a verifiable chain of custody — proving that what runs in your cluster was built by your pipeline, from source you control, and has not been altered since — and then getting the cluster to refuse anything that cannot prove it.
The chain of custody, link by link
A defensible Kubernetes supply chain rests on four capabilities, each answering a specific question:
- Provenance — where did this image come from? Cryptographically attested build metadata linking the image to a source commit and a build system.
- Integrity — has it changed since it was built? Signatures and digest pinning that make tampering detectable.
- Composition — what is inside it? A Software Bill of Materials enumerating every dependency, so a new CVE is a lookup, not an investigation.
- Enforcement — will the cluster reject what fails the above? Admission control that verifies signatures, provenance, and policy before scheduling.
Miss any one and the others weaken. A perfect SBOM does not help if the cluster runs unsigned images; a signature proves integrity but says nothing about whether the build was trustworthy in the first place.
The reason this matters more for Kubernetes than for a single server is scale of trust. A cluster typically pulls from many repositories, runs images built by different teams, and mixes first-party services with third-party controllers, operators, and sidecars installed from public charts. Each of those is a supply chain you have implicitly adopted. A backdoor in a popular operator, or a typosquatted image reference in a Helm values file, propagates to every cluster that installs it — which is exactly the leverage attackers seek. Treating supply chain security as a per-cluster admission problem, rather than a per-image afterthought, is what turns that sprawl back into something you can reason about.
Establish provenance with SLSA
SLSA (Supply-chain Levels for Software Artifacts) is the framework the industry has converged on for build provenance. Its levels describe increasing guarantees: that a build produced signed provenance, that it ran on a hardened, isolated builder, and that the provenance is non-falsifiable. The practical goal is to generate signed, machine-readable provenance in CI — recording the source commit, the builder identity, and the build parameters — and to attach it to the image as an attestation. Reusable workflows and build tooling can emit SLSA provenance automatically, so this is increasingly a matter of configuration rather than custom engineering.
Sign images and attach SBOM attestations
Provenance is only useful if it is bound to the image and verifiable. Cosign signs both the image and its attestations using keyless, OIDC-backed short-lived certificates:
# Sign the image
cosign sign --yes registry.example.com/payments/api@sha256:abc123...
# Attach an SBOM as a signed attestation
cosign attest --yes \
--predicate sbom.cdx.json \
--type cyclonedx \
registry.example.com/payments/api@sha256:abc123...
Now the image carries verifiable proof of both its origin and its contents, and both are tamper-evident.
Enforce verification at admission
The chain is meaningless unless the cluster refuses to run anything that breaks it. A Kyverno policy verifies the signature and can require that a matching SBOM or provenance attestation exists before a pod is scheduled:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-provenance
spec:
validationFailureAction: Enforce
rules:
- name: verify-and-attest
match:
any:
- resources:
kinds: ["Pod"]
verifyImages:
- imageReferences: ["registry.example.com/payments/*"]
attestors:
- entries:
- keyless:
issuer: "https://token.actions.githubusercontent.com"
subject: "https://github.com/acme/*"
attestations:
- type: https://cyclonedx.org/bom
attestors:
- entries:
- keyless:
issuer: "https://token.actions.githubusercontent.com"
Anything unsigned, built by an unrecognized identity, or missing its attestations is rejected before it ever runs.
Maturity checklist
- CI emits signed SLSA provenance for every image
- Images signed with cosign; deployments pull by digest
- SBOM generated per build and attached as a signed attestation
- Third-party and base images verified or mirrored into a trusted registry
- Admission controller enforces signature + provenance + policy
- Dependency risk continuously re-evaluated as new CVEs are disclosed
- Build systems hardened and access-controlled (they are production infrastructure)
How Safeguard helps
A supply chain program lives or dies on whether every image can prove its lineage and contents automatically. Safeguard's SBOM Studio generates CycloneDX and SPDX SBOMs directly from your build, stores them alongside each image, and diffs them release over release so a dependency that silently appears is visible immediately — and it ingests SBOMs from vendors and existing tools so your inventory spans what you build and what you buy. Container security scanning and software composition analysis continuously re-evaluate that inventory against new advisories, while Griffin AI prioritizes by reachability and opens auto-fix pull requests for the issues that matter. Compare our supply-chain-native approach to broader platforms on the comparison hub.
Build a chain of custody your cluster can verify. Start free with Safeguard or read the documentation.