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.

• ✗

  Implement network policies to restrict egress from pods to the registry.

  Why it's wrong here

  Network policies operate at the network layer, filtering traffic based on IP addresses, ports, and labels; they cannot inspect the contents or provenance of container images. Restricting egress to the registry only limits where pods can connect, not which images are allowed to run, so a malicious image already pulled and launched would remain unaffected. Admission-time verification of signed attestations is required to establish trust in image provenance before a workload is scheduled.

• ✗

  Grant registry write access only to the CI system's service account.

  Why it's wrong here

  Granting registry write access solely to the CI system's service account follows least privilege, but it still leaves the CI pipeline as a single point of failure. If an attacker compromises the CI system—for example, via a malicious dependency or stolen credentials—they can push arbitrary images to the registry, and the cluster will blindly run them. This control reduces the attack surface but provides no cryptographic proof that the images were built by the intended, unmodified pipeline.

• ✗

  Use a static analysis tool to check the Dockerfile before building.

  Why it's wrong here

  Static analysis of a Dockerfile examines the declared build steps, such as base images and RUN commands, but it cannot inspect the fully built image or its layers. Problems like a vulnerable base image that is pulled at build time, a compromised package repository, or a tampered build cache will not be detected by Dockerfile linting alone. Such tools are useful for security hygiene but do not create verifiable evidence of the image's origin or content.

• ✗

  Use a unique registry path and restrict access via firewall rules.

  Why it's wrong here

  Using a unique registry path and firewall rules provides access control based on network location and obscurity, but it does not ensure that images pushed to that path are legitimate. If the CI credentials or a developer's token are stolen, the attacker can push a malicious image to that same path, and the firewall will allow it because it originates from a permitted network. This approach cannot detect or prevent tampering; it only reduces the chance of outside access.

• ✓

  Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.

  Why this is correct

  In-toto attestations are cryptographically signed metadata generated during the CI pipeline that describe the build steps, materials, and results, providing non-repudiation for the image's origin. An admission webhook such as Kyverno can be configured to verify these signatures and attestations at admission time, ensuring that only images produced by the trusted pipeline and with valid provenance are allowed to run. This combination enables robust supply-chain security by tying the runtime state to an auditable, tamper-evident build process.

Go deeper

Related to this question