Skip to content

Supply chain security

First PublishedByAtif Alam

Software supply chain security reduces the risk that build, dependency, or distribution steps introduce malicious or vulnerable code. This page orients you to SBOM, SLSA-style thinking, and signing; pair it with scanning and artifact hygiene.

Tooling and threat models change quickly. Align naming and gates with your security and platform owners.

SBOM (Software Bill of Materials)

Section titled “SBOM (Software Bill of Materials)”

An SBOM is a machine-readable inventory of components (packages, images, licenses) for a release or artifact. It supports vulnerability response (which services embed log4j-style issues?), license review, and vendor questionnaires.

Practices:

  • Generate SBOMs in CI for applications (language lockfiles + SBOM format) and container images (base layers included).
  • Store SBOMs next to artifacts (registry metadata, object storage, or dedicated store) with immutable release linkage.
  • On CVE disclosure, query SBOMs to scope blast radius before panic-patching.

Read next: Security scanning (DevSecOps) for SCA and container scanning that feeds SBOM and gate decisions.

SLSA (provenance and tamper resistance)

Section titled “SLSA (provenance and tamper resistance)”

SLSA (Supply-chain Levels for Software Artifacts) is a framework for build provenance and tamper-evident pipelines — not a single tool. In practice teams adopt levels incrementally: scripted builds → hermetic or isolated builders → signed provenance consumers can verify.

Practices:

  • Treat build identity as first-class: who/what produced this artifact, from which commit and pipeline run.
  • Prefer ephemeral, minimal-privilege build environments over long-lived build VMs with broad secrets.
  • Document expected provenance fields for “promotable” artifacts (staging → prod).

Read next: Compliance and audit for signed commits, change evidence, and separation of duties that complement provenance.

Signing and verification

Section titled “Signing and verification”

Signing proves artifact integrity and (with key policy) origin. Common patterns: Sigstore/cosign for OCI images, Notary-style metadata, or cloud KMS-backed signing.

Practices:

  • Sign at promotion boundaries (release tag, prod registry push) with keys owned by CI or a dedicated signing service — not developer laptops for prod.
  • Verify in deploy paths (admission webhook, CD pull, GitOps reconciler) before running new images.
  • Rotate keys on a schedule; break-glass procedures for key compromise.

Read next: Artifact management for registries, retention, and promotion flows where signatures attach.

Section titled “Related”