Supply Chain Security

Supply chain security answers two questions: what is in your software and where did it come from. SolarWinds, Codecov, log4j, and a long list of npm typosquats have made these questions existential. The discipline turns "we trust our build" into "here's the cryptographic evidence."

The threat model is broader than people realize. Anything that touches your build can become an attack vector: a compromised dependency, a tampered base image, a malicious GitHub Action, a phished maintainer, a stolen signing key, a subverted artifact registry.

Why Supply Chain Security

The Players and Standards

Signing and verification

Cosign is the modern default for containers. Notation is gaining ground in OCI registries. Sigstore overall is now the de-facto standard for new projects.

SBOM (Software Bill of Materials)

For new projects: Syft + Grype + Cosign. Trivy is a strong all-in-one alternative.

SLSA (Supply-chain Levels for Software Artifacts)

SLSA defines maturity levels for build integrity. Pronounced "salsa". From Google originally, now OpenSSF.

Most teams aim for SLSA 2-3. GitHub Actions with the slsa-github-generator reaches SLSA 3 with little custom work.

Provenance and in-toto

in-toto is a specification for cryptographically attesting what happened during a build:

• Which source repo
• Which commit
• Which build tool, which version
• Who triggered it
• What outputs were produced

The attestation is signed, included as image metadata or stored in a transparency log. Verifiable provenance.

Dependency provenance

What "Signing an Image" Actually Means

You build a container, push it, sign it. The signature includes:

• Digest of the image (immutable hash)
• Public key (or, with keyless signing, identity that signed)
• Timestamp
• Signature itself

On deploy, the cluster (via admission policy) verifies the signature against expected keys/identities before pulling the image. An unsigned image (or signed by the wrong identity) is rejected at the gate.

With keyless signing (Cosign + Fulcio + Rekor):

1. Build runs in GitHub Actions, signed by an OIDC identity
2. Fulcio issues a short-lived cert tied to that identity
3. Image is signed with that cert
4. Signature + cert chain goes to Rekor (transparency log)
5. Verifier checks: cert chain valid + identity matches expected + Rekor entry exists

No long-lived signing keys to steal. The identity (GitHub workflow path + repo) is what's trusted.

# Sign during CI
COSIGN_EXPERIMENTAL=1 cosign sign ghcr.io/my-org/checkout@sha256:abc123...

# Verify in admission controller
COSIGN_EXPERIMENTAL=1 cosign verify \
  --certificate-identity-regexp 'https://github.com/my-org/checkout/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/my-org/checkout@sha256:abc123...

What's in an SBOM

A Software Bill of Materials is a structured list of every component in your software:

{
  "spdxVersion": "SPDX-2.3",
  "name": "checkout-service",
  "packages": [
    { "name": "golang", "versionInfo": "1.22.0", "downloadLocation": "https://go.dev/dl/go1.22.0.linux-amd64.tar.gz" },
    { "name": "github.com/gin-gonic/gin", "versionInfo": "v1.9.1", "license": "MIT" },
    { "name": "github.com/golang-jwt/jwt", "versionInfo": "v4.5.0" },
    ... 200+ more ...
  ]
}

Generated automatically from the build artifact:

syft ghcr.io/my-org/checkout:v1.2.3 -o spdx-json > sbom.json

Stored alongside the image (as an OCI artifact) or in a central catalog:

cosign attest --predicate sbom.json --type spdx ghcr.io/my-org/checkout:v1.2.3

The SBOM is now a signed attestation attached to the image. Anyone can pull it. The "log4j question" — "do any of our images use log4j 2.14.x?" — becomes a one-line query over the SBOM catalog.

Learning Path

The Compliance Angle

Regulators are catching up. Notable mandates:

• US Executive Order 14028 (2021) — federal vendors must provide SBOMs
• EU Cyber Resilience Act (2024-25) — broader CE-mark style requirements
• NIST SP 800-218 (SSDF) — secure software development framework
• PCI DSS 4.0 — requires inventory of bespoke and custom software components

If you sell software to enterprises or governments, SBOM + provenance is rapidly becoming RFP-mandatory.