Phase 14 — Software Supply Chain Security at Scale
Track: Elite / Principal | Duration: 8 weeks | Prerequisites: Phase 03, Phase 07
Objective: defend the build and the dependency graph — the attack surface behind every major recent
compromise (SolarWinds, event-stream, xz, dependency-confusion). Become able to design and build
verifiers for end-to-end build integrity: provenance and SLSA, in-toto attestations, hermetic and
reproducible builds, keyless signing and transparency logs (Sigstore), binary authorization, dependency
security, and SBOM/VEX. This is the work that lets a company — and the critical open-source it depends
on — ship software that customers can verify, not just trust.
Deep guides: WARMUP.md derives the whole supply chain from first principles; HITCHHIKERS-GUIDE.md is the operator's manual (cosign/rekor/SLSA/Bazel in practice).
Why This Phase Exists
The attacker's highest-leverage move is to compromise what goes into your software and have you ship it, signed and trusted, to every customer. Phase 03 introduced SBOM/SLSA/Sigstore; this phase goes to the depth a FAANG supply-chain team or a critical-OSS maintainer operates at: the SLSA levels and how to achieve L3+, the in-toto attestation graph and materials reconciliation (where dependency injection is caught), the Merkle math under transparency logs, binary authorization as the enforcement point, and the dependency attack classes and their pin-by-digest defenses. A single supply-chain compromise has the blast radius of every downstream user at once — which is exactly why this capability protects so much.
Core Topics
- The source→consumer threat model; the build as the crown-jewel target.
- Provenance and in-toto attestations; DSSE; the attestation graph; materials reconciliation.
- SLSA build-track levels (L1–L3+), achieving non-falsifiable provenance; computing/enforcing a level.
- Hermetic builds (Bazel/Nix, no network, declared inputs) and reproducible (bit-for-bit) builds.
- Keyless signing (Sigstore/Fulcio) and transparency logs (Rekor); RFC 6962 Merkle inclusion proofs; Certificate Transparency as the same mechanism.
- Binary authorization / admission verification; verify-at-the-door, fail-closed.
- Dependency security: confusion/substitution, typosquatting, hijacked/malicious packages, lockfile and digest pinning.
- SBOM (CycloneDX/SPDX) and VEX (OpenVEX/CSAF); fleet-wide "are we affected and where".
- Package-registry and build-system hardening; OIDC-federated short-lived publish identity.
Labs
| Lab | Build | Core security idea |
|---|---|---|
| 01 SLSA Provenance Verifier | in-toto/SLSA provenance policy engine | materials reconciliation vs lockfile + SLSA-level enforcement |
| 02 Transparency-Log Verifier | RFC 6962 Merkle inclusion-proof verifier | domain-separated hashing, signed tree head, audit-path verification |
Pure-Python, offline, deterministic; faithful to the real mechanisms (the inclusion-proof math is real RFC 6962-style Merkle verification; signatures are deterministic stand-ins). Run:
LAB_MODULE=solution pytest -q
pytest -q
Capstone — Supply-Chain Assurance Program
Design (and partially implement) a supply-chain assurance program for a fictional product + its critical OSS dependencies:
- the source→consumer threat model with a control at each link;
- a SLSA L3 build design (isolated, non-falsifiable provenance; hermetic where feasible) and a reproducible-build plan with a verification rebuilder;
- a signing + transparency design (keyless/Sigstore, Rekor monitoring for unexpected signatures);
- a binary-authorization policy verifying provenance + SLSA level + materials at admission;
- a dependency-security policy (digest pinning, confusion/typosquat defenses, install-script controls,
maintainer-change monitoring — the
xzlesson); - an SBOM + VEX pipeline answering "are we affected and where" fleet-wide;
- an executive memo: the blast-radius argument for supply-chain investment and residual risk.
Recommended Sources
SLSA specification; in-toto and DSSE; RFC 6962; Sigstore (Cosign/Fulcio/Rekor) docs; Reproducible Builds;
Bazel/Nix; NIST SP 800-218 (SSDF) and SP 800-161; OpenSSF Scorecard; SolarWinds/xz/event-stream
post-mortems.
Measurable Outcomes
- Verify SLSA provenance and catch an injected dependency, a swapped digest, a missing locked material, an untrusted builder, and a build below the required level.
- Verify a Merkle inclusion proof; detect a forged tree head, a tampered audit path, an untrusted log, and a not-included entry.
- Design SLSA-L3 builds and a verify-at-the-door binary-authorization policy.
- Produce an SBOM+VEX capability that answers fleet-wide affected-and-where queries.
Evaluation Checklist
- Map the source→consumer threat model and the defense at each link.
- Explain and perform materials reconciliation.
- Explain the SLSA levels and what each buys.
- Explain hermetic + reproducible builds and why they're the top of the ladder.
- Verify a Merkle inclusion proof and explain RFC 6962 domain separation.
- Design a fail-closed binary-authorization policy.
Common Mistakes
- Equating CVE scanning with supply-chain security (it misses injected/malicious/backdoored code).
- Signing without verifying at consumption (theater).
- Verifying the builder/source but not the materials (missing dependency injection).
- Pinning versions but not digests (re-publish/mirror attacks).
- Claiming a high SLSA level without isolated, non-falsifiable provenance.
- Treating the build system and registry as "internal, therefore trusted."
Interview Topics
SLSA levels and how to achieve L3+; in-toto attestations and materials reconciliation; hermetic vs
reproducible builds; keyless signing and transparency-log inclusion proofs; binary authorization;
dependency confusion/typosquat/hijack defenses; SBOM vs VEX; the SolarWinds/xz lessons.