Registries & Supply-Chain Security¶

Estimated time: 18 min read · Part: Docker & Kubernetes

Container Registries¶

A container registry is a server that stores and distributes Docker images. When you docker push, the image layers are uploaded to the registry; when you docker pull (or a Kubernetes node pulls an image to run), the layers are downloaded. Registries are organized into repositories (one per service, typically) containing images identified by tags (version labels) and digests (immutable SHA-256 hashes of the image content).

Software Bill of Materials (SBOM)¶

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component and dependency in an artifact — every Python package, every OS library, their versions and licenses. An SBOM serves two purposes: vulnerability response (when a new CVE is published for OpenSSL 3.0.x, you can immediately query your SBOM store to find which services are affected); license compliance (ensuring you are not shipping GPL code in a proprietary product). Executive Order 14028 (US, 2021) mandates SBOMs for software sold to the federal government, and the EU Cyber Resilience Act is moving in the same direction. Any client in a regulated industry or with government customers needs an SBOM pipeline.

name: Supply Chain Security

on:
  push:
    branches: [main]

jobs:
  build-sign-sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write    # required for OIDC and Sigstore keyless signing

    steps:
      - uses: actions/checkout@v4

      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        id: build
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

      # Generate SBOM using Syft
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
          artifact-name: sbom.spdx.json
          format: spdx-json       # SPDX is the standard SBOM format (also CycloneDX)

      # Scan for CVEs using Grype
      - name: Scan image for vulnerabilities
        uses: anchore/scan-action@v3
        with:
          image: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
          fail-build: true         # fail the pipeline on HIGH or CRITICAL CVEs
          severity-cutoff: high

      # Sign the image using Sigstore/cosign (keyless)
      - name: Sign image with cosign
        uses: sigstore/cosign-installer@v3
      - run: |
          cosign sign --yes \
            ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Image Signing with Sigstore and Cosign¶

Image signing creates a cryptographic attestation that a specific image (identified by digest) was produced by a specific CI workflow — and has not been tampered with since. The modern tool is cosign, part of the Sigstore project. Sigstore's keyless mode uses the CI job's OIDC identity token (the same mechanism used for keyless cloud authentication) to sign the image without managing long-lived private keys. The signature is stored in the same registry alongside the image. A consumer — Kubernetes admission controller, deployment script — can verify the signature before running the image. This closes the gap where an attacker who compromises a registry could push a malicious image without CI.

# Verify that an image was signed by a specific GitHub Actions workflow
cosign verify \
  --certificate-identity-regexp "https://github.com/myorg/myrepo/.github/workflows/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myrepo@sha256:a1b2c3d4...

# Output if valid:
# Verification for ghcr.io/myorg/myrepo@sha256:a1b2c3d4...
# The following checks were performed on each of these signatures:
#   - The cosign claims were validated
#   - Existence of the claims in the transparency log was verified offline
#   - The code-signing certificate claims were validated
#
# [{"critical":{"identity":{"docker-reference":"ghcr.io/myorg/myrepo"},
#    "image":{"docker-manifest-digest":"sha256:a1b2c3..."},...}}]

# List all attestations on an image
cosign tree ghcr.io/myorg/myrepo@sha256:a1b2c3d4...

WHY supply chain risk Your deployed application is only as secure as its weakest dependency. An attacker who compromises an OS package, a Python library, or a registry can inject malicious code that runs in production. SBOMs, scanning, and signing are the three layers of defense.

HOW the three practices Generate an SBOM on every build (Syft); scan for CVEs in CI and on a schedule (Grype, Trivy); sign images keylessly with Sigstore/cosign. Verify signatures before deploying (Kyverno policy in Kubernetes).

WHERE regulated clients EO 14028 (US federal vendors), EU CRA, SOC 2 Type II, PCI-DSS all have supply-chain provisions. For any regulated client, SBOM + signing is a compliance checkbox that also delivers real security value.

LAYER 1: SBOM GENERATION (runs in CI on every build)
Tool: Syft (anchore/sbom-action GitHub Action)
When: after docker push, before deploy
Output: SBOM in SPDX-JSON format, uploaded as CI artifact
         AND attached to the image as an OCI attestation
Storage: DependencyTrack or Grype DB for queryability across services

LAYER 2: CVE SCANNING
A) In CI (fast feedback): Grype scan on every build
   - Fail build on HIGH/CRITICAL severity
   - Allows blocking new vulnerabilities from shipping
B) Scheduled (catches newly published CVEs against old images):
   - Daily GitHub Actions scheduled workflow
   - Scan all images currently running in production
   - Alert on Slack/PagerDuty if new HIGH/CRITICAL CVEs discovered
Tool: Grype or Trivy

LAYER 3: IMAGE SIGNING
Tool: Sigstore/cosign (keyless via OIDC, no key management)
When: after CVE scan passes, before deploy step
Enforcement: Kyverno or OPA Gatekeeper policy in Kubernetes
- Kubernetes admission controller verifies cosign signature
- Unsigned or untrusted images are rejected at deploy time

EVENT FLOW: New Critical CVE Published
1. Daily scheduled scan (Layer 2B) detects vulnerability in prod image
2. Alert sent to security team with affected services and severity
3. Team queries DependencyTrack (Layer 1): which services, which versions
4. Priority triage: internet-facing services patched first
5. Dependency bumped, PR opened, CI runs (Layer 2A) — blocks if CVE persists
6. New image built, SBOM generated (Layer 1), signed (Layer 3)
7. Kubernetes admission controller verifies signature before rollout
8. DependencyTrack record updated for new clean image