Supply Chain in CD

Provenance from build to deploy.

The supply-chain attack surface

Build dependencies (npm, PyPI, Cargo) can be compromised.

Build infrastructure can be tampered with.

Build artifacts can be replaced en route to the registry.

Each step is a separate attack vector that needs separate controls.

SLSA framework

Levels 1-4 increase rigor. Level 1: documented build process. Level 2: tamper-resistant signed provenance. Level 3: hardened builds. Level 4: two-party review.

Most production-grade builds aim for SLSA 2-3.

Frameworks like sigstore (cosign), in-toto, and GitHub artifact attestations make this approachable.

Concrete controls

Pin dependencies by hash, not version. Lockfiles + verified hash on install.

Sign artifacts at build. Verify signatures at deploy.

Hermetic builds in isolated environments. No network access during build.

SBOM (Software Bill of Materials) for every artifact. Generated by syft or similar.

Verify at deploy time

Cosign verify in the deploy pipeline. Reject unsigned images.

Policy engines (OPA Gatekeeper, Kyverno) enforce signature requirements at admission.

Anchore, Snyk, Trivy scan SBOMs for known CVEs. Block deploy on critical findings.

How to invest

Public/distributed software: SLSA 3 minimum. Customers expect signed, attestable artifacts.

Internal services: SLSA 2 with signature verification. Lower bar, still meaningful.

Don't try to hit SLSA 4 in year 1. The two-party review requirement disrupts day-to-day workflow.