CI/CD-Pipeline mit Sigstore, SLSA und SBOMs haerten

CI/CD ist eine Software-Supply-Chain-Risikooberflaeche, weil die Pipeline Abhaengigkeiten laden, Code kompilieren, Artefakte erstellen, sie veroeffentlichen und an die Produktion uebergeben kann, mit sehr wenig menschlicher Inspektion. OpenSSF behandelt Supply-Chain-Sicherheit weiterhin als zentrales Thema, und sein aktuelles Projektset umfasst weiterhin sowohl Sigstore als auch SLSA als Kernbausteine fuer die Absicherung, wie Software gebaut und verteilt wird.

Sigstore, SLSA und SBOMs loesen verschiedene Teile des Problems. Sigstore gibt Ihnen Signierung, Verifikation, Transparenz und keyless-identitaetsbasierte Workflows; SLSA gibt Ihnen ein Framework fuer Build-Integritaet plus Provenance, die beschreibt, wo, wann und wie ein Artefakt produziert wurde; und SBOM-Standards wie SPDX und CycloneDX geben Ihnen ein maschinenlesbares Inventar der Komponenten in der Software, die Sie ausliefern. Keines davon ersetzt die anderen. Sie funktionieren am besten als Stack.

Dieses Tutorial verwendet GitHub Actions fuer die konkreten Beispiele, weil der aktuelle GitHub-Flow sauber auf OIDC-basierte Signierung, Build-Provenance-Attestationen und signierte SBOM-Attestationen abbildet. Dieselbe Basislinie gilt trotzdem auf anderen CI-Systemen: Signieren Sie, was Sie ausliefern, generieren Sie Provenance vom Builder, generieren Sie ein SBOM zur Build-Zeit und verifizieren Sie alle drei vor dem Deployment. Fuer breiteren Kontext, wie AI-getriebene Entwicklung das Supply-Chain-Risikobild veraendert, siehe Software Supply Chain Security in the AI Era.

Schritt 1: Ihre aktuelle Pipeline kartieren

Bevor Sie Kontrollen hinzufuegen, kartieren Sie den tatsaechlichen Softwarepfad von der Quelle bis zur Produktion. SLSAs Provenance-Modell existiert, weil Artefakte nicht vertrauenswuerdig sind, nur weil sie aus “der Pipeline” kamen; Sie brauchen verifizierbare Informationen ueber den Builder, die Eingaben, den Aufruf und das produzierte Subjekt. Wenn Sie diese beweglichen Teile nicht beschreiben koennen, koennen Sie sie nicht verteidigen.

Die Pipeline-Stufen inventarisieren

Erfassen Sie fuer jede Anwendung oder jedes Image, das Sie veroeffentlichen:

• Quell-Repository und geschuetzte Branches
• Build-Workflow oder Runner
• Abhaengigkeitsaufloesung
• Paketierungsschritt
• Artefakt-Registry oder Release-Store
• Deployment-Pfad
• Drittanbieter-Actions, Plugins und Base-Images

Eine leichte Inventardatei reicht zum Start.

File: pipeline-inventory.yaml

application: payments-api
source:
  repo: github.com/acme/payments-api
  protected_branches:
    - main
build:
  ci_platform: github-actions
  workflow: .github/workflows/release.yml
  runner_type: github-hosted
dependencies:
  lockfiles:
    - package-lock.json
    - Dockerfile
  third_party_actions:
    - actions/checkout
    - docker/build-push-action
artifact:
  type: container-image
  registry: ghcr.io/acme/payments-api
deploy:
  environments:
    - staging
    - production
  gate: deploy-verify.sh

Identifizieren, was tatsaechlich deploybar ist

Signieren und verifizieren Sie das, was Ihre Runtime verbraucht, nicht nur eine Zwischendatei. GitHubs Artefakt-Attestation-Dokumentation macht denselben Punkt in der Praxis: Signieren Sie Software, die Menschen tatsaechlich ausfuehren, wie Binaries, Pakete und Container-Images, statt jede nebensaechliche Datei im Repo.

Fuer die meisten Teams bedeutet das eines oder mehrere von:

• Container-Image-Digests
• Release-Binaries
• Paket-Artefakte
• Deployment-Bundles oder Manifeste, die Digests pinnen

Ihre Drittanbieter-Vertrauenspunkte identifizieren

SLSAs Bedrohungsmodell konzentriert sich stark auf Manipulation im Build-Pfad. In echten Pipelines sind die haeufigsten Vertrauenspunkte nicht nur das Quell-Repo. Sie sind auch:

• Wiederverwendbare Actions oder Plugins
• Basis-Container-Images
• Paket-Registries
• Self-Hosted Runner
• Registry-Credentials
• Deploy-Credentials

Erstellen Sie eine kurze Checkliste und zwingen Sie sich, sie zu benennen.

File: third-party-trust-points.md

# Third-Party Trust Points

- Docker base images
- npm registry packages
- GitHub Actions used by the release workflow
- Container registry credentials
- Cloud deploy role assumed by the workflow

Sie sollten nun eine Pipeline-Karte haben, die Ihnen sagt, wo Artefakte gebaut werden, wo sie veroeffentlicht werden und welche externen Systeme das Ergebnis beeinflussen.

Schritt 2: Artefakt-Signierung hinzufuegen

Signierung ist die erste erzwingbare Kontrolle, weil sie eine einfache Frage beantwortet: Kam das Artefakt von einer erwarteten Identitaet? Sigstores Keyless-Flow ist besonders nuetzlich in CI, weil er ein OIDC-Identitaetstoken und kurzlebige Zertifikate verwendet, statt Sie zu zwingen, einen langlebigen privaten Signierschluessel in der Pipeline zu halten. In GitHub Actions kann Sigstores Fulcio-Integration die Zertifikatsidentitaet an den Workflow und das Repository binden, das die Signierung durchgefuehrt hat.

Entscheiden, was signiert werden soll

Fuer OCI-Workloads signieren Sie den unveraenderlichen Image-Digest, nicht ein schwebendes Tag. Fuer Release-Binaries signieren Sie das finale Artefakt, das Benutzer herunterladen. Wenn Sie sowohl einen Container als auch ein Release-Tarball ausliefern, signieren Sie beide separat und verifizieren Sie sie dort, wo jedes verbraucht wird.

Keyless-Signierung zum Build hinzufuegen

Das folgende Beispiel baut ein Container-Image, pusht es und signiert den Image-Digest mit Cosign unter Verwendung von GitHubs OIDC-Token.

File: .github/workflows/release.yml

name: release

on:
  push:
    branches:
      - main

permissions:
  contents: read
  packages: write
  id-token: write

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ghcr.io/acme/payments-api

jobs:
  build-sign:
    runs-on: ubuntu-latest

    steps:
      - name: Check out source
        uses: actions/checkout@v4

      - name: Log in to GHCR
        run: echo "${{ github.token }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin

      - name: Build and push image
        id: build
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ env.IMAGE_NAME }}:${{ github.sha }}

      # Check https://github.com/sigstore/cosign/releases for latest version
      - name: Install Cosign
        run: |
          COSIGN_VERSION="v3.0.5"
          curl -fsSL -o /tmp/cosign.deb \
            "https://github.com/sigstore/cosign/releases/download/${COSIGN_VERSION}/cosign_${COSIGN_VERSION#v}_amd64.deb"
          sudo dpkg -i /tmp/cosign.deb

      - name: Sign image digest with Sigstore keyless
        env:
          IMAGE_URI: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}
        run: |
          cosign sign --yes "${IMAGE_URI}"

Signaturen dort verifizieren, wo es darauf ankommt

Hoeren Sie nicht bei cosign sign auf. Verifikation gehoert dorthin, wo Vertrauensentscheidungen getroffen werden:

• vor dem Deployment
• zur Admission-Zeit in Kubernetes
• waehrend der Release-Promotion
• auf der Consumer-Seite, wenn andere Teams Ihre Artefakte pullen

Sigstores Policy-Controller existiert speziell, um Image-Signatur- und Attestation-Policy in der Kubernetes-Admission durchzusetzen, und kann Signaturen und Attestationen mit Namespace-bezogener Durchsetzung validieren.

Ein einfaches Pre-Deploy-Verifikationsskript sieht so aus:

File: deploy-verify-signature.sh

#!/usr/bin/env bash
set -euo pipefail

IMAGE_URI="$1"

cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "https://github.com/acme/payments-api/.github/workflows/release.yml@refs/heads/main" \
  "${IMAGE_URI}"

Sie sollten nun Artefakt-Signierung in der Pipeline und einen Verifikationspunkt vor dem Deployment oder der Admission haben.

Schritt 3: Provenance generieren

Provenance ist eine Attestation, die beschreibt, wie ein Artefakt produziert wurde. In SLSA-Begriffen sollte Provenance einem Verifizierer erlauben, die Builder-Identitaet, das Artefakt-Subjekt und den Digest sowie die Build-Details zu pruefen, die das Output mit der Quelle und den Build-Anweisungen verbinden. Provenance wird erst nuetzlich, wenn Sie sie gegen eine erwartete Vertrauenswurzel und erwartete Build-Identitaet verifizieren.

Welche Build-Metadaten wichtig sind

Mindestens ist Provenance wertvoll, wenn sie Ihnen erlaubt zu beantworten:

• Welcher Builder hat das Artefakt produziert
• Welches Quell-Repo und welche Revision wurden verwendet
• Welche Build-Anweisungen liefen
• Welcher Artefakt-Digest wurde produziert

GitHubs aktuelles Artefakt-Attestation-Modell umfasst Repository, Workflow, Environment, Commit-SHA, Event und andere OIDC-abgeleitete Build-Informationen. GitHub merkt auch explizit an, dass Artefakt-Attestationen allein auf SLSA v1.0 Build Level 2 abbilden, waehrend wiederverwendbare Workflows helfen koennen, sich Richtung Build Level 3 zu bewegen, indem Build-Anweisungen isoliert werden.

Basislinie: Build-Provenance in GitHub Actions hinzufuegen

Fuer eine praktische erste Basislinie fuegen Sie eine Build-Provenance-Attestation direkt nach dem Image-Build hinzu. GitHubs offizielle attest-build-provenance-Action unterstuetzt Binaries und Container-Images und kann die Attestation in die Registry pushen.

Fuegen Sie diesen Schritt zum build-sign-Job nach dem Image-Build hinzu. Der permissions-Block auf Job-Ebene aus dem obigen Workflow enthalt bereits den erforderlichen attestations: write-Scope; fuegen Sie ihn hinzu, falls Ihr Workflow ihn noch nicht hat.

      - name: Generate build provenance attestation
        uses: actions/attest-build-provenance@v3
        with:
          subject-name: ${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

Staerkerer Pfad: Hin zu wiederverwendbaren, isolierten Build-Workflows

Wenn Sie eine staerkere SLSA-Geschichte auf GitHub Actions brauchen, verwenden Sie wiederverwendbare Workflows oder den SLSA GitHub Generator, statt alle Build-Logik inline in einem mutierbaren Release-Workflow zu lassen. Das SLSA GitHub Generator-Projekt ist das offizielle SLSA-Framework-Tooling fuer GitHub-native Projekte und ist darauf ausgelegt, SLSA Build Level 3 Provenance fuer unterstuetzte Workflows zu generieren.

Ein vereinfachter wiederverwendbarer Provenance-Job fuer Datei-Artefakte sieht so aus:

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      hashes: ${{ steps.hashes.outputs.subjects }}
    steps:
      - uses: actions/checkout@v4

      - name: Build artifact
        run: |
          mkdir -p dist
          tar -czf dist/payments-api.tar.gz src package.json package-lock.json

      - name: Compute artifact digest file
        run: sha256sum dist/payments-api.tar.gz > subject-digests.txt

      - name: Encode subjects for SLSA generator
        id: hashes
        uses: slsa-framework/slsa-github-generator/actions/generator/generic/create-base64-subjects-from-file@v2.1.0
        with:
          path: subject-digests.txt

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: ${{ needs.build.outputs.hashes }}
      upload-assets: true

Provenance vor Promotion verifizieren

GitHubs gh attestation verify verifiziert Build-Provenance-Attestationen, und SLSAs eigene Verifikations-Leitlinie sagt, der Verifizierer sollte die Signatur pruefen, sicherstellen, dass das Subjekt zum Artefakt-Digest passt, den Predicate-Type bestaetigen und die Builder-Identitaet mit einer vorkonfigurierten Vertrauenswurzel vergleichen.

Ein einfacher Verifikationsschritt fuer ein Container-Image sieht so aus:

gh attestation verify \
  "oci://ghcr.io/acme/payments-api:${GITHUB_SHA}" \
  -R acme/payments-api

Sie sollten nun Build-Provenance generiert haben und einen konkreten Ort, um sie vor Promotion oder Deploy zu verifizieren.

Schritt 4: Ein SBOM erstellen

Ein SBOM beantwortet eine andere Frage als Provenance. Provenance sagt Ihnen, wie das Artefakt gebaut wurde. Ein SBOM sagt Ihnen, was drin ist. GitHubs SBOM-Attestation-Flow unterstuetzt signierte SBOM-Attestationen, und Sigstore/Cosign unterstuetzen sowohl SPDX- als auch CycloneDX-SBOM-bezogene Workflows. SPDX und CycloneDX sind beide aktive, offizielle Standards, daher ist die wichtige operationelle Wahl nicht “welcher ist echt”, sondern welchen Sie als kanonisches internes Format verwenden werden.

Ein kanonisches Format waehlen

Eine gute Standardregel ist:

• Waehlen Sie SPDX JSON, wenn Ihre Organisation bereits stark auf Lizenz-/Compliance-Tooling oder das ISO-gestuetzte SPDX-Oekosystem setzt
• Waehlen Sie CycloneDX JSON, wenn Ihr Sicherheitstooling eher auf Application-Security und Abhaengigkeitsanalyse fokussiert ist

Beide sind gueltig. Der groessere Fehler ist, mehrere Formate ad hoc zu generieren und keine klare Wahrheitsquelle zu haben.

Das SBOM zur Build-Zeit generieren

Fuer GitHub Actions zeigen GitHubs SBOM-Attestation-Docs explizit darauf, zuerst das SBOM zu erstellen und es dann zu attestieren. Das folgende Beispiel verwendet Syft, um eine SPDX-JSON-Datei fuer das gebaute Image zu generieren. Syft ist ein weit verbreiteter SBOM-Generator fuer Images und Dateisysteme.

Fuegen Sie diese Schritte zum build-sign-Job nach dem Image-Build hinzu:

      # Check https://github.com/anchore/syft/releases for latest version
      - name: Install Syft
        run: |
          SYFT_VERSION="v1.42.1"
          curl -fsSL -o /tmp/syft.tar.gz \
            "https://github.com/anchore/syft/releases/download/${SYFT_VERSION}/syft_${SYFT_VERSION#v}_linux_amd64.tar.gz"
          tar -xzf /tmp/syft.tar.gz -C /tmp
          sudo mv /tmp/syft /usr/local/bin/syft

      - name: Generate SPDX SBOM for image
        env:
          IMAGE_URI: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}
        run: |
          syft "${IMAGE_URI}" -o spdx-json=sbom.spdx.json

Das SBOM mit dem Artefakt speichern

GitHubs aktueller SBOM-Attestation-Flow signiert das SBOM als Attestation, die mit dem Artefakt verknuepft ist. Sigstores Cosign unterstuetzt auch das Anhaengen oder Attestieren von SBOMs fuer OCI-Artefakte. Fuer eine praktische CI-Basislinie auf GitHub haelt die Verwendung der offiziellen attest-sbom-Action die Artefakt-zu-SBOM-Verknuepfung explizit und verifizierbar.

Fuegen Sie diesen Schritt nach der SBOM-Generierung hinzu. Der permissions-Block auf Job-Ebene muss attestations: write enthalten:

      - name: Generate signed SBOM attestation
        uses: actions/attest-sbom@v4
        with:
          subject-name: ${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.build.outputs.digest }}
          sbom-path: sbom.spdx.json
          push-to-registry: true

Die SBOM-Attestation verifizieren

GitHubs Verifikations-Flow unterstuetzt SBOM-Attestationen und erlaubt die Verifikation eines spezifischen Predicate-Types. Fuer SPDX ist der dokumentierte Predicate-Type https://spdx.dev/Document/v2.3.

gh attestation verify \
  "oci://ghcr.io/acme/payments-api:${GITHUB_SHA}" \
  -R acme/payments-api \
  --predicate-type https://spdx.dev/Document/v2.3

Sie sollten nun ein Build-Zeit-SBOM, eine signierte Attestation, die es an das Artefakt bindet, und einen Verifikationspfad vor dem Deployment haben.

Schritt 5: Verifikations-Gates hinzufuegen

Hier wird die Basislinie real. SLSAs Verifikations-Leitlinie ist deutlich: Provenance bewirkt nichts, es sei denn, jemand inspiziert sie. Dieselbe Logik gilt fuer Signaturen und SBOMs. Generierung ohne Gates ist ein Dashboard-Feature, keine Kontrolle.

Unsignierte Artefakte blockieren

Ein Deploy- oder Promotion-Job sollte fehlschlagen, wenn die Artefakt-Signatur fehlt oder die Signieridentitaet nicht dem entspricht, was Sie erwarten. In GitHub/Sigstore-Begriffen bedeutet das normalerweise die Verifikation des OIDC-Issuers und das Abgleichen der Zertifikatsidentitaet mit dem Release-Workflow oder einem vertrauenswuerdigen Regex-Muster.

Nicht vertrauenswuerdige Provenance blockieren

Verlangen Sie mindestens, dass das Artefakt eine gueltige Provenance-Attestation von Ihrem erwarteten Repo und Builder hat. Wenn Sie GitHub-Artefakt-Attestationen verwenden, verifizieren Sie sie mit gh attestation verify. Wenn Sie SLSA-native Builder verwenden, validieren Sie auch die Builder-Identitaet und die erwartete Quelle oder Ref.

Unbekannte Abhaengigkeiten vor dem Deploy markieren

Ein SBOM ist am nuetzlichsten, wenn Sie es tatsaechlich mit einer Policy vergleichen. Gute erste Pruefungen sind:

• keine Pakete aus nicht genehmigten Registries
• kein leeres oder offensichtlich unvollstaendiges SBOM
• keine kritischen unbekannten Lizenzen, falls Ihre Organisation das verfolgt
• keine neu eingefuehrten Komponenten ausserhalb erlaubter Abhaengigkeits-Policy

Ein einfaches Gate-Skript kann die minimale Basislinie erzwingen:

File: deploy-verify.sh

#!/usr/bin/env bash
set -euo pipefail

IMAGE_URI="$1"
REPO="acme/payments-api"

echo "1) Verify Sigstore signature"
cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "https://github.com/acme/payments-api/.github/workflows/release.yml@refs/heads/main" \
  "${IMAGE_URI}" >/dev/null

echo "2) Verify build provenance"
gh attestation verify \
  "oci://${IMAGE_URI}" \
  -R "${REPO}" >/dev/null

echo "3) Verify SBOM attestation"
gh attestation verify \
  "oci://${IMAGE_URI}" \
  -R "${REPO}" \
  --predicate-type "https://spdx.dev/Document/v2.3" >/dev/null

echo "4) Pull SBOM payload for policy checks"
gh attestation verify \
  "oci://${IMAGE_URI}" \
  -R "${REPO}" \
  --predicate-type "https://spdx.dev/Document/v2.3" \
  --format json \
  --jq '.[].verificationResult.statement.predicate' > verified-sbom.json

# Check that the SBOM contains package data (SPDX uses .packages, CycloneDX uses .components)
jq -e '.packages // .components | length > 0' verified-sbom.json >/dev/null

echo "All supply-chain checks passed"

Zur Deployment- oder Admission-Zeit erzwingen

Wenn Ihr Deploy-Ziel Kubernetes ist, ist Admission der sauberste Ort, um “kein unsigniertes Image” oder “kein Image ohne erforderliche Attestation” durchzusetzen. Sigstore Policy-Controller ist genau fuer diesen Anwendungsfall gebaut und kann Signatur- und Attestation-Policies bei der Admission evaluieren.

Sie sollten nun ein Gate haben, das Artefakte blockiert, denen eine gueltige Signatur, gueltige Provenance oder eine gueltige SBOM-Attestation fehlt.

Schritt 6: Pipeline-Identitaeten absichern

Eine gehaertete Supply-Chain-Pipeline versagt trotzdem, wenn der Runner zu viel imitieren kann oder wenn Secrets zu lange leben. GitHubs OIDC-Modell existiert gerade deshalb, damit Workflows sich bei Cloud-Providern und anderen Diensten authentifizieren koennen, ohne langlebige statische Credentials in Secrets zu speichern. GitHub dokumentiert auch das explizite Verschaerfen von GITHUB_TOKEN-Berechtigungen statt breite Defaults bestehen zu lassen.

OIDC gegenueber langlebigen Secrets bevorzugen

Fuer Cloud-Deploys und Registry-Zugriff bevorzugen Sie kurzlebige, foederierte Credentials, wo Ihre Plattform sie unterstuetzt. Das reduziert den Explosionsradius geleakter Token und bindet die Vertrauensentscheidung zurueck an die Workflow-Identitaet. Sigstores Keyless-Modell folgt demselben Prinzip fuer das Signieren.

Standard-Workflow-Berechtigungen reduzieren

Fuehren Sie Release-Workflows nicht mit breiten Repository-Berechtigungen aus, es sei denn, der Job braucht sie wirklich. Ein Release-Workflow, der nur Quellcode liest, Pakete schreibt, Artefakte signiert und Attestationen schreibt, kann das normalerweise direkt sagen.

permissions:
  contents: read
  packages: write
  id-token: write
  attestations: write

Branches und Environments schuetzen

SLSAs Guidance fuer hoehere Level betont vertrauenswuerdige Builder und geschuetzte Control-Planes, nicht nur signierte Outputs. In praktischen CI-Begriffen bedeutet das:

• Release-Branches schuetzen
• Tags schuetzen
• Environment-Approvals fuer Produktions-Deploys verwenden
• Einschraenken, wer Release-Workflows aendern kann
• Self-Hosted Runner vorsichtig isolieren, falls Sie sie verwenden

Diese Kontrollen sind nicht getrennt von Supply-Chain-Sicherheit. Sie sind der Weg, um zu verhindern, dass ein Mensch oder Workflow das Builder-Vertrauen umgeht, das Sie aufzubauen versuchen.

Token-Lebensdauer kurz und Secrets gescopt halten

Gute Defaults umfassen:

• keine langlebigen Registry-Passwoerter in CI, wenn OIDC oder kurzlebige Token verfuegbar sind
• Environment-gescoptete Secrets
• Deploy-Credentials getrennt von Build-Credentials
• keine Wiederverwendung breiter persoenlicher Token fuer Automatisierung

Sie sollten nun ein engeres Identitaetsmodell fuer Runner, Token und geschuetzte Workflows haben.

Schritt 7: Eine minimale Policy-Basislinie aufbauen

Eine Basislinie ist das, was Supply-Chain-Haertung davor bewahrt, aspirationell zu werden. GitHubs Artefakt-Attestation-Docs sind klar, dass Attestationen keine Garantie sind, dass ein Artefakt sicher ist; sie erlauben Ihnen, Policy mithilfe der Build- und Herkunftsinformationen zu definieren und durchzusetzen, die sie exponieren. SLSAs Verifikationsmodell sagt dasselbe in anderen Worten: Vertrauen kommt aus dem Pruefen der Attestation gegen Ihre Erwartungen.

Mit einer kleinen, erzwungenen Policy beginnen

Eine praktische Basislinie fuer ein kleines oder mittelgrosses Team ist:

• jedes deploybare Artefakt muss signiert sein
• jedes deploybare Artefakt muss Build-Provenance haben
• jedes deploybare Artefakt muss ein SBOM haben
• Deploys schlagen fehl, wenn die Verifikation fehlschlaegt
• Ausnahmen erfordern manuelle Genehmigung und Ablauf

File: supply-chain-policy.yaml

required:
  signature: true
  provenance: true
  sbom: true

trusted_signers:
  - issuer: https://token.actions.githubusercontent.com
    identity_regex: https://github.com/acme/payments-api/.github/workflows/release.yml@refs/heads/main

provenance:
  trusted_repo: acme/payments-api
  trusted_branch: refs/heads/main

sbom:
  predicate_type: https://spdx.dev/Document/v2.3
  must_include_dependencies: true

exceptions:
  max_duration_hours: 24
  approvers:
    - platform-team
    - security-team

Einen einfachen Ausnahme-Workflow hinzufuegen

Ausnahmen sind kein Versagen. Permanente Ausnahmen sind es. Halten Sie sie explizit:

File: exception-request.md

# Supply-Chain Policy Exception

- Artifact:
- Reason:
- Missing control: signature / provenance / SBOM
- Requested by:
- Approved by:
- Expiration time:
- Remediation issue:

Wie gute Reife im Laufe der Zeit aussieht

Ein vernuenftiger Reifepfad ist:

1. Signaturen, Provenance und SBOMs generieren
2. sie vor dem Deploy verifizieren
3. Builder-Identitaeten und Workflow-Berechtigungen einengen
4. zur Admission- oder Promotion-Zeit erzwingen
5. wiederverwendbare Build-Workflows und strengeres Provenance-Vertrauen standardisieren

Diese Progression stimmt mit der Oekosystem-Richtung von OpenSSF rund um Supply-Chain-Sicherheit ueberein und mit SLSAs eigenem Schwerpunkt auf der Bewegung von “Metadaten existieren” zu “Metadaten sind vertrauenswuerdig und verifiziert.”

Haeufige Einrichtungsprobleme

SBOMs generieren, aber nicht verwenden

Teams produzieren oft SBOMs, weil das Tooling einfach ist, verifizieren dann nie die Attestation, haengen das SBOM nie an das Artefakt an und vergleichen dessen Inhalt nie mit einer Policy. GitHubs SBOM-Attestation-Workflow und Verifikationsbefehle existieren speziell, damit das SBOM Teil eines verifizierbaren Release-Records werden kann, statt eine lose Datei in Build-Artefakten.

Artefakte signieren ohne Verifikation

Dies ist der einzeln haeufigste Fehlermodus. Sigstore, GitHub-Artefakt-Attestationen und SLSAs Verifikations-Guidance nehmen alle an, dass jemand das Ergebnis gegen eine vertrauenswuerdige Identitaet oder Vertrauenswurzel verifiziert. Wenn Ihr Deploy-Schritt nie prueft, hat die Kontrolle keine Zaehne.

SLSA nur als Compliance behandeln

SLSA ist nicht nur ein Berichtslabel. Sein Provenance- und Verifikationsmodell geht darum, ob ein Verifizierer vertrauen kann, welcher Builder das Artefakt produziert hat und aus welcher Quelle es kam. Wenn Sie bei “wir haben eine Provenance-Datei” aufhoeren, verpassen Sie den gesamten Sinn.

Menschlichen Zugriff auf die Pipeline ignorieren

Eine starke Signier-Geschichte hilft nicht viel, wenn zu viele Leute den Release-Workflow bearbeiten, Branch-Protection umgehen oder Deploys von unreviewed Branches ausfuehren koennen. SLSAs Builder-Trust-Modell und GitHubs Guidance rund um wiederverwendbare Workflows und geschuetzte Identitaeten weisen beide auf dieselbe Schlussfolgerung: Menschlicher Zugriff auf die Control-Plane ist wichtig.

Zusammenfassung

Eine praktische CI/CD-Supply-Chain-Basislinie ist nicht riesig. Beginnen Sie damit, die Pipeline zu kartieren, das deploybare Artefakt mit Sigstore zu signieren, Provenance auszugeben, die Ihr Deploy-System verifizieren kann, ein SBOM in einem kanonischen Format zu generieren und dann das Deployment zu blockieren, wenn diese Pruefungen fehlschlagen. Das bringt Sie bereits viel weiter als “wir haben einige Metadaten in CI generiert.”

Fuer kleine Teams sind die Quick Wins unkompliziert: Keyless-Signierung, Build-Provenance-Attestation, ein einzelnes SBOM-Format, minimale Workflow-Berechtigungen und ein Pre-Deploy-Verifikationsskript. Im Laufe der Zeit sieht Reife aus wie wiederverwendbare gehaertete Build-Workflows, strengeres Provenance-Vertrauen, Admission-Zeit-Durchsetzung und weniger langlebige Credentials irgendwo im Pfad von der Quelle bis zur Produktion.

Wenn Ihre CI/CD-Pipeline auch AI-generierten Code von Coding-Agenten verarbeitet, ergaenzen Sie diese Supply-Chain-Haertung mit AI-Coding-Agent-Pipelines absichern, das Erkennung, Policy-Durchsetzung, Sicherheitsscanning und risikobasierte Review-Gates fuer AI-generierte PRs abdeckt.