Skip to content

Security Supply Chain

← Back to all decks

12 cards — 🟢 3 easy | 🟡 5 medium | 🔴 4 hard

🟢 Easy (3)

1. What is an SBOM and what are the two main formats?

Show answer An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in an artifact: libraries, versions, and licenses. The two main formats are SPDX (Linux Foundation standard) and CycloneDX (OWASP standard). SBOMs let you answer "does this image contain log4j?" in seconds rather than days.

2. How do you scan a container image for vulnerabilities using grype?

Show answer Run "grype ghcr.io/org/myapp:v1.2.3" to scan an image against CVE databases. Use "--fail-on high" to fail CI on high/critical vulnerabilities. Output JSON with "-o json" and filter for critical issues with jq. You can also scan from an SBOM: "grype sbom:./sbom.spdx.json" for faster repeated scans.

3. What cosign command verifies a signed container image and what flags constrain trust?

Show answer Use "cosign verify" with --certificate-identity-regexp (constrains which identity signed it, e.g., a GitHub Actions workflow path) and --certificate-oidc-issuer (constrains which OIDC provider issued the token, e.g., https://token.actions.githubusercontent.com). Both flags together establish a chain of trust: the image was signed by a specific CI pipeline.

🟡 Medium (5)

1. What is SLSA and what do its levels guarantee?

Show answer SLSA (Supply-chain Levels for Software Artifacts) is a graduated security framework with Levels 1-3. Higher levels provide stronger guarantees: Level 1 requires build provenance documentation, Level 2 requires a hosted build service, Level 3 requires a hardened build platform with non-falsifiable provenance. Each level increases confidence that an artifact was built from claimed source by a trustworthy system.

2. How does cosign sign container images in keyless mode?

Show answer In keyless mode, cosign uses OIDC identity (e.g., GitHub Actions' OIDC token) instead of a static key pair. The CI system proves its identity to Sigstore's Fulcio CA, receives a short-lived signing certificate, signs the image by digest, and records the signature in the Rekor transparency log. Consumers verify using the OIDC issuer and identity constraints.

3. What is Rekor and what role does it play in Sigstore?

Show answer Rekor is Sigstore's immutable transparency log that records all signing events. When an artifact is signed with cosign, the signature and metadata are logged in Rekor, creating a tamper-evident audit trail. Anyone can search Rekor to verify when and by whom an artifact was signed, providing non-repudiation even for keyless signatures.

4. How does Kyverno enforce container image signature verification in Kubernetes?

Show answer Kyverno is a Kubernetes admission controller that evaluates policies before pods are created. A ClusterPolicy with verifyImages rules checks that images matching specified patterns (e.g., "ghcr.io/org/*") have valid cosign signatures from authorized identities. If an unsigned or improperly signed image is deployed, the admission webhook denies the pod creation.

5. How do you generate and attach an SBOM to a container image?

Show answer Generate an SBOM with syft: "syft ghcr.io/org/myapp:v1.2.3 -o spdx-json > sbom.spdx.json" (or -o cyclonedx-json for CycloneDX). Attach it as an OCI artifact with "cosign attach sbom --sbom sbom.spdx.json ghcr.io/org/myapp:v1.2.3". Consumers can then verify the SBOM attestation with "cosign verify-attestation --type spdxjson".

🔴 Hard (4)

1. What is an in-toto attestation and how does it differ from a simple signature?

Show answer An in-toto attestation binds a subject (artifact digest) to a structured predicate (build provenance, vuln scan results, SBOM). While a simple signature only proves who signed, an attestation also proves how the artifact was produced, what tests passed, and what components it contains. Policy engines like Kyverno can enforce rules based on attestation predicates.

2. What is a dependency confusion attack and how do you prevent it?

Show answer Dependency confusion exploits package managers that check public registries before private ones. An attacker publishes a higher-versioned package with the same name as an internal package to a public registry (npm, PyPI). The build system then pulls the malicious public version. Prevent it by configuring scoped registries, pinning exact versions, using lockfiles, and setting up registry priority rules.

3. How do you generate SLSA Level 3 provenance in GitHub Actions?

Show answer Use the slsa-framework/slsa-github-generator reusable workflow. In your release workflow, build and push the image, capture its digest, then call the generator workflow with the image and digest as inputs. The workflow requires id-token: write permission for keyless signing. Verify locally with "cosign verify-attestation --type slsaprovenance".

4. How can OPA Gatekeeper be used for image verification as an alternative to Kyverno?

Show answer OPA Gatekeeper uses ConstraintTemplates with Rego policy language to define image verification rules. While Kyverno has built-in verifyImages, Gatekeeper requires custom Rego logic or external data (e.g., calling a verification webhook). Kyverno is simpler for image signing use cases, but Gatekeeper offers more flexible general-purpose policy expression.