SBOM & Software-Lieferketten-Sicherheit

Was ist ein SBOM?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis aller Komponenten, Bibliotheken und Abhängigkeiten, die in einer Software enthalten sind — vergleichbar mit einer Zutatenliste auf einer Lebensmittelverpackung. Ein SBOM enthält typischerweise: den Komponentennamen, die Version, den Lizenztyp, den Hersteller oder Maintainer, kryptographische Hashes zur Integritätsprüfung sowie die Beziehungen zwischen den Komponenten (Abhängigkeitsbaum). Moderne Softwareprodukte bestehen zu 70–90 % aus Open-Source-Komponenten und transitiven Abhängigkeiten. Ohne ein SBOM wissen Unternehmen schlicht nicht, was in ihrer Software steckt — und können daher Schwachstellen wie Log4Shell (CVE-2021-44228) weder schnell identifizieren noch beheben.

Die US-Regierung hat SBOMs bereits 2021 mit der Executive Order 14028 für alle Bundesbehörden-Lieferanten verpflichtend gemacht. Die EU folgt nun mit dem Cyber Resilience Act und macht SBOMs ab 2027 zur gesetzlichen Pflicht für nahezu alle Produkte mit digitalen Elementen. SBOMs sind damit kein optionales Nice-to-have mehr, sondern werden zum regulatorischen Standard.

Zwei Formate haben sich als industrieweite Standards durchgesetzt:

• SPDX (Software Package Data Exchange): Entwickelt von der Linux Foundation und seit 2021 ein ISO/IEC 5962-Standard. SPDX unterstützt JSON, YAML, RDF und Tag-Value als Ausgabeformate und bietet umfangreiche Lizenzinformationen — ideal für Compliance-Anforderungen. SPDX 3.0 (veröffentlicht April 2024) erweitert das Format um Sicherheits- und Build-Informationen und unterstützt neben Software auch Hardware-, Daten- und KI/ML-Modell-Inventare.
• CycloneDX: Entwickelt von der OWASP Foundation, mit starkem Fokus auf Sicherheit und Schwachstellenmanagement. CycloneDX unterstützt JSON und XML, integriert sich nahtlos mit Vulnerability Exploitability eXchange (VEX) und bietet native Unterstützung für Software-, Hardware-, Service- und ML-Model-Inventare. CycloneDX 1.6 (veröffentlicht 2024) führt Attestation-Support und erweiterte Krypto-Informationen (CBOM — Cryptography Bill of Materials) ein. In der Praxis nutzen sicherheitsorientierte Teams häufig CycloneDX, während lizenzorientierte Teams SPDX bevorzugen.
• VEX (Vulnerability Exploitability eXchange): Ein ergänzendes Format, das angibt, ob eine in einem SBOM aufgeführte Schwachstelle tatsächlich ausnutzbar ist oder nicht. VEX reduziert „Alert Fatigue“ erheblich: Statt hunderte CVEs aus transitiven Abhängigkeiten manuell zu bewerten, kann der Hersteller per VEX-Statement erklären, ob eine Schwachstelle im konkreten Kontext relevant ist („affected“, „not affected“, „fixed“ oder „under investigation“).

Supply-Chain-Angriffe 2026

Software-Supply-Chain-Angriffe haben sich zu einer der größten Bedrohungen in der Cybersicherheit entwickelt. Laut Sonatype’s State of the Software Supply Chain Report 2025 hat sich die Zahl der Angriffe auf Software-Lieferketten gegenüber 2024 verdoppelt. Gartner prognostiziert, dass bis 2026 70 % der Unternehmen von mindestens einem Supply-Chain-Angriff betroffen sein werden.

• Typosquatting und Dependency Confusion: Angreifer veröffentlichen bösartige Pakete mit Namen, die populären Bibliotheken ähneln (z. B. reqeusts statt requests). In npm, PyPI und RubyGems wurden 2025 über 700.000 verdächtige Pakete identifiziert. Dependency-Confusion-Angriffe nutzen die Tatsache aus, dass viele Build-Systeme öffentliche Repositories gegenüber internen bevorzugen — ein internes Paket company-utils kann durch ein gleichnamiges bösartiges Paket auf npm ersetzt werden.
• Kompromittierte Container-Images: Angriffe auf Container-Registries und manipulierte Base-Images nehmen zu. Im Frühjahr 2025 wurden auf Docker Hub über 4 Millionen Images als potenziell bösartig eingestuft — viele davon mit Crypto-Minern, Backdoors oder Credential-Stealern. Das Problem: Entwickler ziehen oft latest-Tags ohne Integritätsprüfung, und selbst offizielle Base-Images können hunderte bekannte CVEs enthalten.
• KI-gestützte Supply-Chain-Angriffe: Mit der Verbreitung von KI-gestützter Softwareentwicklung (GitHub Copilot, Cursor, Claude Code) entstehen neue Angriffsflächen. KI-generierter Code kann „halluzinierte“ Abhängigkeiten referenzieren — Pakete, die nicht existieren und von Angreifern mit bösartigem Code registriert werden können (AI Package Hallucination Attack). Darüber hinaus wurden auf Plattformen wie Hugging Face manipulierte KI-Modelle mit eingebetteten Backdoors entdeckt.
• Maintainer-Übernahme: Angreifer übernehmen die Kontrolle über populäre Open-Source-Projekte, indem sie sich als hilfsbereite Contributor einbringen und schrittweise Vertrauen aufbauen — bevor sie bösartigen Code einschleusen. Der XZ Utils-Angriff (CVE-2024-3094) im März 2024 hat dieses Risiko dramatisch illustriert: Ein Angreifer arbeitete über zwei Jahre als Maintainer am xz-Komprimierungstool, bevor er eine Backdoor in die SSH-Authentifizierung einbaute, die nahezu alle Linux-Distributionen betroffen hätte.
• CI/CD-Pipeline-Kompromittierung: Build-Systeme und CI/CD-Pipelines sind ein zunehmend attraktives Ziel. Angreifer kompromittieren GitHub-Actions-Workflows, GitLab-Runner oder Jenkins-Server, um bösartigen Code während des Build-Prozesses einzuschleusen. Das Ergebnis: Der Quellcode ist sauber, aber das ausgelieferte Artefakt enthält Malware. Dieser Angriffsvektor wurde 2025 bei mehreren prominenten Vorfällen beobachtet, darunter kompromittierte GitHub Actions in weit verbreiteten Open-Source-Projekten. Frameworks wie SLSA (Supply-chain Levels for Software Artifacts) adressieren dieses Problem durch verifizierbare Build-Provenance.

Die Konsequenz: Ohne Transparenz über die eigene Software-Lieferkette — also ohne SBOM — können Unternehmen weder erkennen, ob sie von einer kompromittierten Komponente betroffen sind, noch rechtzeitig reagieren. Log4Shell hat 2021 gezeigt, dass Unternehmen Wochen bis Monate brauchten, um herauszufinden, wo in ihren Systemen die verwundbare log4j-Bibliothek eingesetzt wurde. Mit einem aktuellen SBOM hätte diese Frage in Minuten beantwortet werden können.

EU Cyber Resilience Act (CRA)

Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) wurde im Oktober 2024 verabschiedet und tritt stufenweise bis Dezember 2027 in Kraft. Der CRA ist das weltweit erste Gesetz, das Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen verbindlich vorschreibt — von IoT-Geräten und Routern über Software und Betriebssysteme bis hin zu industriellen Steuerungssystemen. Für SBOMs ist der CRA ein Meilenstein: Er macht eine maschinenlesbare Software-Stückliste zur gesetzlichen Pflicht.

• SBOM-Pflicht (Anhang I, Teil II): Hersteller von Produkten mit digitalen Elementen müssen ein SBOM erstellen und aktuell halten, das mindestens die Top-Level-Abhängigkeiten der Software dokumentiert. Das SBOM muss der Marktüberwachungsbehörde auf Anfrage in einem gängigen maschinenlesbaren Format (SPDX oder CycloneDX) zur Verfügung gestellt werden. Der CRA verlangt keine Veröffentlichung des SBOMs gegenüber Endkunden, aber eine Bereitstellung an Behörden und — für digitale Elemente in kritischen Produkten (Klasse I und II) — an notifizierte Stellen.
• Schwachstellenbehandlung (Art. 14): Hersteller müssen Schwachstellen in ihren Produkten während der gesamten Supportdauer (mindestens 5 Jahre) aktiv behandeln: Sicherheitsupdates unentgeltlich bereitstellen, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden an die ENISA melden und ein koordiniertes Schwachstellenmanagement implementieren. SBOMs sind dabei das zentrale Werkzeug, um betroffene Produkte schnell zu identifizieren.
• Zeitplan: Der CRA tritt stufenweise in Kraft: Ab September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen. Ab Dezember 2027 gelten alle Anforderungen einschließlich der SBOM-Pflicht, der CE-Kennzeichnung und der Konformitätsbewertung. Hersteller haben also noch bis Ende 2027 Zeit, ihre Prozesse anzupassen — aber die Komplexität der Umsetzung (SBOM-Generierung, Schwachstellenmonitoring, Update-Prozesse) erfordert einen frühzeitigen Start.
• Wer ist betroffen? Nahezu jedes Unternehmen, das Software oder Geräte mit Software-Anteilen in der EU vertreibt. Der CRA gilt für Hersteller, Importeure und Händler. Ausnahmen gelten für reine Open-Source-Software (nicht-kommerziell), medizinische Geräte (eigene Regulierung), Luftfahrt und Kraftfahrzeuge (eigene Regulierung). Bußgelder: Bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes für Verstöße gegen wesentliche Anforderungen.
• Produkte der Klassen I und II: Der CRA unterscheidet zwischen Standard-Produkten und Produkten mit erhöhtem Risiko. Klasse I (z. B. Passwort-Manager, VPN-Software, Firewalls, Betriebssysteme) erfordert harmonisierte Standards oder eine Bewertung durch Dritte. Klasse II (z. B. Hypervisoren, HSMs, chipkarten-basierte Sicherheitselemente, Smart-Meter-Gateways) erfordert zwingend eine Konformitätsbewertung durch eine benannte Stelle (Notified Body). Für Klasse-II-Produkte ist das SBOM besonders kritisch, da es Teil der Konformitätsdokumentation wird.
• Open-Source-Software und der CRA: Die Sonderstellung von Open Source war eine der umstrittensten Fragen während der Verhandlungen. Der finale Text befreit nicht-kommerzielle Open-Source-Software von den Herstellerpflichten. Allerdings wird ein neuer Status des „Open-Source-Software-Verwalters“ (Open Source Steward) eingeführt: Organisationen, die die Entwicklung von Open-Source-Software koordinieren (z. B. Stiftungen wie die Apache Foundation oder Eclipse Foundation), unterliegen vereinfachten Pflichten, insbesondere zur Dokumentation von Schwachstellenbehandlungsprozessen. Kommerzielle Unternehmen, die Open-Source-Komponenten in ihre Produkte integrieren, bleiben vollständig verantwortlich.

Praktische Umsetzung

Die Implementierung einer robusten Software-Supply-Chain-Sicherheit erfordert einen mehrschichtigen Ansatz, der SBOM-Generierung, Signierung, kontinuierliche Verifizierung und Integration in die CI/CD-Pipeline umfasst. Die folgenden Tools und Frameworks bilden das Fundament einer modernen Supply-Chain-Sicherheitsstrategie.

• SBOM-Generierung: Für die automatisierte SBOM-Erstellung stehen mehrere ausgereifte Tools zur Verfügung: Syft (Anchore, Open Source) analysiert Container-Images, Dateisysteme und Repositories und erzeugt SBOMs in SPDX- und CycloneDX-Format. Trivy (Aqua Security) kombiniert SBOM-Generierung mit Schwachstellenscanning und unterstützt Container, Dateisysteme und Git-Repositories. cdxgen (CycloneDX-Generator) erzeugt CycloneDX-SBOMs für über 30 Programmiersprachen und Paketmanager. Die Integration erfolgt typischerweise als Build-Step in der CI/CD-Pipeline: Nach jedem Build wird automatisch ein SBOM generiert, versioniert und archiviert.
• Sigstore und cosign — Container-Image-Signierung: Sigstore ist ein Open-Source-Projekt unter der Linux Foundation, das die Signierung und Verifizierung von Software-Artefakten drastisch vereinfacht. Das Werkzeug cosign ermöglicht die keyless Signierung von Container-Images über OIDC-basierte Identitäten (z. B. GitHub Actions, Google, Microsoft). Die Signaturen werden in einem transparenten, öffentlichen Protokoll (Rekor) gespeichert, das Manipulationen erkennt. In der Praxis: cosign sign --yes my-registry.io/my-image:v1.0 signiert ein Container-Image, cosign verify prüft die Signatur vor dem Deployment.
• in-toto Framework — Supply-Chain-Integrität: in-toto ist ein CNCF-Projekt, das die Integrität der gesamten Software-Lieferkette verifiziert — nicht nur des Endprodukts. in-toto definiert ein Supply-Chain-Layout, das festlegt, welche Schritte (Build, Test, Review, Signierung) von welchen autorisierten Akteuren ausgeführt werden müssen. Jeder Schritt erzeugt ein signiertes Attestation, das beweist, dass der Schritt korrekt und von der richtigen Person/System ausgeführt wurde. Beim Deployment verifiziert in-toto, dass alle vorgeschriebenen Schritte eingehalten wurden — ein fehlendes Code-Review oder ein nicht autorisierter Build-Schritt wird erkannt und blockiert.
• Kontinuierliches Monitoring und SBOM-Lifecycle: Ein SBOM ist kein einmaliges Dokument, sondern muss kontinuierlich aktualisiert und überwacht werden. Tools wie Dependency-Track (OWASP) importieren SBOMs und gleichen sie automatisch mit der National Vulnerability Database (NVD), OSV.dev und weiteren Schwachstellendatenbanken ab. Bei neuen CVEs werden betroffene Komponenten und Produkte automatisch identifiziert und Alerts generiert. Die Integration in bestehende SIEM- und Ticketsysteme ermöglicht eine nahtlose Einbindung in den Incident-Response-Prozess.
• SLSA-Framework (Supply-chain Levels for Software Artifacts): SLSA (ausgesprochen „Salsa“) ist ein Framework von Google und der OpenSSF, das vier Reifegrade für Supply-Chain-Sicherheit definiert: Level 1: Dokumentation des Build-Prozesses (Build-Provenance). Level 2: Provenance wird von einem gehosteten Build-Service generiert (z. B. GitHub Actions). Level 3: Build-Umgebung ist gehärtet und isoliert, Provenance ist nicht fälschbar. Level 4: Hermetic Build mit vollständig reproduzierbaren Ergebnissen und Zwei-Personen-Review. SLSA Level 3 ist für die meisten Unternehmen ein realistisches und sinnvolles Ziel.
• Empfohlene Toolchain für den Einstieg: 1) Syft für SBOM-Generierung in der CI/CD-Pipeline (generiert bei jedem Build ein SBOM in CycloneDX-Format). 2) Grype (Anchore) für Schwachstellenscanning basierend auf dem SBOM. 3) Dependency-Track (OWASP) als zentrale Plattform für SBOM-Management und kontinuierliches Monitoring. 4) cosign (Sigstore) für Container-Image-Signierung. 5) GitHub Actions / GitLab CI mit SLSA-Level-3-konformen Build-Provenance-Generatoren. Diese Toolchain ist vollständig Open Source, produktionsreif und deckt die CRA-Anforderungen ab.

Praxis-Empfehlung: Starten Sie mit Syft + Dependency-Track als Minimalsetup. Ergänzen Sie cosign für Container-Signierung und implementieren Sie in-toto für kritische Produktionsumgebungen. Für CRA-betroffene Unternehmen sollte die SBOM-Integration in die CI/CD-Pipeline spätestens Mitte 2026 abgeschlossen sein, um bis zum CRA-Stichtag im Dezember 2027 ausreichend Erfahrung gesammelt zu haben.

Kultureller Wandel: Die größte Herausforderung bei der SBOM-Einführung ist oft nicht die Technik, sondern der kulturelle Wandel. Entwicklungsteams müssen verstehen, dass SBOMs kein bürokratischer Overhead sind, sondern ein wesentliches Werkzeug für die Sicherheit der eigenen Software. Product-Owner müssen Schwachstellenmanagement als festen Bestandteil des Produktlebenszyklus akzeptieren. Und die Geschäftsleitung muss bereit sein, in die notwendige Tooling-Infrastruktur zu investieren. Unternehmen, die SBOM frühzeitig als strategische Investition und nicht als Compliance-Pflichtübung begreifen, werden langfristig profitieren — durch schnellere Reaktionsfähigkeit bei Schwachstellen, bessere Lieferantenbeziehungen und höheres Kundenvertrauen.

Die Software-Lieferkette ist das neue Schlachtfeld der Cybersicherheit. Während Unternehmen jahrelang in Perimeter-Sicherheit, Firewalls und Endpoint-Protection investiert haben, blieb die Frage „Was steckt in unserer Software?“ oft unbeantwortet. SBOMs, Supply-Chain-Signierung und kontinuierliche Verifizierung ändern das grundlegend — und werden mit dem EU CRA zum regulatorischen Standard. Unternehmen, die jetzt handeln, gestalten die Zukunft der Software-Sicherheit aktiv mit.