Overview
Supply Chain Security is about trusting the artifacts that reach your cluster. You shrink images with multi-stage builds, distroless or scratch bases, pinned versions and a non-root USER, and you remove shells and package managers from the final stage. You describe what an image contains with a Software Bill of Materials in SPDX or CycloneDX format, generated by tools such as the Kubernetes bom utility or Trivy. You restrict which registries Pods can pull from and require signed images, using admission controls such as the ImagePolicyWebhook plugin, ValidatingAdmissionPolicy or a policy engine, with signatures produced by Sigstore cosign.
The fourth competency is static analysis. Kubesec scores a manifest and lists risky settings, KubeLinter flags misconfigurations, and Trivy scans images for known CVEs by severity. Exam tasks often end with deleting or fixing the workloads that a scan flags.
How it's tested
Supply chain tasks give you files, images or running workloads to evaluate. You may scan the images used by Pods in a namespace and remove those with HIGH or CRITICAL findings, fix a Dockerfile, generate an SBOM in a stated format, or configure the API server so only an approved registry or signed images are admitted.
-
Scan and act
Run Trivy or Kubesec against several images or manifests, compare results with a threshold, and delete, fix or report only the items that fail it.
-
Fix the build file
A Dockerfile or manifest has risky lines such as a latest tag, root user or an unneeded package; you change the fewest lines needed to meet the stated rules.
-
Admission gate
Configure ImagePolicyWebhook or another admission control so Pods from unapproved registries or unsigned images are rejected, including what happens when the backend is unreachable.
A task asks that Pods be rejected if the image policy webhook is unreachable. The admission configuration for ImagePolicyWebhook has a defaultAllow field; setting it to false makes the plugin deny when the backend cannot answer. Leaving the default of true would admit every Pod during an outage. The plugin also needs ImagePolicyWebhook in --enable-admission-plugins and --admission-control-config-file pointing at a mounted file.
Competencies 4
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
5.1 Minimize base image footprintBuilding small, non-root images with fewer components.
- What it means
- Every package in an image is potential vulnerable code and a tool an attacker can use. Minimizing the base image means shipping only the application and what it needs to run.
- What to understand
- Use multi-stage builds so compilers stay in the build stage. Choose distroless, scratch or slim bases, pin tags or digests instead of latest, combine RUN steps to avoid leftover files, remove shells and package managers where possible, and set a non-root USER. Avoid copying secrets into layers, because earlier layers remain readable even after a later delete.
- How it shows up
- Expect to edit a Dockerfile to use a pinned base and a non-root user, then rebuild.
- Common confusion
- Deleting a file in a later layer and assuming it no longer exists in the image.
5.2 Understand your supply chain (e.g. SBOM, CI/CD, artifact repositories)Knowing what is in your artifacts and how they are built.
- What it means
- The supply chain is every step from source code through builds, dependencies, registries and deployment. Understanding it means you can say exactly which components an image contains and where they came from.
- What to understand
- An SBOM lists packages, versions and licences in SPDX or CycloneDX format. The Kubernetes bom tool, whose CLI reference is on the allowed list, generates SPDX documents with bom generate; Trivy can output CycloneDX or SPDX for an image. CI/CD pipelines should produce SBOMs and scans, and artifact repositories should store images by immutable digest.
- How it shows up
- A task may ask you to generate an SBOM for an image in a given format, or find which image includes a vulnerable library version.
- Common confusion
- Treating an SBOM as a vulnerability report; it lists components, and scanners match them to CVEs.
5.3 Secure your supply chain (permitted registries, sign and validate artifacts, etc.)Allowing only approved registries and verified images.
- What it means
- Securing the supply chain means the cluster refuses artifacts that do not come from trusted sources or cannot be proven authentic. Controls sit at admission time, where Pods are accepted or rejected.
- What to understand
- The ImagePolicyWebhook admission plugin sends image references to an external service, configured through --admission-control-config-file with a kubeconfig for the backend and defaultAllow. ValidatingAdmissionPolicy uses CEL expressions to check fields such as image prefixes without a webhook. Policy engines like Kyverno or OPA Gatekeeper can enforce registries and verify cosign signatures. Referencing images by digest prevents tag swaps.
- How it shows up
- Expect to complete a half-configured ImagePolicyWebhook setup or write a policy that allows only one registry.
- Common confusion
- Assuming a tag like v1.2 is immutable; tags can be moved, while digests cannot.
5.4 Perform static analysis of user workloads and container images (e.g. Kubesec, KubeLinter)Scanning manifests and images before deployment.
- What it means
- Static analysis inspects artifacts without running them. For Kubernetes it covers manifests, Dockerfiles and container images, and it catches risky configurations and known vulnerabilities early.
- What to understand
- kubesec scan pod.yaml returns a score with critical and advisory items such as privileged or missing resource limits. kube-linter lint path checks manifests against built-in rules. trivy image --severity HIGH,CRITICAL name lists CVEs in an image, and trivy config scans manifests and Dockerfiles. Know how to read each output quickly and filter it.
- How it shows up
- A task names several Pods and asks you to remove those running images with critical vulnerabilities.
- Common confusion
- Scanning the image tag in the task text instead of the image the Pod actually runs.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Multi-stage build
A Dockerfile with separate build and runtime stages.
- Remember
- Only artifacts copied with COPY --from reach the final image.
- Tested as
- Primary way to shrink images in Dockerfile tasks.
- Trap
- Installing build tools in the final stage.
-
Distroless and scratch
Minimal bases without shells or package managers.
- Remember
- Smaller attack surface, but debugging needs ephemeral containers.
- Tested as
- Answer to 'reduce base image footprint'.
- Trap
- Assuming alpine is the smallest possible option.
-
Image digest
The sha256 identifier of exact image content.
- Remember
- image@sha256:... always pulls the same bytes.
- Tested as
- Prevents tag mutation attacks.
- Trap
- Pinning a tag and calling it immutable.
-
SBOM formats
SPDX and CycloneDX are the two common standards.
- Remember
- bom generates SPDX; Trivy can produce either.
- Tested as
- Generation tasks specify the format.
- Trap
- Producing JSON in the wrong schema.
-
ImagePolicyWebhook
Admission plugin that asks a backend whether images are allowed.
- Remember
- Needs plugin enabled, admission config file, backend kubeconfig and mounts.
- Tested as
- A long multi-file exam task.
- Trap
- Forgetting the volume mount for the config directory.
-
defaultAllow
ImagePolicyWebhook setting for when the backend fails.
- Remember
- false denies Pods if the webhook is unreachable.
- Tested as
- Tasks often require fail-closed behaviour.
- Trap
- Leaving it true, which fails open.
-
Trivy severity filter
Limits output to selected CVE severities.
- Remember
- trivy image --severity HIGH,CRITICAL image
- Tested as
- Matches typical task thresholds.
- Trap
- Reading total counts instead of the filtered severities.
-
Kubesec score
Numeric rating of a manifest with critical findings listed.
- Remember
- Critical items such as privileged lower the score sharply.
- Tested as
- Tasks ask you to fix findings until a score or check passes.
- Trap
- Treating advisory items as failures.
-
Cosign signatures
Sigstore signatures stored alongside images in the registry.
- Remember
- Verification happens with cosign verify or an admission policy.
- Tested as
- Answers 'sign and validate artifacts'.
- Trap
- Thinking a registry login proves image authenticity.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Static analysis tools
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Trivy | Scans images, filesystems and configs for CVEs and misconfigurations | Matches packages to vulnerability databases | Expecting it to score manifests the way Kubesec does |
| Kubesec | Scores Kubernetes manifests for security risk | Gives a numeric score and critical items | Using it on container images |
| KubeLinter | Lints manifests and Helm charts against rules | Reports check names with remediation | Expecting CVE results from it |
Ways to restrict images at admission
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| ImagePolicyWebhook | Built-in plugin calling an external image policy service | Configured with API server flags and files | Missing defaultAllow false when fail-closed is required |
| ValidatingAdmissionPolicy | Built-in CEL rules evaluated in the API server | No external service needed; needs a binding | Creating the policy without a ValidatingAdmissionPolicyBinding |
| Policy engine | Kyverno or Gatekeeper running as admission webhooks | Can verify signatures and mutate | Assuming it works while its webhook Pods are down |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Fail-open admission
- What candidates pick
- Keeping defaultAllow true in the ImagePolicyWebhook config.
- Why it looks right
- It is the value in many examples.
- Why it's wrong
- If the backend is unreachable, every image is admitted, which defeats the control.
Clue to watch for A task stating Pods must be denied when the backend is unavailable.
-
Wrong image source
- What candidates pick
- Scanning image names copied from a Deployment file on disk.
- Why it looks right
- The file is right there in the task directory.
- Why it's wrong
- Running Pods may use different tags; the grader checks the images actually deployed.
Clue to watch for A task saying 'Pods currently running in namespace X'.
-
Leftover secrets in layers
- What candidates pick
- Adding RUN rm secret.txt after copying it.
- Why it looks right
- The file disappears from the final filesystem view.
- Why it's wrong
- Earlier layers still contain the file, and anyone with the image can extract it.
Clue to watch for A Dockerfile that COPYs credentials.
-
Misread severity
- What candidates pick
- Deleting every Pod whose image shows any CVE.
- Why it looks right
- Removing all vulnerable images seems safest.
- Why it's wrong
- The task sets a threshold, and deleting compliant workloads fails grading.
Clue to watch for Explicit wording such as HIGH or CRITICAL only.
-
Tag trust
- What candidates pick
- Accepting nginx:1.27 as a pinned, trusted reference.
- Why it looks right
- A version number looks fixed.
- Why it's wrong
- Tags can be re-pushed to new content; only a digest guarantees the same image.
Clue to watch for Requirements mentioning immutable or verified images.
Answer framework
Use this flow for any task that evaluates or restricts images and manifests.
- Collect the real inputs: images from kubectl get pods -o jsonpath, manifest paths and Dockerfiles named in the task.
- Run the right tool for each input, Trivy for images, Kubesec or KubeLinter for manifests, and filter by the stated severity or rule.
- Record which items fail the threshold before changing anything, so deletions or edits target only those items and nothing else.
- Apply the fix: delete or update workloads, edit the Dockerfile, or wire the admission control files, flags and volume mounts.
- Confirm by rescanning, rebuilding the image, or creating a test Pod from a disallowed registry and checking it is rejected.
Practice question
Want more like this? The CKS practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Install Trivy, Kubesec, KubeLinter and bom on a lab machine before anything else, because fluency with their output is most of this domain. Scan a handful of old and new public images, compare severities, and practise selecting only those over a threshold. Export a few Pod specs and run Kubesec until you can predict which settings lower the score.
Next, rebuild a simple application three ways: a single-stage image on a full base, a multi-stage image on alpine, and a distroless image with a non-root user. Compare sizes and Trivy results. Generate an SBOM for each with bom and with Trivy so both commands are familiar.
Save the most time for admission control. Configure ImagePolicyWebhook on a kubeadm cluster using the kubernetes.io admission controller page, test it with the backend down to see fail-open and fail-closed behaviour, then write a ValidatingAdmissionPolicy that permits a single registry prefix. Keep notes of the exact flags and file paths you used for later revision.
FAQ
How much of the CKS exam is Supply Chain Security?
Supply Chain Security accounts for 20% of the score in the official curriculum, so plan on three or four tasks that use scanning, SBOM and admission tools.
Which scanning tools should I learn?
The competency names Kubesec and KubeLinter for static analysis, and Trivy is widely used for image CVE scanning. Learn their basic commands and how to filter output, since the exam host provides the tools a task needs.
Is Trivy documentation allowed during the exam?
The Linux Foundation allowed list for CKS does not include Trivy's site, so rely on trivy --help. The bom CLI reference is allowed, and tasks may add Quick Reference links.
Do I need to know cosign commands?
The competency mentions signing and validating artifacts. Knowing cosign sign and cosign verify conceptually, and how admission policies enforce signatures, is reasonable preparation; deep key management is unlikely.
What is the difference between ImagePolicyWebhook and ValidatingAdmissionPolicy?
ImagePolicyWebhook is a built-in plugin that delegates image decisions to an external service. ValidatingAdmissionPolicy evaluates CEL expressions inside the API server and needs no external service.
Will I have to build container images on the exam?
Some tasks involve editing a Dockerfile and possibly building with a tool on the host. Practise the edit itself, and read the task for whether a build or push is required.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
Practise scan-and-act, Dockerfile and admission control tasks under realistic time pressure to confirm your supply chain skills are ready.