Supply Chain Security: SBOM, SLSA, and Sigstore in Your CI/CD Pipeline

# Supply Chain Security: SBOM, SLSA, and Sigstore in Your CI/CD Pipeline

The average container image pulls in 300-900 transitive dependencies. You authored maybe 5% of the code running in production. The rest? Open-source packages maintained by strangers, compiled by unknown build systems, distributed through registries you don't control.

Supply chain attacks (SolarWinds, Log4Shell, xz-utils) proved this isn't theoretical. Regulations are catching up — the EU Cyber Resilience Act and US Executive Order 14028 now mandate SBOM for critical software.

Here's how to implement the full stack: SBOM generation, SLSA attestations, and Sigstore signing.

The Three Pillars

1. SBOM — Software Bill of Materials

An SBOM is a machine-readable inventory of every component in your software. Think of it as a nutrition label for code.

Two standards:

Generate SBOMs in CI:

# GitHub Actions with Syft
- uses: anchore/sbom-action@v0
  with:
    image: myapp:${{ github.sha }}
    format: cyclonedx-json
    output-file: sbom.json

Or with Trivy:

trivy image --format cyclonedx --output sbom.json myapp:latest

2. SLSA — Supply-chain Levels for Software Artifacts

SLSA (pronounced "salsa") defines 4 levels of build integrity:

SLSA 3 with GitHub Actions:

- uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
  with:
    image: ghcr.io/myorg/myapp
    digest: ${{ steps.build.outputs.digest }}

This generates a signed provenance attestation that proves: who built it, what source was used, what build system ran, and what the inputs were.

3. Sigstore — Keyless Signing

Sigstore eliminates the pain of key management for artifact signing. It uses OIDC identity (your CI/CD identity) instead of long-lived keys.

# Sign a container image (keyless)
cosign sign ghcr.io/myorg/myapp@sha256:abc123

# Verify
cosign verify --certificate-identity="https://github.com/myorg/myapp/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123

Putting It All Together: The Secure Pipeline

name: Secure Build Pipeline
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write  # Required for Sigstore
    steps:
      - uses: actions/checkout@v4

      - name: Build and push
        id: build
        run: |
          docker build -t ghcr.io/myorg/myapp:${{ github.sha }} .
          docker push ghcr.io/myorg/myapp:${{ github.sha }}

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/myorg/myapp:${{ github.sha }}
          format: cyclonedx-json

      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3
      - run: cosign sign ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}

      - name: Scan for vulnerabilities
        run: trivy image --severity HIGH,CRITICAL ghcr.io/myorg/myapp:${{ github.sha }}

Admission Control: Enforce in Production

Use Kyverno or OPA Gatekeeper to reject unsigned images:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  rules:
  - name: check-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - imageReferences: ["ghcr.io/myorg/*"]
      attestors:
      - entries:
        - keyless:
            issuer: "https://token.actions.githubusercontent.com"
            subject: "https://github.com/myorg/*"

Compliance Mapping

Vulnerability Management with SBOMs

Generating an SBOM is only step one. The real value comes when you use it for continuous vulnerability monitoring:

# Generate SBOM once at build time
syft ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.json

# Scan SBOM against latest CVE database (run daily via cron)
grype sbom:sbom.json --fail-on critical

This separates build from scan. You build the SBOM once, then re-scan it daily against updated vulnerability databases without rebuilding the image. When Log4Shell dropped, teams with SBOMs identified affected services in minutes. Teams without SBOMs spent days running find commands across hundreds of containers.

Real-World Implementation Timeline

Based on implementing this for three clients:

Week 1: Foundation

Week 2: Signing

Week 3: Enforcement

Week 4: Production

Total engineering effort: approximately 20-30 hours spread across the team. The hardest part isn't the tooling — it's getting buy-in from teams who see it as "more CI overhead." Show them the Log4Shell timeline and the EU CRA deadlines.

Start Here

If you do nothing else: 1. Generate SBOMs with Syft or Trivy (30 minutes to set up) 2. Sign images with Cosign keyless (15 minutes) 3. Add Trivy vulnerability scanning to CI (already scanning? good)

That gets you to SLSA 1 and basic compliance readiness. Build from there.

The EU CRA enforcement deadline is January 2027. That's 20 months away. Starting now gives you comfortable runway. Starting next quarter means rushing — and rushing security implementations is how you introduce the vulnerabilities you're trying to prevent.

---

Need help implementing supply chain security for your CI/CD pipeline? Book a free security consultation or explore our DevSecOps services.