If you cannot prove where a container image came from and that it has not been tampered with, you are essentially running code from a stranger on your most critical systems. This is what Supply Chain Security: Container Image Security is about — validating the origin, integrity, and safety of every image before it ever touches your cluster. For the CKS exam, this is not abstract theory: you will be expected to configure image verification, set up admission controllers, and enforce policies that stop dangerous images at the door.
Jump to a section
A simple way to picture Supply Chain Security: Container Image Security
A busy fish market by the harbour at dawn.
Receiving a pallet of iced cod, the chef doesn't just put it in cold storage. First, she examines the crate's seal to confirm it came from the trusted supplier, not a poacher's skiff. She runs her thumb along the gills — red, not grey — and sniffs for any hint of ammonia. Only after this inspection does she sign the manifest. Inside her kitchen, she labels the fillets with the catch date and stores them in a locked, monitored fridge. Every hour, a junior chef checks the temperature log. If the ice melts or a package bulges, the whole batch is thrown out. They never mix wild-caught fish with farmed in the same crate, and they never take fish from a delivery whose history they cannot trace back to the vessel. When a customer later falls ill, the chef can pinpoint exactly which crate, which boat, and which net the contaminated fish came from. This entire ritual — verifying provenance, inspecting contents, controlling storage, and keeping a traceable chain — protects the market's reputation and the diners' health.
For a Kubernetes cluster, the container images are the fish, the registry is the supplier, and security scanning is the sniff test. The same discipline of trust, verification, and provenance tracking keeps malicious code out of production.
A container image is a lightweight, standalone, executable package that includes everything needed to run a piece of software: code, runtime, system tools, libraries, and settings. Think of it as a frozen, pre-cooked meal for a computer. You download an image from a registry (a storage location for images) like Docker Hub, then run it inside a container — a virtualised environment that isolates the process from the rest of the system.
Security starts with where the image comes from. A registry can be public (like Docker Hub or Google Container Registry) or private (inside your own organisation). Public images are convenient but risky — anyone can upload an image, and attackers routinely upload images containing malware, backdoors, or vulnerable libraries. This is called a 'supply chain attack' because you are trusting a foreign source to deliver safe code.
To mitigate this, you need several layers of security.
Image Signing and Verification
The first layer is digital signing. An image author uses a private cryptographic key to 'sign' the image, creating a digital signature. Anyone with the corresponding public key can verify that the image was indeed created by that author and has not been altered since. This is analogous to a tamper-evident seal on a food jar. The standard tool for this in the Kubernetes ecosystem is Cosign, part of the Sigstore project. You sign an image with a command like cosign sign <image>, and you verify it with cosign verify <image>.
Image Scanning The second layer is scanning the image's components for known vulnerabilities. A container image is built in layers on top of a base operating system (like Ubuntu or Alpine Linux). Each layer can contain software packages, and those packages have known security flaws indexed in databases (like the National Vulnerability Database). Scanning tools (e.g., Trivy, Clair, Anchore) inspect each layer, identify every package and its version, and report any vulnerabilities with a severity rating (Critical, High, Medium, Low). This gives you a risk score before you ever run the image.
Admission Control The third layer is enforcement at the Kubernetes cluster level. An admission controller is a piece of software that intercepts requests to create pods (the smallest deployable unit in Kubernetes) and checks them against policies before allowing them. For supply chain security, you use an admission controller like the Open Policy Agent (OPA) or Kyverno to enforce rules such as:
Only allow images from trusted registries.
Require that images have a valid signature.
Reject images with Critical vulnerabilities.
Require that images have been scanned within a certain timeframe.
Why It Exists and What It Replaces Earlier, organisations would simply pull images from the internet and run them without checks. That approach led to high-profile breaches where a malicious library introduced into a popular base image was pulled into thousands of customers' environments. Supply chain security replaces blind trust with a model of 'zero trust' — verify everything, trust nothing without proof.
Example Scenario A developer builds a Node.js app and pushes the image to the company's internal registry. The CI/CD pipeline automatically signs the image with the team's key and scans it with Trivy. The scan finds a High severity vulnerability in a logging library. The pipeline fails the build, and the developer must update the library to a patched version. Once the image is clean, it is promoted to a 'trusted' tag. When a pod tries to use that image in production, the admission controller checks the signature and the scan report. If either is missing or invalid, the pod is rejected and an alert is fired. This entire process ensures that only vetted, untampered code reaches production.
Choose and Harden Base Images
Start with a minimal, trusted base image like `gcr.io/distroless/base` or an official distro image pinned to a specific version. Remove unnecessary tools (shells, package managers) to reduce attack surface. This step ensures the foundation of your application is as small and secure as possible, leaving fewer potential vulnerabilities for attackers to exploit.
Build the Application Image and Create an SBOM
During the build process, generate a Software Bill of Materials (SBOM) — a machine-readable inventory of every component and library in the image. Tools like Syft can create this. An SBOM allows you to track exactly which versions of which packages are inside, making it possible to correlate against new vulnerabilities as they are disclosed.
Sign the Image with Cosign
After the image is built and tested, use `cosign sign` to apply a digital signature using a private key. This signature is attached to the image in the registry. Later, anyone with the corresponding public key can verify that this specific image came from your signing key and has not been altered. This step prevents tampering from the build server to the registry.
Scan the Image for Vulnerabilities
Run a vulnerability scanner like Trivy against the image. The scanner looks at every installed package and checks it against the CVE database. It outputs a report listing each vulnerability, its severity, and a fix version. If the scan finds Critical or High severity vulnerabilities, you should block the image from proceeding and return it to the developer for patching.
Push the Image to a Trusted Registry
Only push the signed and scanned image to a private registry that you control, such as Harbor or Amazon ECR with scanning enabled. Use immutable tags (e.g., the SHA256 digest) to ensure the exact image you validated is the one that gets pulled later. Avoid pushing to public registries for production workloads because you lose control over access and distribution.
Enforce Policies via Admission Controller
Configure an admission controller (Kyverno or OPA/Gatekeeper) with policies that check every pod creation request. The policies should verify the image's signature, confirm it came from an allowed registry, and check that a recent scan report exists with no prohibited vulnerabilities. If any condition fails, the pod is rejected and an alert is raised. This step is the final gate before the image runs in your cluster.
An IT professional responsible for Kubernetes security, often called a platform engineer or security engineer, implements a container image security programme step by step.
Step 1: Define a Secure Base Image Policy
The engineer first decides which base images are allowed. They might create a curated list of approved base images, such as gcr.io/distroless/base (a minimal, hardened image with no package manager) or ubuntu:22.04 patched to a specific version. They codify this in a policy that any image must have its base listed in an allowlist. They also set a rule that images must not use 'latest' tags, because those tags move and introduce unknown content.
Step 2: Automate Image Signing in CI/CD
The engineer configures the CI/CD pipeline (e.g., Jenkins, GitLab CI) to run cosign sign on every built image, using a private key stored in a secure vault like HashiCorp Vault or cloud KMS. The public key is stored where admission controllers can retrieve it. The pipeline also runs a vulnerability scan via a tool like Trivy. If vulnerabilities above a threshold (e.g., Critical or High) are found, the pipeline fails the build. Only images that pass both scanning and signing are pushed to the production registry.
Step 3: Configure Admission Controller Rules The engineer writes OPA or Kyverno policies that run on every pod creation request. Typical rules include:
Check that the image registry is in the approved list (e.g., my-registry.internal.io).
Verify the image has a valid Cosign signature using the stored public key.
Check that the image has a scan result newer than 24 hours with no Critical vulnerabilities.
Reject images with 'latest' tag.
Step 4: Monitor and Respond The engineer sets up monitoring on the registry and admission controller logs. When a violation occurs — for example, a developer tries to pull an image from the public Docker Hub without approval — the admission controller rejects the pod and logs the event. The engineer receives an alert and investigates. They might temporarily block the offending namespace or revoke the developer's access to push images.
Step 5: Audit and Update Every month, the engineer reviews the approved base images list. New vulnerabilities are discovered daily, so old base images need to be rebuilt with patches. The engineer triggers a rebuild of all images using a vulnerable base, re-signs them, and re-scans them. They also update the admission policies if the threat landscape changes (e.g., adding a new registry for a trusted partner).
Tools in Use - Trivy (scanning) - Cosign (signing and verification) - Kyverno or OPA / Gatekeeper (admission control) - Docker Content Trust or Notary (older signing mechanisms) - Private registries like Harbor (with built-in scanning and vulnerability reporting)
This process — policy definition, automated verification, enforcement, and continuous auditing — is the day-to-day reality of container image security in a professional setting.
The CKS exam explicitly tests your ability to secure the container supply chain. Expect scenario-based questions where you must choose the correct tool and configuration to verify image integrity or enforce registry policies. Here is what they specifically test:
Key Concepts You Must Memorise
Image signing: You need to know how to sign an image with Cosign and how to verify it. The exam will give you scenarios where you must choose the command that verifies an image's signature. The correct answer is usually cosign verify --key <public-key> <image-url>.
Admission controllers: You must understand that Kyverno and OPA/Gatekeeper are used to enforce policies at pod creation time. A typical question: 'You want to block any pod that uses an image from a registry not in an allowlist. Which admission controller policy would you write?' Correct answer: a policy that checks spec.containers[*].image against a predefined list.
Image scanning: You need to know that scanning tools (Trivy, Clair, Anchore) check for CVEs (Common Vulnerabilities and Exposures). The exam will ask what to do when a scan finds a Critical vulnerability — answer: block the image from running or rebuild it with a patched library.
Common Traps and Misleading Answers
Trap: Using TLS/SSL as a security measure for images. The exam might offer 'use HTTPS' as the sole security measure. HTTPS secures the transport channel but does not verify image content. The correct answer will involve signing and verification.
Trap: Restricting only the registry but not verifying signatures. A rule that allows only images from my-registry.io is not enough if an attacker compromises that registry. Signatures prove image authorship beyond the registry.
Trap: Assuming 'latest' tag is safe. The exam loves to present a scenario where a pod uses image:latest. The correct answer is to use a specific immutable tag (e.g., SHA256 digest) or a version tag.
Trap: Ignoring base images. The exam will test whether you understand that base images are the foundation. A question might ask: 'Your image uses ubuntu:latest as a base. What is the risk?' Answer: the base may contain unpatched vulnerabilities, and the tag moves.
Question Types
Multiple-choice scenario: 'A developer pushes an image to a private registry. Which step ensures the image has not been tampered with since it was built?' Answer: signing the image with Cosign.
Fill-in-the-blank: 'The tool _________ is used to verify the digital signature of a container image.' Answer: Cosign.
Ordering steps: 'Put the following steps in the correct order to ensure image security: a) scan image, b) sign image, c) run admission controller, d) push to registry.' Correct order: a, b, d, c.
Policy writing: You may be asked to interpret a Kyverno or OPA policy. Know the basic structure: match (which resources to apply to), validate (the rule), and deny (what to block).
Exact Concepts They Love to Test
Cosign signing and verification commands
Kyverno validate.deny rules for registry and tag
OPA/Gatekeeper ConstraintTemplates and Constraints
Image vulnerability severity levels (Critical, High, Medium, Low) and their meaning
The concept of a Software Bill of Materials (SBOM) — a list of all components in an image — though less common, it appears
The difference between static analysis (scanning layers) and dynamic analysis (running the container)
To pass, you must be able to describe the flow from build to run and identify exactly where each security control fits. Practise with hands-on labs using Cosign, Kyverno, and Trivy until the commands are second nature.
A container image is a frozen software package that includes code, runtime, libraries, and settings, and it must be verified for origin and integrity before being run.
Image signing with a tool like Cosign ensures the image has not been tampered with and came from a known, trusted author.
Image scanning (using Trivy, Clair, or Anchore) identifies known vulnerabilities (CVEs) in the image's software components and assigns a severity rating.
Admission controllers (such as Kyverno or OPA/Gatekeeper) enforce policies at pod creation time to reject images that fail security checks.
You should never use the 'latest' tag in production because it is mutable and can silently change the image deployed; always use a specific digest or version tag.
Supply chain security in Kubernetes replaces blind trust with a zero-trust model: verify every image's signature, scan its components, and enforce policies automatically.
These come up on the exam all the time. Here's how to tell them apart.
Image Signing (Cosign)
Verifies authorship and content integrity using cryptographic keys
Does not identify specific software vulnerabilities
Prevents tampering during transit or at rest in the registry
Image Scanning (Trivy)
Checks each software package against a known vulnerability database
Does not verify who created the image or if it has been altered
Identifies outdated or vulnerable libraries that need updating
Admission Controller (Kyverno)
Runs at pod creation time before the container starts
Enforces policies on image metadata (registry, tag, signature)
Is part of the Kubernetes control plane, not inside the container
Runtime Security (Falco)
Runs continuously after the container is already running
Monitors system calls for suspicious behaviour like privilege escalation
Is deployed as a daemonset and observes container activity from the host
Immutable Tag (Digest)
Points to an unchanging snapshot of the image content
Guarantees reproducibility across deployments and environments
Allows audit trails to be precise — you know exactly what ran
Mutable Tag (latest)
Can be overwritten to point to a different image at any time
Makes it impossible to know exactly what version ran yesterday
Commonly used in development but dangerous for production security
Mistake
If I use a private registry, I do not need to sign images because only my team can push to it.
Correct
A private registry authenticates at the push level, but it does not verify the content of the image itself. If an attacker compromises a developer's machine or pushes a malicious build via a compromised CI pipeline, the registry accepts it. Signing verifies that the image originated from a specific trusted key, regardless of how it was uploaded.
People confuse authentication (who can push) with integrity (what got pushed). They think controlling access to the registry is sufficient, but it ignores the possibility of a compromised user or pipeline.
Mistake
Scanning for vulnerabilities once when the image is built is enough for production security.
Correct
Vulnerabilities are discovered daily. An image that was clean at build time may become vulnerable hours or days later when a new CVE is published for a library inside it. Continuous scanning — re-scanning the image at regular intervals and before deployment — is necessary, as is rebuilding images when base images are patched.
Beginners think of security as a one-time checkpoint, not an ongoing process. They do not realise the vulnerability database is constantly updated, so yesterday's clean image is today's risk.
Mistake
Using the 'latest' tag is fine as long as I have a scan report.
Correct
The 'latest' tag is mutable — it can point to different images over time. A scan you run today may apply to a different image than the one you run next week. Even if you scan 'latest' each time, you have no guarantee of reproducibility. Always use an immutable digest (e.g., `image@sha256:...`) or a fixed version tag.
People are used to the convenience of 'latest' from local development and think scanning compensates for the tag's instability. They do not understand that tags are pointers, not content identifiers.
Mistake
Admission controllers can block images based on vulnerability severity alone, without needing a scan report.
Correct
An admission controller cannot 'see' inside an image's layers to know its vulnerabilities. It can only check metadata like the image digest, signature, or registry URL. To block on vulnerabilities, you must first have a scan result (stored somewhere, e.g., in a metadata annotation or a policy engine data source) and then write a policy that checks that result. The admission controller itself is not a scanner.
It is easy to assume admission controllers have scanning capabilities built in, but they are policy enforcers, not scanners. Beginners conflate the two roles.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A container image signature is a cryptographic stamp that proves a specific image was created by a specific person or system. You need it to ensure the image has not been tampered with between build and deployment. Without a signature, any attacker who gains write access to your registry could modify the image, and you would not know.
You use an SBOM generation tool (like Syft or Trivy with the `--sbom` flag) to create a Software Bill of Materials that lists every package, its version, and its licence. This is like a recipe for the image. You can also use a scanner such as Trivy which both identifies packages and checks them for vulnerabilities.
It is strongly discouraged. Public registries are open to anyone to upload images, so you risk pulling an image that contains malware or that has been tampered with. For production, you should use a private registry that you control, with access control and scanning capabilities enabled.
An immutable tag always points to the same image content, typically by using the image's SHA256 digest (e.g., `myimage@sha256:abcdef...`). Unlike `latest` which can change, an immutable tag guarantees that every time you pull that reference, you get the exact same bits. This is essential for reproducibility and security auditing.
Both are tools for signing and verifying container images, but Cosign is newer and part of the Sigstore project. Docker Content Trust uses Notary under the hood and requires running a separate Notary server. Cosign is simpler: it stores signatures directly in the registry, works with any OCI-compliant registry, and is the recommended tool for CKS.
An admission controller does not scan the image itself. Instead, you run a separate scanning tool (e.g., Trivy) in your CI/CD pipeline, and you store the scan result, often as metadata in the registry or in an external database. Your admission policy then checks that metadata — for example, by requiring an annotation with a recent scan date and a severity threshold. If the annotation is missing or indicates a Critical vulnerability, the policy denies the pod.
You've finished Supply Chain Security: Container Image Security. Continue through the CKS study guide to build a complete picture of the exam.
Done with this chapter?