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.

• ✓

  Signing the image with Cosign and verifying the signature before deployment

  Why this is correct

  Cosign image signing, backed by Sigstore, creates a cryptographic signature bound to the image digest and the signer's identity (such as an OIDC email). Verifying that signature before deployment confirms both that the image content is unmodified and that it came from an approved publisher, making it a true provenance and tamper-evidence check. Without this step, an attacker who compromises a registry can swap a signed-looking tag for a malicious image and the cluster would have no way to detect the substitution.

• ✗

  Running the container in a separate namespace

  Why it's wrong here

  A Kubernetes namespace provides logical isolation for resources, RBAC, quotas, and network policies, but it does not inspect or validate the contents of container images. Running a container in a separate namespace does not prevent a compromised or tampered image from executing; it merely limits which cluster resources that container can see or affect. Namespace isolation is a control for blast radius and multi-tenancy, not an integrity or authenticity verification mechanism.

• ✓

  Using a SHA256 digest instead of a tag in the image reference

  Why this is correct

  Referencing an image by its SHA256 digest pins the deployment to a single, immutable manifest computed from the exact layer contents, so any change to the image produces a different digest and the image pull fails. This prevents tag-mutability attacks where the 'latest' tag is repointed to an unexpected or malicious image, giving you a reproducible and content-addressable image reference. However, a digest alone proves only that content is unchanged; it does not prove who created it, so it is often paired with a signature for full provenance.

• ✗

  Scanning the image for vulnerabilities using Trivy

  Why it's wrong here

  Trivy and similar vulnerability scanners inspect installed package versions against known CVE databases to find security flaws, but they perform no cryptographic verification of the image's origin or integrity. A maliciously modified image could pass a scan entirely if its payload has no known vulnerabilities, and a legitimate image could fail due to outdated libraries. Scanning is a valuable part of runtime security hygiene, but it is not a substitute for verifying that the image is what an authorized publisher intended to ship.

• ✗

  Using a base image with the latest tag

  Why it's wrong here

  Using a base image with the 'latest' tag is not a verification technique; 'latest' is a mutable pointer that can be overwritten by the image author or an attacker who compromises the registry, so the same tag may resolve to different image contents over time. This makes deployments non-reproducible and lets a previously validated image silently become an untrusted one without any change to the manifest reference. Image verification requires an immutable reference or a cryptographic signature, and 'latest' actively works against both.

Go deeper

Related to this question