Was der Cyber Resilience Act zur SBOM verlangt
Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847 und seit dem 10. Dezember 2024 in Kraft (EUR-Lex, Verordnung (EU) 2024/2847). Seine Kernpflichten - sichere Entwicklung, Konformitätsbewertung, CE-Kennzeichnung - gelten erst ab dem 11. Dezember 2027 (EU-Kommission). Die SBOM gehört zu diesen Anforderungen an die sichere Entwicklung: Hersteller müssen die in einem Produkt mit digitalen Elementen enthaltenen Komponenten identifizieren und dokumentieren, unter anderem durch das Erstellen einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, das mindestens die obersten Abhängigkeiten (top-level dependencies) des Produkts abdeckt (Verordnung (EU) 2024/2847, Anhang I, Teil II). Die untersten Ebenen tief verschachtelter Unterabhängigkeiten sind rechtlich nicht zwingend, sie zu erfassen bleibt aber ein sinnvoller nächster Schritt.
Wichtig ist die Abgrenzung, was die SBOM nicht ist: Der CRA verlangt nicht, die Stückliste zu veröffentlichen. Sie ist Teil der technischen Dokumentation und wird den Marktüberwachungsbehörden auf Anfrage vorgelegt (EU-Kommission). Zugleich ist sie kein einmaliges Dokument, sondern laufend aktuell zu halten, solange ein Produkt unterstützt wird. Das Bundesamt für Sicherheit in der Informationstechnik ordnet ein, dass die CRA-Pflichten für alle Produkte mit digitalen Elementen auf dem EU-Markt greifen - einschließlich bereits in Verkehr gebrachter Bestandsprodukte (BSI). Für Website- und Web-App-Betreiber heißt das: Es geht nicht nur um Neuentwicklungen, sondern um den gesamten unterstützten Bestand.
Anders als eine öffentliche Feature-Liste wandert die Software-Stückliste in die technische Dokumentation und wird nur auf behördliche Anfrage vorgelegt. Ihr Wert liegt in der Nachvollziehbarkeit: Sobald eine eingesetzte Bibliothek in einem Verzeichnis aktiv ausgenutzter Schwachstellen auftaucht, zeigt eine aktuelle SBOM in Minuten, ob und wo das eigene Produkt betroffen ist - statt in Handarbeit ganze Codebasen zu durchsuchen.
Was in einer SBOM steht: Komponente, Version, purl, Hash und Lizenz
Eine SBOM ist mehr als eine Liste von Paketnamen. Die US-Behörde NTIA hat die Mindestelemente einer Software-Stückliste definiert, die international als Referenz dienen: je Komponente der Lieferant, der Komponentenname, die Version, eindeutige Kennungen wie Package URL (purl), CPE oder SWID, die Abhängigkeitsbeziehung sowie Angaben zum Autor der SBOM und ein Zeitstempel der Erstellung (NTIA, Minimum Elements for a Software Bill of Materials). Die verbreiteten Formate ergänzen darüber hinaus kryptografische Hashes wie SHA-256 zur Integritätsprüfung und die Lizenz je Komponente - Angaben, die für Sicherheits- und Rechtsprüfungen gleichermaßen zählen.
Der eindeutige, maschinenlesbare Name des Bausteins - etwa der npm-Paketname oder die PHP-Bibliothek. Er verankert jede Zeile der Stückliste.
Die exakte Versionsangabe. Ohne sie lässt sich nicht entscheiden, ob eine gemeldete Lücke die eingesetzte Fassung betrifft (NTIA).
Die universelle Kennung, die Werkzeuge über Ökosysteme hinweg verstehen - etwa pkg:npm/jquery@3.6.0. purl ist der bevorzugte Identifikator für den Abgleich mit Schwachstellen-Verzeichnissen (OWASP CycloneDX).
Der kryptografische Fingerabdruck der Komponente. Er belegt, dass die eingesetzte Datei mit der dokumentierten übereinstimmt und nicht unbemerkt ausgetauscht wurde.
Die Lizenz je Komponente - für die Rechtsprüfung und für die Frage, unter welchen Bedingungen ein Baustein weiterverwendet werden darf.
Welche Komponente welche andere einbindet. Der CRA verlangt mindestens die oberste Ebene; die Beziehungen machen später Auswirkungen nachvollziehbar (Verordnung (EU) 2024/2847).
Der Package URL - kurz purl - ist dabei das Bindeglied zwischen Stückliste und Sicherheitswelt. Eine purl wie pkg:npm/react-dom@18.3.1 benennt Ökosystem, Paket und Version in einer einzigen, standardisierten Zeichenkette. Genau diese Kennung erlaubt es, eine SBOM automatisiert gegen öffentliche Schwachstellen-Verzeichnisse abzugleichen: Taucht eine purl in einem solchen Verzeichnis auf, ist die betroffene Komponente sofort in der eigenen Stückliste gefunden. purl gilt in beiden verbreiteten Formaten als der präzisere Identifikator für Software-Pakete (OWASP CycloneDX).
CycloneDX oder SPDX: die beiden verbreiteten SBOM-Formate
Der CRA schreibt kein einzelnes Format vor, sondern verlangt ein gängiges, maschinenlesbares Format (Verordnung (EU) 2024/2847). In der Praxis dominieren zwei offene Standards: CycloneDX, entwickelt von der OWASP-Community mit starkem Fokus auf Sicherheits-Anwendungsfälle, und SPDX, das als ISO/IEC 5962:2021 international standardisiert ist und historisch stärker bei der Lizenz-Compliance liegt. Beide sind maschinenlesbar, beide unterstützen purl - die Wahl hängt vor allem von der eigenen Werkzeugkette ab.
| Merkmal | CycloneDX | SPDX |
|---|---|---|
| Herkunft | OWASP-Community | Linux Foundation (SPDX-Projekt) |
| Standardisierung | Ecma International, ECMA-424 | ISO/IEC 5962:2021 |
| Aktuelle Version | 1.7 (Oktober 2025) | 3.0 (April 2024) |
| Datenformate | JSON, XML, Protocol Buffers | Tag-Value, JSON, RDF, YAML |
| Traditionelle Stärke | Security, VEX, Supply-Chain | Lizenz-Compliance, Provenienz |
| Kennungen | purl, CPE | purl, CPE |
SPDX wurde im September 2021 als ISO/IEC 5962:2021 veröffentlicht und damit zum international anerkannten Standard für Software-Stücklisten, Lizenz-Compliance und weitere Lieferketten-Artefakte (Linux Foundation). Die aktuelle Fassung SPDX 3.0 erschien im April 2024 und erweitert die Einsatzfelder deutlich (Linux Foundation). CycloneDX ist als ECMA-424 ein Ecma-International-Standard; die Version 1.7 wurde im Oktober 2025 veröffentlicht und ergänzte unter anderem erweiterte Transparenz für kryptografische Bausteine (OWASP CycloneDX). Für die CRA-Konformität ist entscheidend: Beide erfüllen die Formatanforderung aus Anhang I - Sie müssen sich also nicht zwischen Standard und Pflichterfüllung entscheiden, sondern nur das Format wählen, das zu Ihren Werkzeugen passt.
Eine SBOM ist im Kern eine Zutatenliste für Software: Sie sagt, woraus ein Produkt besteht - und ist damit die Grundlage, um Risiken über die gesamte Lieferkette hinweg überhaupt sichtbar zu machen.
— Sinngemäß nach NTIA, Minimum Elements for a Software Bill of Materials
Warum Websites und Web-Apps eine SBOM brauchen
Die Vorstellung, eine Website bestehe vor allem aus eigenem Code, ist überholt. 97 Prozent aller untersuchten Codebasen enthalten Open Source, und über 70 Prozent einer typischen Anwendung bestehen aus Open-Source-Bausteinen - im Schnitt 981 Open-Source-Komponenten pro Anwendung (Black Duck OSSRA 2025). Für Websites gilt das genauso: WordPress-Plugins, npm-Pakete im Build, PHP-Bibliotheken über Composer, eingebundene JavaScript-Bibliotheken. Jeder dieser Bausteine ist eine Komponente, die in die Stückliste gehört - und jede kann eine Schwachstelle mitbringen.
86 Prozent der kommerziellen Codebasen enthalten mindestens eine verwundbare Open-Source-Komponente (Black Duck OSSRA 2025). Zugleich hat sich die Zahl der Open-Source-Dateien in einer durchschnittlichen Anwendung verdreifacht - von über 5.300 im Jahr 2020 auf über 16.000 im Jahr 2024 (Black Duck OSSRA 2025). Ohne systematisches Inventar lässt sich diese Menge an Fremdcode kaum überblicken, und genau darin liegt der praktische Wert einer SBOM.
Die Lieferkette ist auch ein aktiver Angriffsvektor. Im ENISA Threat Landscape 2025 zählen klassische Software-Supply-Chain-Angriffe zu den zehn wichtigsten Bedrohungskategorien und machten rund 10,6 Prozent der analysierten Vorfälle aus (ENISA). Bereits die ENISA-Analyse von 2021 zeigte, dass Angreifer in etwa 66 Prozent der untersuchten Lieferketten-Vorfälle auf den Code der Zulieferer zielten (ENISA). Für Websites ist das konkrete Muster ein heimlich verändertes Dritt-Skript - das klassische Magecart-Szenario. Wer seine eingebundenen Skripte kennt und ihren Fingerabdruck überwacht, erkennt solche Manipulationen früher; wie das kontinuierlich gelingt, beschreibt der Beitrag zur Überwachung von Subresource Integrity. Die SBOM liefert dafür die Bestandsliste, gegen die geprüft wird.
Den Software-Bestand systematisch erfassen
Eine belastbare SBOM entsteht nicht aus dem Gedächtnis, sondern aus den Quellen, die den Software-Bestand ohnehin beschreiben. Für Websites und Web-Apps sind das vor allem die Manifest-Dateien der eingesetzten Ökosysteme und die eingebundenen Fremd-Ressourcen. Der folgende Ablauf führt von der ersten Erfassung zu einer maschinenlesbaren Stückliste, die die CRA-Formatanforderung erfüllt.
- Quellen bestimmen -
package.jsonund Lockfile für npm,composer.jsonfür PHP, die Plugin- und Theme-Liste des CMS sowie alle über ein CDN oder per Script-Tag eingebundenen Fremd-Ressourcen - Name und Version je Baustein festhalten - die exakte Version ist entscheidend, um später Betroffenheit von gemeldeten Lücken beurteilen zu können (NTIA)
- Package-URL (purl) und Hash ergänzen - die purl als Kennung für den automatisierten Abgleich, der SHA-256-Hash als Integritätsnachweis
- Lizenz je Komponente erfassen - für die Rechtsprüfung und die Weiterverwendbarkeit
- Abhängigkeitsebene festlegen - mindestens die obersten Abhängigkeiten, wie der CRA es fordert (Verordnung (EU) 2024/2847)
- In CycloneDX oder SPDX ablegen und in die technische Dokumentation aufnehmen - damit die Stückliste maschinenlesbar und auf Anfrage vorlegbar ist
Der CRA verlangt zunächst nur die top-level dependencies - also die Bausteine, die Sie direkt einbinden, nicht jede tief verschachtelte Unterabhängigkeit. Das senkt die Einstiegshürde erheblich: Beginnen Sie mit der obersten Ebene, halten Sie sie sauber aktuell und erweitern Sie die Tiefe später. Eine gepflegte Top-Level-SBOM ist einer unvollständigen, veralteten Vollinventur in der Praxis überlegen.
Eine SBOM aktuell halten - der eigentliche Aufwand
Der schwierige Teil ist nicht das Erstellen, sondern das Aktualhalten. Eine SBOM veraltet mit jedem Deploy, jedem npm update, jedem Plugin-Wechsel und jeder ausgetauschten Bibliothek. Der CRA verlangt ausdrücklich keine Momentaufnahme, sondern eine laufend gepflegte Stückliste über den unterstützten Lebenszyklus des Produkts (EU-Kommission). Besonders heikel sind Komponenten, die das Ende ihres Supports (End-of-Life) erreicht haben: Sie bekommen keine Sicherheitsaktualisierungen mehr, tauchen aber weiter im Produkt auf - und werden so zur bevorzugten Angriffsfläche. Eine SBOM, die den Versionsstand nachhält, macht solche veralteten Bausteine überhaupt erst sichtbar.
Das Aktualhalten verbindet die SBOM direkt mit den Meldepflichten. Wird eine in der Stückliste geführte Komponente aktiv ausgenutzt, greifen die engen CRA-Meldefristen ab September 2026 - die 24-Stunden-Frühwarnung, die 72-Stunden-Vollmeldung und der Abschlussbericht, wie sie der Beitrag zur CRA-Schwachstellen-Meldepflicht ab September 2026 im Detail erklärt. Für viele Betreiber überlagert sich das mit der NIS2-Richtlinie, die eine sehr ähnliche 24-Stunden-Frühwarnung kennt; die praktischen Folgen fasst der Beitrag zu den NIS2-Meldepflichten für Website-Betreiber zusammen. In beiden Fällen ist die aktuelle SBOM die Grundlage, um Betroffenheit schnell zu beurteilen.
Eine gepflegte Stückliste zahlt sich auch bei technischen Umstellungen aus. Wer die kryptografischen Bausteine seiner Systeme inventarisiert, kann den Übergang auf quantensichere Verfahren planvoll steuern - ein Thema, das der Beitrag zu Post-Quantum-TLS mit ML-KEM im Browser überwachen aufgreift. Und für die E-Mail-Zustellung zeigt der Beitrag zu MTA-STS und TLS-RPT für verschlüsselte Mail, wie sich transportverschlüsselte Kanäle absichern lassen - auch solche Konfigurationen gehören zum Bild eines gepflegten, nachvollziehbaren Technik-Bestands.
Das XICTRAQ CRA-Komponenten-Cockpit
Genau an dieser Stelle setzt das CRA-Komponenten-Cockpit an. Es inventarisiert die auf einer Website eingesetzten Komponenten samt Versionsstand, erkennt heuristisch veraltete Stacks und mahnt nahende CRA-Fristen rechtzeitig an. Aus der abstrakten Pflicht, einen Software-Bestand nachzuweisen, wird so ein konkreter, wiederholbarer Arbeitsablauf - vom ersten Inventar bis zur laufenden Pflege.
Die eingesetzten Bausteine werden erfasst und mit Versionsstand geführt - die Datenbasis, aus der eine Stückliste in einem gängigen Format entsteht.
Eine Tech-Stack-Heuristik markiert Bausteine, die dem Support-Ende nahekommen oder es überschritten haben - genau die Kandidaten, die eine Aktualisierung brauchen.
Nahende CRA-Stichtage werden gestaffelt in Erinnerung gerufen, sodass die Vorbereitung nicht erst kurz vor der Vollanwendung am 11. Dezember 2027 beginnt (EU-Kommission).
Sicherheitsrelevante Abweichungen laufen in denselben Benachrichtigungs-Workflow wie das übrige Monitoring - per E-Mail, Slack, Discord oder Telegram, mit Eskalation.
Das Cockpit steht nicht für sich, sondern ergänzt die übrige Angriffsflächen-Überwachung. Gemeinsam mit dem Security-Scan für Header und TLS, der Skript-Integritätsprüfung und der Zertifikatsbeobachtung entsteht ein Bild des tatsächlich ausgelieferten Zustands - nicht nur der Absicht. Wer wissen möchte, welche Bausteine sein digitales Produkt heute enthält und wo die nächste Frist wartet, findet in der Preisübersicht die passende Ausbaustufe. Eine Software-Stückliste ist am Ende kein Papierdokument, sondern ein lebendes Inventar - und ein Werkzeug, das dieses Inventar pflegt, nimmt der CRA-Vorbereitung viel von ihrer Schwere.
Mit der Software-Stückliste jetzt beginnen
Die SBOM-Pflicht des Cyber Resilience Act ist kein fernes Randthema, sondern eine planbare Aufgabe mit klarem Nutzen über die reine Konformität hinaus. Die Vollanwendung am 11. Dezember 2027 ist fix (EU-Kommission), und der Weg dorthin führt über drei nüchterne Schritte: den Software-Bestand aus den vorhandenen Quellen erfassen, ihn in ein maschinenlesbares Format wie CycloneDX oder SPDX bringen und ihn dann - der eigentliche Aufwand - dauerhaft aktuell halten. Jeder dieser Schritte verbessert nebenbei die eigene Sicherheitslage, weil er sichtbar macht, woraus ein Produkt wirklich besteht.
Der gemeinsame Nenner ist Übersicht. Ein aktuelles Komponenten-Inventar verkürzt die Zeit, in der bei einer neu gemeldeten Lücke die Frage "Sind wir betroffen?" beantwortet ist - von Tagen der Handarbeit auf Minuten des Abgleichs. Wer heute anfängt, seinen Bestand zu inventarisieren, hat bis 2027 eine gepflegte Stückliste und einen eingespielten Prozess statt einer Last-Minute-Aktion. Eine Live-Demo zeigt, wie die Komponenten-Inventur im Alltag aussieht; und der Einstieg in ein systematisches Bestands-Monitoring gelingt über die kostenlose Registrierung.
Dieser Artikel basiert auf Daten und Dokumenten von: Verordnung (EU) 2024/2847 (Cyber Resilience Act, EUR-Lex - Inkrafttreten 10.12.2024, SBOM-Anforderung Anhang I Teil II, gängiges maschinenlesbares Format, top-level dependencies), Europäische Kommission (digital-strategy.ec.europa.eu - Vollanwendung 11.12.2027, SBOM als Teil der technischen Dokumentation, Aktualhaltung, Sanktionsrahmen), Bundesamt für Sicherheit in der Informationstechnik (BSI, Cyber Resilience Act - Geltung für alle Produkte mit digitalen Elementen inkl. Bestandsprodukte), NTIA (The Minimum Elements For a Software Bill of Materials - Lieferant, Name, Version, eindeutige Kennungen CPE/SWID/purl, Abhängigkeitsbeziehung, Autor und Zeitstempel), OWASP CycloneDX (Spezifikation, purl als bevorzugter Identifikator, Ecma-Standard ECMA-424, Version 1.7 Oktober 2025), Linux Foundation SPDX (ISO/IEC 5962:2021 seit September 2021, SPDX 3.0 April 2024), Black Duck Open Source Security and Risk Analysis Report 2025 (Open-Source-Anteil in Codebasen, verwundbare Komponenten, Datei-Wachstum), ENISA Threat Landscape 2025 und Threat Landscape for Supply Chain Attacks 2021 (Anteil und Charakteristik von Lieferketten-Angriffen). Die rechtlichen Ausführungen sind keine Rechtsberatung.