CKS Supply Chain Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Run containers as root to ensure all permissions are available

  Why it's wrong here

  Running as root inside a container maps to the root user on the host when privilege escalation is not explicitly restricted; combined with the default capabilities (e.g., CAP_DAC_OVERRIDE, CAP_SYS_ADMIN), a compromised root process could leverage a kernel vulnerability to break out of the container and gain host-level access. The principle of least privilege demands that containers run as an unprivileged user (via USER directive), with capabilities dropped and root filesystem mounted read-only, to limit the blast radius of any intrusion.

• ✗

  Use the 'latest' tag for base images to get the latest features

  Why it's wrong here

  The 'latest' tag is a mutable pointer that changes without warning, so a build that works today may pull a different base image tomorrow, introducing unexpected library changes or newly discovered vulnerabilities while breaking the reproducibility required for secure supply chain management. Pinning to a specific image digest (e.g., imagename@sha256:...) or a versioned tag with a digest ensures the exact same filesystem content is used across all builds and environments, allowing thorough security scanning and controlled updates rather than surprise changes.

• ✓

  Use distroless base images to minimize the attack surface

  Why this is correct

  Distroless base images contain only the minimal runtime libraries and timezone data necessary to execute the application, with no shell, package manager, or other utilities that an attacker could use for post-exploitation; this dramatically reduces the attack surface because many privilege-escalation and lateral-movement techniques rely on tools like curl, wget, or a shell that are simply absent. However, this also means debugging directly inside the container is harder, so distroless images should be paired with robust structured logging and centralized observability to maintain visibility without sacrificing a minimal, hardened runtime footprint.

• ✗

  Embed secrets directly in the Dockerfile for easy access

  Why it's wrong here

  Embedding secrets in a Dockerfile, whether through ENV, ARG, or COPY, places them in permanent image layers and the image README/metadata; anyone who can pull or inspect the image can extract those secrets using 'docker history' or 'docker save', and they may also be leaked indirectly through registry push logs or CI build logs. Secrets must instead be injected at runtime from secure external sources—such as Kubernetes Secrets, Docker secrets, or a vault service—and referenced in the container environment, ensuring the secret never persists in the image artifacts themselves.

Go deeper

Related to this question