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.

• ✓

  To list all open source and third-party components in an image

  Why this is correct

  An SBOM (Software Bill of Materials) is a formal, machine-readable inventory that enumerates all open source and third-party components, their exact versions, and dependency relationships inside a container image. Its primary purpose is to provide transparency and traceability for software supply chain security, enabling vulnerability correlation, license compliance, and provenance verification. Without an SBOM, you cannot systematically identify which component is affected by a newly disclosed CVE or audit what third-party code actually ships in production.

• ✗

  To scan images for secrets

  Why it's wrong here

  Scanning container images for secrets is a distinct security control performed by dedicated tools (e.g., Trivy, Snyk, or git-secrets) that search filesystem layers for hardcoded credentials, API keys, and private certificates. An SBOM does not inspect file contents or look for sensitive data; it only catalogs software component metadata already declared during the build. Treating SBOM generation as a secret scanner creates a false sense of security, because leaked tokens would never be listed in a bill of materials.

• ✗

  To sign container images

  Why it's wrong here

  Container image signing is a cryptographic operation, typically using tools like cosign or sigstore, that creates a digital signature bound to an image digest to verify its integrity and publisher identity. An SBOM is not a signature; it is a declarative document that lists components, and it can be signed separately (e.g., as an attestation) but its purpose is inventory, not authenticity. Confusing these two mechanisms ignores that signing proves who built the image, while an SBOM proves what is inside it.

• ✗

  To enforce network policies

  Why it's wrong here

  Network policies in Kubernetes are implemented as NetworkPolicy resources that control pod-to-pod or pod-to-service traffic based on labels, IP addresses, and ports, enforced by the CNI plugin. An SBOM has no relationship to traffic flow or cluster networking; it is a software artifact that describes dependencies for supply chain analysis. Assigning the role of network policy enforcement to an SBOM conflates runtime network layer controls with build-time component transparency, which are entirely different domains.

Go deeper

Related to this question