Supply-chain security

Your pipeline is part of the software supply chain: source, dependencies, build, artifact, deploy. An attacker can poison any hop. They might compromise an npm package, steal a CI token, or swap an unsigned image in the registry. Defences stack, and no single one is enough.

Walking through the layers

1. Pin dependencies. Commit lockfiles such as package-lock.json, go.sum or poetry.lock. Prefer digest-pinned base images over floating tags. Review dependency update PRs, and do not auto-merge them into production paths.
2. Generate an SBOM. A Software Bill of Materials lists every package in an artifact, with its version and license. Generate one at build time with Syft, Trivy or docker sbom, and store it next to the image. When the next critical CVE arrives, you query the SBOMs instead of logging in to hosts.
3. Sign and record provenance. Sigstore's cosign signs images with short-lived certificates, often tied to the CI job's identity. This is called keyless signing. Verification at deploy time checks that the image came from your workflow.
4. Protect CI credentials. Use OIDC federation, so the job receives temporary cloud credentials instead of storing long-lived keys.

The sketch below shows the signing and OIDC pieces of a workflow. It is illustrative, not a complete workflow.

permissions:
  id-token: write   # lets the job request an OIDC token
  contents: read
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/org/svc:${{ github.sha }}
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign --yes ghcr.io/org/svc:${{ github.sha }}

Levels of provenance

SLSA (Supply-chain Levels for Software Artifacts) grades provenance in levels. Level 1 documents the build. Level 2 uses a hosted, scripted build with provenance. Level 3 hardens the build platform against tampering. Level 4, as first defined, adds two-party review and reproducible, hermetic builds. You do not need Level 4 on day one. Signing images and recording provenance from GitHub Actions is a realistic starting point.

Common mistakes

• Pinning to tags. A tag can move. Pin the digest or the full action SHA.
• Generating an SBOM and never using it. It is only useful when you can query it.
• Storing cloud keys in secrets. Use OIDC, so there is no long-lived key to leak.
• Scanning without failing the build. A warning in the log protects nobody.

Check yourself

1. Why does an SBOM help when a new critical CVE is published? Answer: It lists every package in each artifact, so you find the affected images without logging in to hosts.
2. Why is OIDC safer than a stored access key? Answer: The job gets short-lived credentials, so there is no long-lived secret to steal.

Key takeaways

• Pin lockfiles and digests. Review dependency updates before they reach production.
• Generate SBOMs at build time, and query them when a CVE is published.
• Sign images and verify the signature at deploy time.
• Use OIDC federation instead of long-lived cloud keys.

Further learning

Bob Callaway from Google explains why keyless signing and transparency logs change supply-chain verification.

SLSA: Supply-chain Levels for Software Artifacts describes the levels in detail. Next, see how to measure all of this delivery work: DORA metrics.