CKS — Image Security & Supply Chain

3 minute read

Chapter 9 — Image Security & Supply Chain

CKS Exam Domain: Supply Chain Security (20%)

Supply Chain Security is one of the three highest-weighted domains on the CKS exam, carrying 20% of the total score. It covers everything that happens before a container runs — where images come from, what’s inside them, whether they’ve been tampered with, and whether the cluster enforces policies about what is allowed to run.

The attack surface starts long before a Pod is scheduled. A single compromised base image, an unscanned vulnerability, or an unsigned image pulled from a public registry can give an attacker a foothold that bypasses every runtime control you’ve built.

Why Supply Chain Security Matters

┌─────────────────────────────────────────────────────────────┐
│                  Container Supply Chain                      │
│                                                             │
│  Base Image (OS layer)                                      │
│    └── Application Dependencies (libraries, packages)       │
│        └── Application Code                                 │
│            └── Container Image (built + tagged)             │
│                └── Registry (stored + distributed)          │
│                    └── Pod (pulled + running)               │
│                                                             │
│  EVERY STAGE IS AN ATTACK VECTOR                            │
│                                                             │
│  • Malicious base image → backdoored OS packages            │
│  • Vulnerable dependency → CVE exploitation                 │
│  • Unsigned image → man-in-the-middle swap                  │
│  • Public registry → typosquatting attacks                  │
│  • No admission control → any image runs in the cluster     │
└─────────────────────────────────────────────────────────────┘

Real-world supply chain attacks:

  • SolarWinds (2020) — Build pipeline compromise injected backdoors into signed updates
  • Codecov (2021) — Tampered Docker image in CI exfiltrated environment variables
  • Log4Shell (2021) — Vulnerable library embedded in thousands of container images
  • ua-parser-js (2021) — npm package hijack delivered crypto miners via container builds

What This Chapter Covers

# Topic Focus Area Link
1 Minimize Base Image Footprint Distroless, multi-stage builds, image hardening Go →
2 Image Scanning Trivy, Grype, severity filtering, CI/CD integration Go →
3 Image Allowlisting OPA Gatekeeper, Kyverno, trusted registries, digest pinning Go →
4 Image Signing & Verification Cosign, Sigstore, keyless signing, admission enforcement Go →
5 ImagePolicyWebhook Admission controller configuration, ImageReview API, backend setup Go →
6 Hands-On Lab End-to-end exercises covering all image security topics Go →

Exam Relevance

The Supply Chain Security domain (20%) directly tests your ability to:

  • Minimize base image footprint — use distroless/minimal images, multi-stage builds
  • Scan images for known vulnerabilities — Trivy is the de facto standard on the exam
  • Restrict images to allowlisted registries — OPA Gatekeeper or Kyverno constraints
  • Verify image integrity — signing with Cosign, digest pinning
  • Configure ImagePolicyWebhook — admission controller that gates image pulls through an external backend

Exam Task Patterns

Typical CKS exam tasks in this domain:

1. "Scan images running in namespace X and delete Pods with CRITICAL vulnerabilities"
   → Use `trivy image` on each image, delete offending Pods

2. "Create a policy that only allows images from registry.example.com"
   → Write OPA Gatekeeper Constraint or Kyverno ClusterPolicy

3. "Configure ImagePolicyWebhook to deny images not approved by the backend"
   → Edit API server manifest, create AdmissionConfiguration, set up kubeconfig

4. "Build a minimal image for the given application"
   → Multi-stage Dockerfile, distroless base, non-root user

Defense-in-Depth: Image Security Layers

A robust image security strategy operates at every layer:

Layer Control Tool / Mechanism
Build Minimal base images, no secrets in layers Distroless, multi-stage builds
Scan Detect CVEs before deployment Trivy, Grype, Snyk
Sign Prove image provenance and integrity Cosign, Notary, Sigstore
Admit Block unauthorized images at the API server ImagePolicyWebhook, OPA, Kyverno
Runtime Detect anomalous image behavior Falco, runtime scanning 
        Build              Scan              Sign              Admit            Runtime
   ┌──────────┐      ┌──────────┐      ┌──────────┐      ┌──────────┐      ┌──────────┐
   │Distroless│ ───→ │  Trivy   │ ───→ │  Cosign  │ ───→ │ Webhook  │ ───→ │  Falco   │
   │Multi-stg │      │  Grype   │      │ Sigstore │      │   OPA    │      │ Monitor  │
   │Non-root  │      │  CI/CD   │      │  SBOM    │      │ Kyverno  │      │  Detect  │
   └──────────┘      └──────────┘      └──────────┘      └──────────┘      └──────────┘
       ▲                                                                          │
       └──────────────── Feedback Loop (patch, rebuild, re-sign) ─────────────────┘

Getting Started

Start with Minimize Base Image Footprint to build the foundation — understanding what goes into an image determines every security decision downstream.

Updated:

You may also enjoy