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.

• ✓

  Scan images for vulnerabilities in a CI pipeline before deploying.

  Why this is correct

  Scanning images for known vulnerabilities in CI, using tools like Trivy or Grype, catches flaws in OS packages and language dependencies before they reach production. Integrate these scans with policy checks that fail the build on critical or high severity CVEs, and also rescan base images on a schedule, since new vulnerabilities are disclosed after the image is built. This is a reactive measure against known issues, distinct from verifying who built the image or that it hasn't been altered.

• ✓

  Use image signing and verification (e.g., with cosign) to ensure image integrity.

  Why this is correct

  Image signing with cosign cryptographically binds the image manifest to a key held by the publisher, proving identity and origin. Verify the signature in the Kubernetes cluster using an admission controller, such as Kyverno or OPA Gatekeeper, to reject unsigned or tampered images; consider holding keys in a KMS like Vault or AWS KMS. Signing addresses integrity and provenance, whereas vulnerability scanning only identifies known flaws, not whether the artifact is authentic.

• ✗

  Embed API keys directly in container images for authentication.

  Why it's wrong here

  Baking API keys into container images is dangerous because images are immutable and often shared via registries; any user with pull access can extract secrets by unpacking layers. Secrets also leak from intermediate build layers, so even removing them later in the Dockerfile doesn't remove them from the final image. Instead, mount secrets at runtime via Kubernetes Secrets, a sidecar, or a tool like External Secrets Operator, and rotate them regularly.

• ✗

  Allow all images from any registry without verification to speed up development.

  Why it's wrong here

  Allowing images from any registry without verification removes a key trust boundary, letting attackers push malicious or vulnerable images that then execute with the service account's privileges. Without an allowlist, admission control, and signature verification, you cannot establish provenance or know who built the artifact and from what source. This practice increases the attack surface from a single compromised or malicious registry to the entire internet, and undermines any supply chain security investments.

• ✗

  Use mutable tags like 'latest' for easier updates.

  Why it's wrong here

  Using mutable tags like 'latest' means a tag can be overwritten, making it impossible to audit or rollback to the exact code that ran historically, because the tag no longer points to the same digest. An attacker can also overwrite a mutable tag to point to a compromised image, and the cluster would pull it on the next restart. Reproducible deployments require immutable tags derived from commit SHAs or explicit image digests (sha256:...), and you should refer to the digest for immutable deployments.

Go deeper

Related to this question