Supply Chain Security is one of the most practical — and most frequently underestimated — domains on the Certified Kubernetes Security Specialist (CKS) exam. It carries roughly 20% of the exam weight, and almost every task in it is something you’ll do for real on the job: scan an image, shrink an attack surface, verify what’s actually inside a container, and stop dangerous images from ever reaching the cluster.
This guide walks through the entire domain from a practitioner’s perspective. You’ll get the concepts, the commands, and the exam-day shortcuts that let you finish these tasks quickly under the two-hour clock.
If you still need the big picture of the exam first, start with the CKS Exam Guide 2026 and the CKS Exam Topics breakdown, then come back here to go deep on supply chain.
What “Supply Chain Security” Means in Kubernetes
The software supply chain is everything that goes into producing and running your container — base images, application dependencies, build pipelines, registries, and the admission path into the cluster. An attacker doesn’t need to break your running pod if they can poison an upstream image or sneak a vulnerable dependency into your build.
For the CKS exam, the Supply Chain Security domain breaks down into four practical skills:
| Skill | What you’ll do on the exam |
|---|---|
| Minimize base image footprint | Rewrite Dockerfiles to use minimal/distroless images |
| Secure the supply chain | Whitelist allowed registries, sign and validate images |
| Static analysis of workloads | Scan manifests and Dockerfiles for misconfigurations |
| Scan images for vulnerabilities | Use Trivy (or similar) to find and report CVEs |
Each of these maps to a tool or a Kubernetes mechanism. Let’s take them in order.
Minimizing the Base Image Footprint
Every package in your image is a potential CVE. A node:20 image ships with hundreds of OS packages, a shell, a package manager, and build tools — none of which your running application needs. The fix is to use the smallest base image that still runs your app.
The hierarchy of smaller images
ubuntu / debian → full OS, large attack surface
node:20-slim → trimmed, but still has apt + shell
alpine → musl libc, tiny, has a shell
distroless → no shell, no package manager, app + runtime only
scratch → literally nothing but your static binaryA practical multi-stage Dockerfile
The exam loves multi-stage builds because they let you compile in a fat image and ship in a thin one:
# Build stage — has the full toolchain
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server
# Runtime stage — distroless, no shell, no package manager
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]What this buys you on the exam and in production:
- No shell means an attacker who achieves RCE can’t
execinto a useful environment. nonrootuser satisfies the common requirement to not run as UID 0.CGO_ENABLED=0produces a static binary that runs without glibc.
If a task asks you to “reduce the image’s vulnerability count,” switching the base image is almost always the fastest, highest-impact change. Scan before and after to prove it (next section).
Scanning Images with Trivy
Trivy is the scanner you should assume is installed on the exam. It scans container images, filesystems, and even Kubernetes manifests. You need to be fluent with three or four invocations.
Scan an image and fail on severity
# Scan an image, only show HIGH and CRITICAL findings
trivy image --severity HIGH,CRITICAL nginx:1.19
# Exit non-zero if anything CRITICAL is found (useful in pipelines)
trivy image --exit-code 1 --severity CRITICAL nginx:1.19
# Only report fixable vulnerabilities — the ones that matter
trivy image --ignore-unfixed --severity HIGH,CRITICAL myregistry/app:v2A common exam task: find and delete vulnerable pods
A classic Supply Chain task gives you several running pods and asks you to identify which ones use images with CRITICAL vulnerabilities, then delete those workloads. The efficient approach:
# 1. List the images in use in a namespace
kubectl get pods -n production \
-o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u
# 2. Scan each candidate image
trivy image --severity CRITICAL --quiet redis:5.0.5
# 3. Delete the deployment whose image is vulnerable
kubectl delete deployment legacy-redis -n productionExam tip: read the question carefully — sometimes you must delete the pod/deployment, sometimes just report the image name to a file. Putting the answer in the wrong place loses the marks even when your analysis is correct.
Scan a filesystem or Dockerfile
# Scan a project directory for vulnerable dependencies + IaC misconfig
trivy fs --scanners vuln,misconfig /opt/project
# Scan a Kubernetes manifest for insecure settings
trivy config /opt/project/k8s/Static Analysis of Workloads
Static analysis catches insecure settings before deployment — privileged containers, host mounts, missing security contexts. On the exam this often means reading a YAML manifest and fixing it, or running a tool like kubesec or trivy config.
What to flag in a manifest
apiVersion: v1
kind: Pod
metadata:
name: risky
spec:
containers:
- name: app
image: myapp:latest # ❌ mutable tag — pin a digest
securityContext:
privileged: true # ❌ full host access
runAsUser: 0 # ❌ runs as root
allowPrivilegeEscalation: true # ❌
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: / # ❌ mounts the whole node filesystemThe hardened version:
apiVersion: v1
kind: Pod
metadata:
name: hardened
spec:
containers:
- name: app
image: myapp@sha256:9f86d0... # ✅ pinned by digest
securityContext:
privileged: false
runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]Memorize that block. Reproducing a hardened securityContext from memory is one of the highest-leverage things you can practice for the exam — it appears across multiple domains, not just supply chain.
Securing the Supply Chain with Admission Control
Scanning is detective; admission control is preventive. The goal is to make the cluster reject images that don’t meet policy — wrong registry, unsigned, or unscanned — at the API server boundary.
Whitelisting registries with ImagePolicyWebhook
The CKS exam historically tests the ImagePolicyWebhook admission controller. The flow:
- Enable the admission plugin on the API server.
- Point it at an admission configuration file.
- The webhook backend accepts or denies images.
Enable it in the kube-apiserver manifest:
# /etc/kubernetes/manifests/kube-apiserver.yaml
- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
- --admission-control-config-file=/etc/kubernetes/admission/admission-config.yamlThe admission config:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
configuration:
imagePolicy:
kubeConfigFile: /etc/kubernetes/admission/kubeconfig.yaml
allowTTL: 50
denyTTL: 50
retryBackoff: 500
defaultAllow: false # fail closed — deny if the backend is unreachableThe single most important field here is
defaultAllow: false. “Fail closed” is the secure default and a common gotcha — if the question says images must be denied when the webhook is down, this is the line.
Remember the editing discipline for static pod manifests: editing /etc/kubernetes/manifests/kube-apiserver.yaml restarts the API server automatically. If kubectl stops responding for a moment, that’s expected — wait and re-check with crictl ps.
Modern approach: OPA Gatekeeper and admission policies
In real clusters (and increasingly in study labs) you’ll enforce registry allowlists with a policy engine like OPA Gatekeeper or Kyverno. A Kyverno policy that only allows images from a trusted registry:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-registries
spec:
validationFailureAction: Enforce
rules:
- name: allowed-registries
match:
any:
- resources:
kinds: ["Pod"]
validate:
message: "Images must come from registry.sailor.sh"
pattern:
spec:
containers:
- image: "registry.sailor.sh/*"Understanding both the classic ImagePolicyWebhook and a modern policy engine prepares you regardless of which the exam environment presents.
Image Signing, SBOMs, and Provenance
The newest slice of supply chain security is verifiable provenance — proving an image is exactly what your pipeline built and nothing else.
- Signing with a tool like cosign attaches a cryptographic signature to an image. An admission policy can then require a valid signature before a pod runs.
- SBOM (Software Bill of Materials) is a machine-readable inventory of everything in an image. Trivy can generate one:
# Generate a CycloneDX SBOM for an image
trivy image --format cyclonedx --output sbom.json myapp:v1
# Later, scan the SBOM itself for newly disclosed CVEs
trivy sbom sbom.jsonThe exam currently leans more on scanning and admission than on signing, but understanding SBOMs explains why scanning matters: you can only defend what you can enumerate.
A 7-Day Supply Chain Study Plan
| Day | Focus | Hands-on goal |
|---|---|---|
| 1 | Base image minimization | Convert a 3-stage app to distroless, measure size drop |
| 2 | Trivy image scanning | Scan 5 images, filter by severity, fail on CRITICAL |
| 3 | Find-and-delete vulnerable pods | Time yourself: identify + delete under 5 minutes |
| 4 | Static analysis | Harden 3 insecure manifests from memory |
| 5 | ImagePolicyWebhook | Configure it end-to-end, test defaultAllow: false |
| 6 | Kyverno/OPA registry allowlist | Block a disallowed registry, confirm rejection |
| 7 | SBOM + mixed review | Generate an SBOM, redo Days 1–6 against the clock |
The thing that separates a pass from a fail here is speed under pressure, and speed only comes from repetition in a real cluster. Reading about ImagePolicyWebhook is not the same as having configured it three times and knowing exactly which two files to edit.
Practice in a Real Exam-Like Environment
Supply chain tasks are muscle memory. You want to have already broken — and fixed — an API server static manifest before exam day, not be doing it for the first time under the clock.
Sailor.sh’s Certified Kubernetes Security Specialist (CKS) Mock Exam Bundle gives you a browser-based, exam-style terminal with realistic supply-chain scenarios: scanning images, hardening manifests, and wiring up admission control against a live cluster. It mirrors the real exam’s format and time pressure so the muscle memory is there when it counts. If you want to try the free, open-source practice terminal first, the CKS practice environment guide walks through getting started.
Pair the hands-on practice with structured study using the CKS Study Plan, and make sure you’ve cleared the CKS prerequisites — you need a current CKA to even sit the exam.
Frequently Asked Questions
How much of the CKS exam is supply chain security?
Supply Chain Security accounts for roughly 20% of the CKS exam. It’s tied for one of the larger domains, alongside Cluster Hardening and Monitoring/Logging/Runtime Security.
Do I need to memorize Trivy flags for the exam?
You should be fluent with trivy image, --severity, --ignore-unfixed, and --exit-code. The exam provides documentation access, but fumbling for flags costs time you don’t have. Practice until the common invocations are automatic.
Is ImagePolicyWebhook still relevant in 2026?
Yes for the exam, which still tests the classic admission controller. In production, policy engines like Kyverno and OPA Gatekeeper are more common. Learn both — the concepts (allowlist registries, fail closed) transfer directly.
What’s the single highest-impact supply chain change I can make?
Switching to a minimal or distroless base image. It removes entire classes of vulnerabilities and shells that attackers rely on, and it’s usually a few lines of Dockerfile. Scan before and after to quantify the improvement.
Can I pass the CKS without a strong CKA foundation?
Unlikely. CKS assumes you already move fast in a cluster — RBAC, kubectl, editing static pod manifests. If those feel slow, shore them up first. See CKA vs CKAD vs CKS: which certification first.
Conclusion
The Supply Chain Security domain rewards practitioners who actually do the work: shrink the image, scan it, read the manifest critically, and enforce policy at the admission boundary. None of it is conceptually hard — but all of it is timed, and the difference between knowing it and doing it fast is hours in a real terminal.
Build your Dockerfile-to-distroless reflex, get Trivy into your fingers, configure ImagePolicyWebhook until it’s boring, and you’ll walk into this domain confident. The same skills that earn the certification are the ones that genuinely protect production clusters — which is the whole point.