Supply Chain Security
Required knowledge for the CKS certification.
Last reviewed: — verified against Kubernetes 1.36.
Modern Kubernetes environments depend on a long chain of tools, images, dependencies, and external services to build and run applications. This software supply chain is a powerful enabler — and a high-leverage attack vector if any link breaks. This page is the head reference for Domain 5 of the CKS exam (Supply Chain Security, 20%) and covers the build → sign → scan → admit lifecycle that every production workload should pass through.
Why Supply Chain Security Matters
Public incidents — SolarWinds, the event-stream npm backdoor, malicious GitHub Actions, typosquatted PyPI packages — show that attackers consistently target the build pipeline because it bypasses every workload-level control downstream. A compromised supply chain can:
- Inject malicious code into images that admission policy still considers "trusted"
- Exfiltrate registry, cloud, and Git credentials from CI runners
- Plant persistent backdoors that survive cluster rebuilds
- Tamper with dependencies long before a workload reaches production
The defences below address each link in the chain: a hardened build, a signed artifact, a scanned image, a verified admission, and a continuously re-scanned deployed artifact.
Supply Chain Domains
The four domains below map to the four points in the lifecycle where the chain can break.
| Domain | Primary Risk | Key Control | Reference |
|---|---|---|---|
| Build | Compromised CI runner steals credentials or injects code | Ephemeral runners, pinned actions, OIDC for cloud auth | Supply Chain Best Practices |
| Sign | Image cannot be proven authentic at deploy | Cosign or Notation signing in CI; admission-time verification | Cosign · Notation |
| Scan | Vulnerable images deployed to production | Trivy / Grype + SBOM in CI; continuous re-scan in cluster | Trivy · Grype · Trivy Operator |
| Admit | Anything reaches the cluster, signed or not | Image-policy admission webhook (Kyverno / Gatekeeper / Sigstore Policy Controller) | Kyverno |
| SBOM | Cannot answer "is CVE-X in my fleet?" | Syft / Trivy SBOM, KBOM for cluster components | Syft · SBOM · KBOM |
What You'll Learn in This Section
- Detecting and preventing use of vulnerable container images
- Using image signing and verification (Cosign, Notation)
- Enforcing trusted builds with reproducible, auditable pipelines
- Securing CI/CD pipelines to prevent credential leaks and unauthorized image pushes
- Auditing dependencies and scanning for vulnerabilities in third-party libraries
- Generating and consuming SBOMs (Software Bill of Materials) for both images and clusters
Key Articles
- Supply Chain Security Best Practices
- Cosign – Image Signing
- Notation – OCI Image Signing
- Syft – SBOM Generator
- Trivy Operator – Continuous Scanning
- Snyk – Dependency Scanning
- Understanding SBOM
- KBOM – Kubernetes Bill of Materials
- Grype – Vulnerability Scanner
- Trivy – Vulnerability Scanner
Image Signing: Cosign vs Notation
Both Cosign and Notation provide image signing and verification, but they target different ecosystems. Pick the one that aligns with your registry, your compliance posture, and your existing PKI.
| Aspect | Cosign | Notation |
|---|---|---|
| Project | Sigstore (CNCF) | Notary v2 (CNCF) |
| Storage | OCI artifacts in the same registry | OCI artifacts in the same registry |
| Trust root | Public Sigstore (Fulcio + Rekor), keyless OIDC, or self-managed keys | Standard X.509 PKI |
| Keyless workflow | Yes — OIDC identity becomes the signer | No — keys / certificates managed by the operator |
| Transparency log | Rekor (public, append-only) | Optional, integrated via verifier plugins |
| Verification engines | cosign verify, Kyverno, OPA Gatekeeper, Sigstore Policy Controller | notation verify, Ratify, Kyverno (verifyImages) |
| Best fit | Open-source projects, OIDC-based CI, public transparency | Enterprises with existing X.509 PKI, regulated environments |
SBOM Generators: Syft vs Trivy
SBOMs (Software Bill of Materials) describe what is inside an artifact. The two practical generators in the Kubernetes ecosystem are Syft and Trivy.
| Aspect | Syft | Trivy |
|---|---|---|
| Maintainer | Anchore | Aqua Security |
| Output formats | SPDX, CycloneDX, Syft JSON | SPDX, CycloneDX, Trivy JSON |
| Source types | Images, filesystems, archives, source repos | Images, filesystems, Git repos, K8s clusters, cloud accounts |
| Pairs with | Grype for vulnerability matching | Built-in vulnerability scanner, no separate tool needed |
| KBOM support | Indirect (Syft + cluster snapshot tooling) | Native (trivy k8s) |
| Best fit | SBOM-first pipelines that pair with Grype | One-tool pipelines that emit SBOM + scan in a single pass |
Read more: Syft · Trivy · SBOM · KBOM
Try It: Live YAML Security Analyzer
Some supply-chain controls show up as Pod-spec invariants — the image field, imagePullPolicy: Always, imagePullSecrets. Paste a manifest below to see whether it ships those fields with sane values.
Version-Specific Notes (Kubernetes 1.36)
The supply-chain story has tightened in recent Kubernetes versions:
- Validating Admission Policy — GA since 1.30. CEL-based policies in the API server can pin image registries, require digest pins (
@sha256:...), and requireimagePullPolicysettings without running a webhook. - Image Volume source (
volumes[].image) — Beta in 1.33. Mounts an OCI image as a read-only volume; useful for distributing signed configuration bundles or signed model files alongside a workload. - Image pull credential providers — Stable. Kubelet credential provider plugins fetch registry credentials at pull time, removing long-lived
imagePullSecretsfrom the cluster. - Restricted ImagePolicy via Kyverno
verifyImages— Stable. Validates Cosign or Notation signatures at admission and ties images to a trust root maintained outside the cluster.
Always check the Kubernetes deprecation guide before upgrading.
Who Should Read This
- Platform engineers and DevSecOps teams building or maintaining CI/CD infrastructure
- Developers packaging and deploying workloads in containers
- Security professionals validating the integrity of containerized applications in Kubernetes
Hardening Principles for the Supply Chain
Secure by Default
Pin image references to digests (image: registry/app@sha256:...) so that a tag rewrite cannot silently swap the running artifact. Build images from minimal bases. Generate an SBOM and a signature in the same CI step.
Least Privilege
CI runners should hold only the credentials they need for the current job, scoped via OIDC to short-lived cloud and registry tokens. Image push permissions belong to the build pipeline alone, not to humans.
Defense in Depth
Stack scanning (Trivy / Grype), signing (Cosign / Notation), and admission verification. A signature-verifying admission webhook should reject unsigned images even if scanning was somehow skipped.
Continuous Verification
A vulnerability that did not exist at build time can ship to production tomorrow. Run Trivy Operator (or equivalent) to re-scan deployed images on a daily cadence and surface new CVEs without a release.
Conclusion
Supply chain security is the longest-running thread in Kubernetes hardening — every link from git push to kubectl apply has to be controllable and auditable. The articles in this section walk through the build → sign → scan → admit lifecycle with executable examples.
Learn more by reviewing the CNCF Supply Chain Security Whitepaper.