Supply Chain Security 2026: SBOM, Sigstore/SLSA und Admission Control als DevOps-Standard

Software-Lieferkettenangriffe kosten die globale Wirtschaft im Jahr 2026 schätzungsweise 80,6 Milliarden US-Dollar – ein Anstieg von 76 Prozent gegenüber 2023. Allein die Jaguar-Land-Rover-Attacke im August 2025 verursachte einen Schaden von 1,9 Milliarden Pfund und legte die Produktion für fünf Wochen lahm. Angriffe auf Container-Images, CI/CD-Pipelines und Build-Systeme sind keine Zukunftsszenarien mehr, sondern die neue Realität für DevOps-Teams. Mit dem Inkrafttreten der ersten EU-Cyber-Resilience-Act-(CRA)-Berichtspflichten im September 2026 wird Supply-Chain-Sicherheit vom Nice-to-have zur regulatorischen Pflicht.

SBOM: Das digitale Inhaltsverzeichnis für Software

Ein Software Bill of Materials (SBOM) ist die Grundlage jeder Supply-Chain-Sicherheit. Es listet alle Komponenten, Bibliotheken und Abhängigkeiten einer Anwendung auf – ähnlich der Zutatenliste auf einem Lebensmittel. Die EU-CRA schreibt ab September 2026 für Produkte mit digitalen Elementen ein SBOM in maschinenlesbarem Format vor, das zumindest die wichtigsten Abhängigkeiten erfasst.

Die beiden dominierenden SBOM-Formate sind CycloneDX und SPDX. Für containerisierte Anwendungen hat sich CycloneDX als De-facto-Standard etabliert, da es speziell auf Container-Umgebungen ausgelegt ist. In der CI/CD-Pipeline kann das Open-Source-Tool Syft SBOMs automatisiert erzeugen:

syft ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.cyclonedx.json

Ein SBOM allein schützt jedoch nicht vor Angriffen – es dokumentiert nur die Angriffsfläche. Die eigentliche Sicherheit entsteht durch Signieren, Verifizieren und Durchsetzen von Richtlinien.

Sigstore: Keyless Signing für Container-Images

Sigstore ist ein Open-Source-Projekt der Linux Foundation, das kryptografische Signierung ohne das Management eigener GPG-Schlüssel oder PKI-Infrastruktur ermöglicht. Das dahinterstehende Werkzeug Cosign nutzt OIDC-Token aus CI-Plattformen wie GitHub Actions oder GitLab CI als Identität – sogenanntes keyless signing.

Die praktische Anwendung ist denkbar einfach:

cosign sign --yes ghcr.io/myorg/myapp:v1.2.3

Zur Verifikation reicht:

cosign verify \
  --certificate-identity=ci@myorg.com \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/myapp:v1.2.3

Da die Identität direkt aus dem CI-Kontext stammt, entfällt das Problem der Schlüsselverwaltung. Keine Secrets, die rotiert, gesichert oder geleakt werden können.

SLSA: Reifegradmodell für Build-Integrität

Das SLSA-Framework (Supply-chain Levels for Software Artifacts, ausgesprochen „salsa") definiert vier Stufen der Build-Integrität:

• Level 1: Der Build-Prozess ist dokumentiert und nicht manuell.
• Level 2: Der Build läuft gehostet und versioniert, die Herkunft (Provenance) wird als Attestation festgehalten.
• Level 3: Die Build-Plattform selbst ist gehärtet – isolierte, immutable Build-Umgebungen verhindern Manipulation.
• Level 4: Zwei-Personen-Review und hermetische Builds (vollständig reproduzierbar).

Die meisten Organisationen sollten mindestens SLSA Level 3 anstreben. Dort wird sichergestellt, dass ein Angreifer, der Zugriff auf das CI-System erlangt hat, keine manipulierten Artefakte ausliefern kann, ohne dass dies nachweisbar wäre. SLSA Level 4 ist aktuell nur für besonders kritische Infrastrukturkomponenten realistisch.

Kubernetes Admission Control: Die Durchsetzungsebene

Signierte Images nützen wenig, wenn die Signatur nicht auch erzwungen wird. Hier kommen Kubernetes-Admission-Controller ins Spiel. Mit Kyverno oder OPA/Gatekeeper lässt sich durchsetzen, dass nur signierte Images auf einem Cluster laufen dürfen:

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

Diese Richtlinie blockiert jeden Pod, dessen Container-Image keine gültige Cosign-Signatur mit der erwarteten Identität aufweist. Unsigned oder manipulierte Images landen automatisch im Reject – bevor sie überhaupt ausgeführt werden.

Die vollständige DevOps-Pipeline

Aus der Praxis hat sich ein sechsstufiger Sicherheitsworkflow etabliert:

1. Build – Reproduzierbare, hermetische Builds in isolierten CI-Umgebungen
2. Scannen – Vulnerability-Scanning mit Trivy oder Grype direkt nach dem Build
3. Signieren – Keyless Signing mit Cosign und Sigstore
4. Attestieren – SBOM und Scan-Ergebnisse als verifizierbare Attestationen anhängen
5. Verifizieren – Admission Controller (Kyverno/OPA) erzwingen signierte Images im Cluster
6. Überwachen – Kontinuierliches Scannen laufender Container auf neue CVEs

Organisationen, die diesen Workflow implementieren, melden 76 Prozent weniger Sicherheitsvorfälle in der Lieferkette und sparen durchschnittlich 1,76 Millionen US-Dollar pro verhindertem Breach.

Fazit

Supply-Chain-Security ist 2026 kein optionales DevSecOps-Add-on mehr. Mit dem EU Cyber Resilience Act sind SBOMs und nachweisbare Build-Integrität für viele Unternehmen bereits regulatorische Pflicht. Die gute Nachricht: Die Werkzeuge sind reif, open source und produktionserprobt. Sigstore/Cosign, das SLSA-Framework und Kubernetes-Admission-Controller bilden einen Dreiklang, der Angriffe auf die Software-Lieferkette wirksam unterbindet. DevOps-Teams, die heute mit SBOM-Generierung, keyless Signing und Kyverno-Policys beginnen, sind nicht nur sicherer unterwegs – sie sind auch regulatorisch auf der sicheren Seite.

Quellen

• Container Supply Chain Security 2026: Why 67% Can’t Detect the Threat — Gheware DevOps AI Blog
• Supply Chain Security in 2026: SLSA, Sigstore, and Cosign — Luca Berton
• CRA SBOM Requirements 2026 — CycloneDX vs SPDX — sota.io Blog
• Software Supply Chain Security: The 2026 Threat Landscape — Medium / DevOps AI Decoded
• Supply Chain Security 2026: Sigstore and SLSA 3 Guide — Tech Bytes