Software Supply Chain Security: Warum SBOMs 2026 unverzichtbar werden

Von Benedikt Langer · 28. Januar 2026 · 5 Minuten Lesezeit

SolarWinds, Log4Shell, 3CX – die Liste erfolgreicher Software-Supply-Chain-Angriffe wird jedes Jahr länger. Sonatype beziffert den Anstieg von Supply-Chain-Angriffen auf Open-Source-Komponenten auf über 700 Prozent seit 2020. Gleichzeitig macht der EU Cyber Resilience Act Software Bills of Materials (SBOMs) ab 2027 zur Pflicht für alle digitalen Produkte. Unternehmen, die jetzt nicht handeln, stehen bald ohne Marktzugang da.

Das Wichtigste in Kürze

700 % mehr Supply-Chain-Angriffe seit 2020: Open-Source-Dependencies sind das primäre Einfallstor: im Schnitt nutzt eine Anwendung 200+ transitive Abhängigkeiten (Sonatype, 2025).
EU Cyber Resilience Act (CRA): Ab 2027 müssen alle digitalen Produkte mit SBOM, Schwachstellenmanagement und Security-Updates ausgeliefert werden.
DevSecOps-Integration: SBOM-Generierung, Dependency-Scanning und Container-Signing gehören in die CI/CD-Pipeline – nicht in die manuelle Checkliste.

Anatomie eines Supply-Chain-Angriffs

Supply-Chain-Angriffe zielen auf die Abhängigkeiten der Software: Libraries, Frameworks, Build-Tools und Infrastruktur-Komponenten. Der Angriffsvektor ist besonders effektiv, weil ein kompromittiertes Paket automatisch an Tausende Downstream-Nutzer verteilt wird.

Die gängigsten Methoden: Typosquatting (ein Paket mit fast identischem Namen wie ein populäres Paket veröffentlichen), Account-Takeover (den Account eines vertrauenswürdigen Maintainers übernehmen), Dependency Confusion (ein internes Paket mit einem öffentlichen gleichen Namens überschreiben) und Build-System-Kompromittierung (den Build-Server oder die CI/CD-Pipeline manipulieren).

Der 3CX-Vorfall 2023 zeigte die volle Tragweite: Angreifer kompromittierten eine von 3CX genutzte Upstream-Bibliothek. Der manipulierte Code landete im offiziellen 3CX-Desktop-Client, der von über 600.000 Unternehmen genutzt wird. Die Erkennung dauerte Wochen.

„Software-Lieferketten sind das schwächste Glied in der Cybersicherheit. Unternehmen vertrauen Code blind, den sie weder geschrieben noch geprüft haben – und der oft von unbezahlten Einzelpersonen gepflegt wird.“
– Brian Behlendorf, General Manager, Open Source Security Foundation (2025)

SBOMs, Signaturen und der EU Cyber Resilience Act

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis aller Komponenten einer Software – inklusive Versionen, Lizenzen und bekannter Schwachstellen. Die beiden Standards sind SPDX (Linux Foundation) und CycloneDX (OWASP). Beide sind funktional gleichwertig und werden von den wichtigsten Tools unterstützt.

Der EU Cyber Resilience Act (CRA) macht SBOMs ab 2027 zur Pflicht für alle digitalen Produkte, die in der EU verkauft werden. Hersteller müssen Schwachstellen aktiv managen, Security-Updates für die gesamte Produktlebenszeit bereitstellen und SBOMs an die ENISA übermitteln. Das betrifft Softwarehersteller ebenso wie IoT-Geräte, Industriesteuerungen und vernetzte Consumer-Produkte.

Code-Signing und Artefakt-Signaturen ergänzen SBOMs: Tools wie Sigstore (Linux Foundation) ermöglichen kryptographische Signierung von Build-Artefakten und Container-Images – kostenlos und transparent. So kann jeder Nutzer verifizieren, dass ein Artefakt tatsächlich aus der erwarteten Build-Pipeline stammt und nicht manipuliert wurde.

+ 700 %

Anstieg von Supply-Chain-Angriffen auf Open-Source-Komponenten seit 2020. Im Durchschnitt enthält jede Anwendung über 200 transitive Dependencies.

Sonatype State of the Software Supply Chain Report, 2025

DevSecOps-Pipeline: Sicherheit als Teil des Build-Prozesses

Supply Chain Security funktioniert nur, wenn sie als automatisierter Teil der CI/CD-Pipeline in den Entwicklungsprozess integriert ist:

Dependency Scanning: Tools wie Snyk, Grype oder Dependabot scannen bei jedem Build automatisch alle direkten und transitiven Abhängigkeiten auf bekannte CVEs. Kritische Schwachstellen blockieren den Build – kein Merge ohne Fix oder dokumentierte Risiko-Akzeptanz.

SBOM-Generierung: Syft (Anchore) oder cdxgen generieren bei jedem Release automatisch eine SBOM im CycloneDX- oder SPDX-Format. Die SBOM wird als Build-Artefakt gespeichert und kann an Kunden oder Regulierungsbehörden weitergegeben werden.

Container-Security: Container-Images sind besonders anfällig – ein typisches Base-Image enthält hunderte Pakete, viele davon mit bekannten Schwachstellen. Trivy oder Grype scannen Images vor dem Deployment. Distroless-Images (Google) oder Chainguard-Images reduzieren die Angriffsfläche radikal.

Artefakt-Signierung: Jedes Build-Artefakt wird mit Sigstore/Cosign signiert. Kubernetes-Cluster können per Policy (z.B. Kyverno, OPA Gatekeeper) nur signierte Images akzeptieren – unsignierte Deployments werden automatisch blockiert.

Der Aufwand für die Integration ist überschaubar: In einer bestehenden GitHub-Actions- oder GitLab-CI-Pipeline sind die zusätzlichen Steps in einem Tag implementierbar. Die Tools sind Open Source und kostenlos.

Häufige Fragen

Was ist eine SBOM?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis aller Komponenten einer Software – Libraries, Frameworks, Abhängigkeiten – inklusive Versionsnummern, Lizenzen und bekannter Schwachstellen. Vergleichbar mit einer Zutatenliste für Software.

Welches SBOM-Format sollte ich verwenden?

CycloneDX (OWASP) und SPDX (Linux Foundation) sind die beiden etablierten Standards. CycloneDX hat bessere Vulnerability-Integration, SPDX ist stärker bei Lizenzanalyse. Für Security-Fokus empfiehlt sich CycloneDX, für Compliance-Fokus SPDX. Die meisten Tools unterstützen beide.

Wann tritt der EU Cyber Resilience Act in Kraft?

Der CRA wurde 2024 verabschiedet. Hersteller haben eine Übergangsfrist bis 2027, um ihre Produkte konform zu machen. Ab dann müssen alle digitalen Produkte in der EU mit SBOM, aktivem Schwachstellenmanagement und Security-Updates ausgeliefert werden.

Wie fange ich mit Supply Chain Security an?

Drei Sofortmaßnahmen: 1) Dependency-Scanning in die CI/CD-Pipeline integrieren (Snyk, Dependabot – kostenlose Tiers verfügbar). 2) SBOM-Generierung automatisieren (Syft, cdxgen). 3) Container-Images mit Trivy scannen. Alles zusammen ist an einem Tag implementierbar.

Was ist Sigstore?

Sigstore ist ein Open-Source-Projekt der Linux Foundation für kryptographische Signierung von Software-Artefakten. Es ermöglicht Entwicklern, Code, Container-Images und andere Artefakte kostenlos zu signieren – ohne eigene PKI-Infrastruktur. Die Signaturen sind transparent und öffentlich verifizierbar.

Sind Open-Source-Komponenten unsicherer als proprietäre?

Nicht grundsätzlich – aber sie sind transparenter angreifbar. Der Code ist öffentlich, was sowohl Angreifern als auch Verteidigern hilft. Das Hauptrisiko liegt bei ungepflegten Projekten mit einzelnen Maintainern. Tools wie OpenSSF Scorecard bewerten die Sicherheitsreife von Open-Source-Projekten automatisch.

Weiterführende Lektüre im Netzwerk

Cloud & DevOps: Container Security Best Practices (CloudMagazin)

Software-Entwicklung: DevSecOps: Sicherheit in der Softwareentwicklung (MBF)

Quelle Titelbild: Pexels / cottonbro studio