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.

• ✗

  Hardcode passwords in Dockerfile as environment variables for convenience

  Why it's wrong here

  Hardcoding passwords as environment variables in the Dockerfile stores secrets directly in image layers, making them extractable by anyone with access to the image, even after deployment. Additionally, these environment variables are visible to any process inside the container and can be leaked through logs or debugging interfaces. Secret values should instead be injected via Kubernetes Secrets, mounted at runtime, or passed through a secrets manager, never baked into the image. This practice violates the principle of least privilege and fails to separate configuration from immutable image content.

• ✓

  Use minimal base images like distroless or Alpine

  Why this is correct

  Minimal base images like distroless or Alpine drastically reduce the attack surface by containing only the essential libraries and binaries needed to run the application, eliminating package managers, shells, and other utilities that attackers could exploit. This reduces both the number of known Common Vulnerabilities and Exposures (CVEs) and the potential for privilege escalation through less hardened components. Distroless images go further by having no shell or package manager, making them immutable and harder to compromise at runtime, while Alpine provides a small footprint and a package manager for easier dependency management. Choosing a minimal base is a foundational step in a defense-in-depth strategy.

• ✗

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

  Why it's wrong here

  Using the 'latest' tag for base images makes builds non-reproducible, because the underlying image changes over time, so what worked today may break or behave differently tomorrow and may contain unpatched vulnerabilities depending on when it was pulled. The tag gives no guarantee of a specific version or patch level, and a CI/CD pipeline that caches it might inadvertently ship an image with known security issues. Best practice is to pin images to a specific digest (sha256) or at least a versioned tag so that builds are deterministic and security audits can verify exactly what is included. Additionally, 'latest' can be a moving target that introduces breaking changes or regressions without notice.

• ✗

  Run containers as root to simplify permission management

  Why it's wrong here

  Running containers as root grants the container process all Linux capabilities, meaning that any vulnerability leading to code execution immediately gives the attacker full control over the container, and can potentially escape to the host through misconfigurations or kernel exploits. Root privileges inside a container often map to root on the host unless user namespace remapping is explicitly configured, which is not a default in many orchestration environments. The principle of least privilege dictates that containers should run as a non-root user defined in the image's USER directive, with only the minimum required capabilities and read-only filesystems where possible. This reduces the blast radius of an attack and is a core CIS benchmark recommendation.

Go deeper

Related to this question