Software Supply Chain Security
SLSA levels, SBOM generation, provenance attestation, and dependency pinning to secure the software supply chain end-to-end.
Overview
Overview
Supply chain attacks target the build system and dependencies rather than the application itself. Defense requires verifiable provenance for every artifact and a full inventory of every component.
Two questions every artifact must answer
- What is in this artifact? — SBOM (Software Bill of Materials) — SPDX, CycloneDX
- How was this artifact built? — Provenance attestation — in-toto attestation with the SLSA provenance predicate
> [!IMPORTANT] You need both: each covers a different attack surface, and admission control can require both before a pod runs.
Controls along the pipeline
- Source — Dependencies pinned to exact version and digest; Gitleaks and Semgrep secret scanning
- Build — Ephemeral, isolated build service producing signed provenance
- Artifact — SBOM attached as an attestation; keyless Cosign signature
- Deploy — Only images with a valid signature and provenance from your CI system are admitted
Interview questions
- How do you implement software supply chain security end-to-end in a CI/CD pipeline?
- What is the difference between a software bill of materials (SBOM) and provenance attestation?
Sign up free to read the full topic
More DevOps topics
- Service Mesh
- Service Networking Errors — DNS, Timeouts, Port Mismatch and Mesh Sidecars
- Shift-Left Security
- Sigstore & Software Supply Chain Security
- SLO / SLI / Error Budgets
- SLSA — Software Supply Chain Security
- SonarQube — Quality Gates, Web API, Administration, Errors and Mistakes
- Sources — Git, OCI, Helm, Bucket
- Static Analysis for C/C++ in CI
- Storage Errors — FailedMount, Pending PVCs, Multi-Attach and Full Volumes
- Strangler Fig
- Team Topologies
Start free on Cariara · Coding problems · System design studio