Secure Your Entire Build Process

Supply chain attacks accelerate because attackers know breaking upstream libraries affects thousands of downstream projects. This path teaches defense of every stage: SBOMs provide dependency understanding, build provenance verifies origin, image signing ensures authenticity, and reproducible builds detect tampering. By the end, you'll implement SLSA Level 3+ compliance and detect supply chain compromises before malicious code reaches production.

Duration: 5-7 weeks (25-35 hours) Skill Level: Intermediate to Advanced Prerequisites: Container security fundamentals, Kubernetes knowledge

graph TB    Source["Source Code<br/>Repository"]    Source --> SBOM["SBOM<br/>Dependencies<br/>Inventory"]    Source --> Build["Build<br/>Provenance<br/>Verify origin"]    SBOM --> VEX["VEX<br/>Vulnerability<br/>Context"]    Build --> Sign["Image Signing<br/>Cosign<br/>Verify authenticity"]    VEX --> Policy["Policy<br/>SLSA Level 3+<br/>Compliance"]    Sign --> Deploy["Deploy<br/>Only verified<br/>images"]    Policy --> Monitor["Monitor<br/>Continuous<br/>compliance"]    style SBOM fill:#e3f2fd    style VEX fill:#e3f2fd    style Deploy fill:#c8e6c9

Learning Outcomes

After completing this path, you will understand supply chain attack vectors and threats. You'll implement SBOM generation and management comprehensively. You'll create VEX statements contextualizing vulnerabilities. You'll achieve SLSA compliance at Level 3+. You'll implement build provenance and verification. You'll sign and verify container images. You'll build reproducible, deterministic builds. You'll enforce supply chain policies with code. You'll audit and monitor supply chain integrity.

Module 1: Supply Chain Fundamentals (Week 1)

Concepts

The software supply chain encompasses repositories, build systems, registries, and deployment targets. Attack vectors include dependency compromise (malicious code in libraries), build poisoning (tampering during build), registry compromise (serving malicious images), and deployment attacks (compromised credentials). Defense involves verification at each stage.

Real-world incidents demonstrate the threat. SolarWinds 2019 showed build system compromise affecting 18,000+ organizations. Log4Shell revealed transitive dependency vulnerabilities. XZ Utils backdoor showed upstream project compromise.

Compliance and standards establish requirements. Executive Order 14028 mandates SBOMs. NIST guidance establishes SLSA and provenance. Industry standards (OWASP, Linux Foundation) define best practices.

Hands-On Labs

The first lab audits project dependencies identifying outdated packages, known vulnerabilities, and transitive dependencies. The second lab traces vulnerability propagation through dependency chains. The third studies real incidents understanding attack paths.

Module 2: Software Bill of Materials (SBOM) (Weeks 1-2)

Concepts

SBOM fundamentals establish what SBOMs are (component inventories), why they matter (regulatory compliance, vulnerability response), format choices (SPDX vs CycloneDX), and distribution practices. SBOM management covers storage with artifacts, versioning, querying, and analysis. Quality assessment ensures completeness and accuracy.

Hands-On Labs

The first lab generates SBOMs with Syft in multiple formats. The second analyzes SBOMs for package counts, vulnerabilities, and licensing. The third performs SBOM queries extracting specific component information. The fourth integrates SBOM generation into CI/CD pipelines.

Module 3: Vulnerability Contextualization with VEX (Weeks 2-3)

Concepts

VEX fundamentals explain exploitability statements, status options (not affected, affected, fixed, under investigation), and when to use VEX. Justifications provide context: component not included, vulnerable code not present, vulnerable code not reachable, requires specific configuration, requires environment/dependency/interaction. Automation generates VEX from analysis. Signing verifies VEX authenticity.

Hands-On Labs

The first lab creates VEX statements manually documenting vulnerability status. The second analyzes exploitability identifying NOT_AFFECTED vulnerabilities. The third integrates VEX into CI/CD generating statements alongside scan results.

Module 4: SLSA Framework and Build Integrity (Weeks 3-4)

Concepts

SLSA levels establish requirements: Level 0 (no verification), Level 1 (version control), Level 2 (isolated build with signed provenance), Level 3 (hardened build platform), Level 4 (hermetic reproducible builds). Build provenance documents builder, source, build commands, environment, and signatures. Achieving SLSA 3+ requires CI/CD platform that generates attestations automatically.

Hands-On Labs

The first lab assesses current SLSA level using a checklist. The second generates SLSA provenance using GitHub Actions (automatic Level 3). The third verifies provenance using cosign verify-attestation.

Module 5: Reproducible and Deterministic Builds (Weeks 4-5)

Concepts

Build determinism requires bit-for-bit identical outputs regardless of when/where builds occur. Eliminating non-determinism (timestamps, random data, floating deps, file ordering, compression) requires explicit control. Hermetic builds declare all inputs and produce identical outputs. Reproducibility testing verifies consistency. Continuous monitoring detects drift.

Hands-On Labs

The first identifies non-determinism by building repeatedly and comparing hashes. The second creates deterministic Dockerfiles pinning all versions and digests. The third uses Bazel for hermetic builds with guaranteed reproducibility.

Module 6: Supply Chain Policy and Enforcement (Weeks 5-6)

Concepts

Supply chain policies define enforceable rules. Binary Authorization requires signed images. Admission control blocks unsigned or unverified images. Policy-as-code (Rego, CEL) expresses rules. Automated enforcement prevents violations before deployment. Audit trails document all decisions.

Hands-On Labs

The first creates admission control policies using Kyverno or OPA. The second tests policy violations and remediation. The third builds automated enforcement into CI/CD pipelines.

Module 7: Compliance and Auditing (Weeks 6-7)

Concepts

Compliance frameworks (Executive Order 14028, NIST 800-190, ISO 27001) mandate supply chain controls. Auditing produces evidence of compliance. Continuous monitoring detects drift. Reporting demonstrates adherence to frameworks.

Hands-On Labs

The first collects evidence of supply chain controls. The second generates compliance reports. The third establishes continuous monitoring for policy violations.

Final Project: End-to-End Supply Chain

Build a complete supply chain for a containerized application from source to production deployment. The application should include source code management with signed commits, build pipeline with provenance attestation and SBOM generation, image signing with cosign, vulnerability scanning with VEX statements, admission control policies for enforcement, and continuous monitoring for compliance violations.

Your project documentation should explain architecture choices and security decisions at each stage.

What to Read Next

Executive Order 14028 Supply Chain Requirements. NIST 800-190: Application Container Security. SLSA Framework. Sigstore: Signing and Verification.