Supply Chain in CD

Provenance from build to deploy.

The supply-chain attack surface

Supply-chain attacks span the entire build path. Build dependencies, build infrastructure, and artifacts in transit are each separate vectors; securing one without the others leaves the chain only as strong as its weakest link.

• Build dependencies compromised. npm, PyPI, Cargo registry attack vector per package; compromised package compromises every build that pulls it.
• Build infrastructure tampered. CI runner attack surface per builder; compromised runner produces compromised artifacts even with clean source.
• Build artifacts replaced. Artifact-in-transit risk per pipeline; image replaced between build and registry destination.
• Separate controls per step. Named defence per step; "we secured the build but not the source" is the failure mode without comprehensive coverage.

SLSA framework

SLSA codifies the discipline. Levels 1-4 increase rigour; most production teams aim for 2-3, since L4 disrupts day-to-day workflow more than the threat model justifies for many orgs.

• Levels 1-4. Rigour ladder; L1 documented, L2 signed provenance, L3 hardened builds, L4 two-party review for every change.
• Most aim for SLSA 2-3. Realistic target; L4's two-party-review requirement is operationally heavy for most teams.
• Approachable tooling. sigstore (cosign), in-toto, GitHub artifact attestations make SLSA practical without bespoke infrastructure.
• Documented SLSA level per org. Named target supports auditor conversations and budget arguments.

Concrete controls

Concrete controls are mechanical. Hash pinning, signing, hermetic builds, and SBOM each address a specific attack vector; together they form the practical foundation.

• Pin dependencies by hash. Lockfile plus verified hash on install per package; not by version alone, since versions can be republished.
• Sign at build, verify at deploy. cosign sign per artifact in CI; signature verification at deploy time closes the loop.
• Hermetic builds. Isolated environment per build; no network access during the build step prevents dependency-on-the-fly attacks.
• SBOM per artifact. syft-or-equivalent Software Bill of Materials per artifact; required for vulnerability tracking and customer attestations.

Verify at deploy time

Verification gates the deploy. cosign verify, policy enforcement, and SBOM CVE scans together prevent unsigned, unverified, or known-vulnerable artifacts from reaching production.

• cosign verify in deploy pipeline. Signature-check gate per deploy; reject unsigned images at the pipeline boundary.
• Policy engines. OPA Gatekeeper or Kyverno admission policy per cluster; enforce signature requirements at the cluster boundary too.
• SBOM CVE scan. Anchore, Snyk, or Trivy scan per artifact; block deploy on critical findings.
• Named approver per critical finding. Human-review gate catches false positives without auto-approving real risks.

How to invest

Investment is target-driven. Public software needs SLSA 3 because customers expect signed artifacts; internal services SLSA 2 is meaningful and achievable; do not reach for L4 in year one.

• Public or distributed software: SLSA 3. Customer-attestable bar per product; modern customers expect signed artifacts and provenance.
• Internal services: SLSA 2. Lower bar per service with signature verification; still meaningful protection without operational overhead.
• Do not aim L4 in year one. Two-party review disrupts day-to-day workflow; phase realistically over multiple years.
• Documented roadmap per program. Multi-year SLSA progression supports honest planning and budget conversations.