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.

• ✗

  Use a runtime security tool like Falco to detect exploitation attempts.

  Why it's wrong here

  Falco is a runtime security tool that generates alerts when containers exhibit suspicious behavior, such as spawning a shell or accessing unexpected files. However, detection alone does not remediate the vulnerability; the vulnerable package remains in the running image and an attacker can still exploit it before an alert triggers a response. Furthermore, relying on Falco presupposes that detection rules are comprehensive and continuously updated, which is not a substitute for eliminating the vulnerable dependency at the source.

• ✗

  Patch the vulnerability by installing a security update inside the running container.

  Why it's wrong here

  Installing a security update inside a running container modifies only the container's writable layer, which is ephemeral and will be lost as soon as the container is restarted or replaced. This approach also introduces configuration drift, making the container's state inconsistent with the image definition and the rest of the cluster. The underlying image in the registry remains vulnerable, so every future instance spun from that image will still be exposed. A proper fix requires rebuilding the image from a patched base image so the vulnerable layer is replaced permanently.

• ✗

  Add an admission controller that rejects images with vulnerabilities.

  Why it's wrong here

  An admission controller that blocks images with known vulnerabilities stops them from being deployed in the cluster, but it does not address the fact that the vulnerable image still exists in the container registry and could be pulled and run in other environments. This is a reactive, policy-based control that depends on an up-to-date vulnerability database and can be bypassed if the scan results are stale or the controller is misconfigured. The root cause lies in the image build process—using an outdated base image or failing to update dependencies—which must be fixed by rebuilding the image and scanning during CI/CD.

• ✓

  Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.

  Why this is correct

  Rebuilding the image from a patched base image directly eliminates the vulnerable package from the image filesystem, ensuring that the vulnerability is no longer present in the artifact itself. Integrating vulnerability scanning into the CI pipeline shifts security left, allowing teams to detect and block vulnerable images before they are pushed to a registry or deployed. This approach is sustainable and reproducible, as every build is validated and known vulnerabilities trigger a pipeline failure, forcing developers to update dependencies promptly. It addresses the source of the issue rather than applying after-the-fact controls.

• ✗

  Switch to a different container runtime that is immune to the vulnerability.

  Why it's wrong here

  The vulnerability resides in the container image's layers—specifically, the packaged software and libraries—not in the container runtime that executes the image. Switching from containerd to CRI-O, or to any other runtime, does not change the image content; the vulnerable package will still be present and can be exploited just the same. While a different runtime might offer different security features (e.g., seccomp or SELinux), those do not render the image 'immune' to the known vulnerability. Therefore, this action is ineffective because the attack surface remains unchanged at the image level.

Go deeper

Related to this question