Supply Chain Security

TL;DR

• Everything else in supply chain security — vulnerability response, provenance verification, tamper detection — depends on first having a structured, accurate inventory of what is actually in an artifact.
• An SBOM turns “which services run this vulnerable dependency” from a multi-week manual investigation into a fast query.
• Syft generates SBOMs; Cosign signs artifacts (images and SBOMs) so tampering after build is detectable — generation and signing are distinct, complementary steps.
• SLSA defines graduated levels of supply chain rigor rather than a single pass/fail bar, so organizations can target a level matched to their risk profile.
• Biggest gotcha: supply chain checks only prevent anything if they are blocking CI/CD gates — run as informational scans reviewed later, a compromised artifact can already be in production before anyone looks.

Core Concepts

SBOM (Software Bill of Materials)

A structured, machine-readable inventory of every dependency (direct and transitive) in a given build, at a specific version. Its operational value shows up during the scenario every security team dreads: a newly-disclosed critical CVE in a widely-used library, and the urgent question “which of hundreds of production services depend on that vulnerable version.” With SBOMs generated for every build, this becomes a fast, direct query. Without them, it becomes a manual, multi-week investigation opening dependency manifests service by service — the wrong speed for a response that needs to happen in hours.

Syft: SBOM generation

Syft scans a container image or filesystem and produces the structured dependency inventory. This is purely the generation step, distinct from signing or verification.

Cosign: signing and verification

Cosign cryptographically signs artifacts — container images and the SBOMs themselves — so a consumer (a deployment pipeline, a Kubernetes admission controller) can verify an artifact was not tampered with after it was built. Generation (Syft) and signing/verification (Cosign) are distinct, complementary steps in a supply chain security pipeline, not interchangeable tools performing the same job.

What signature verification actually prevents

Without verification, a container image pulled from a registry is trusted simply because it came from the registry — with no cryptographic proof it is the exact artifact CI built, rather than something tampered with or substituted in the registry or network path. Verifying a Cosign signature against a known, trusted signing key before deployment means an unsigned or invalidly-signed image fails verification and is blocked outright, instead of being silently trusted based on source location alone.

SLSA (Supply-chain Levels for Software Artifacts)

Defines graduated levels of supply chain rigor — from basic provenance tracking up through fully verified, tamper-resistant, hermetic builds — rather than a single pass/fail bar. Different levels represent genuinely different amounts of engineering investment and risk tolerance; graduated levels let an organization target a level matched to its actual risk profile and improve incrementally, rather than face an all-or-nothing requirement that gets ignored or absorbs disproportionate effort.

Enforcement timing

Supply chain checks (SBOM generation, signature verification) configured as blocking CI/CD gates prevent an unsigned or unscanned artifact from ever reaching deployment. The same checks run as informational, non-blocking scans reviewed later mean a compromised or unverified artifact may already be running in production before anyone reviews the result — turning prevention into after-the-fact cleanup at exactly the moment prevention mattered most.

Syft vs Cosign vs SLSA

Command / Configuration Reference

# Syft: generate an SBOM for a container image
syft packages myapp:1.2.3 -o cyclonedx-json > sbom.json

# Cosign: sign an image and attach/sign the SBOM
cosign sign --key cosign.key myrepo/myapp:1.2.3
cosign attest --key cosign.key --predicate sbom.json --type cyclonedx myrepo/myapp:1.2.3

# Cosign: verify signature before deploy (used as an admission-control gate)
cosign verify --key cosign.pub myrepo/myapp:1.2.3

Common Pitfalls

• Pitfall: A critical CVE disclosure triggers a multi-week manual investigation across hundreds of services. Why: No SBOMs exist to query directly. Fix: Generate SBOMs for every build so “which artifacts contain dependency X at version Y” is a fast query.
• Pitfall: Container images deploy with no signature verification. Why: No cryptographic guarantee ties the deployed image to what CI actually built. Fix: Sign images and SBOMs with Cosign, and enforce verification before deployment.
• Pitfall: Supply chain scanning runs as an informational, non-blocking step. Why: Findings are reviewed only after the fact. Fix: Make SBOM generation and signature verification blocking CI/CD gates.
• Pitfall: An organization tries to jump straight to the highest SLSA level. Why: No incremental groundwork exists to support it. Fix: Target a SLSA level matched to actual risk profile and treat it as an incremental improvement path.

Interview Questions

• A critical CVE was just disclosed for a widely-used library. Walk through how the organization would identify every affected production service. — Tests whether SBOM-based querying is the reasoned, fast-response answer.
• Explain the distinct roles Syft and Cosign play in a supply chain security pipeline. — Tests whether generation and signing/verification are understood as separate, complementary steps.
• Why should supply chain security checks be blocking CI/CD gates rather than informational scans? — Tests whether the prevention-versus-cleanup timing argument is genuinely understood.
• Why does SLSA define multiple levels instead of a single bar? — Tests whether graduated adoption versus all-or-nothing compliance is understood.