Cyber Resilience Act
Software-Stückliste (SBOM)
Legaldefinition Art. 3 Nr. 39 CRA
„eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“
Eine Software-Stückliste beantwortet eine scheinbar simple Frage: Was steckt eigentlich in diesem Produkt? Moderne Software besteht zu großen Teilen aus fremdem Code, aus Bibliotheken, Frameworks und Laufzeitumgebungen. Wer nicht weiß, welche Komponenten in welcher Version verbaut sind, kann auch nicht beurteilen, ob eine neu veröffentlichte Schwachstelle das eigene Produkt betrifft.
Genau deshalb ist die SBOM keine Dokumentationsübung, sondern die Datengrundlage, auf der alles Weitere aufsetzt: Schwachstellenanalyse, Risikobewertung und im Ernstfall die fristgerechte Meldung.
Was in einer Software-Stückliste steht
Der Cyber Resilience Act (CRA) schreibt keine Feldliste vor, in der Praxis haben sich aber feste Angaben etabliert:
- Name und Version jeder Komponente, wobei gerade die Version entscheidend ist, weil Schwachstellen fast immer versionsgebunden sind
- Herkunft, also Hersteller oder Projekt der Komponente
- Lizenz, die neben der Sicherheit auch die rechtliche Verwendbarkeit bestimmt
- Abhängigkeitsbeziehungen mit der Angabe, welche Komponente welche andere nach sich zieht
- eindeutige Kennungen, über die sich Komponenten automatisiert mit Schwachstellendatenbanken abgleichen lassen
Die Lieferkettenbeziehungen sind dabei ausdrücklich Teil der Legaldefinition. Eine bloße Liste ohne Struktur erfüllt den Begriff nicht.
Was der Cyber Resilience Act konkret verlangt
Die Pflicht steht in Anhang I Teil II Nummer 1. Hersteller müssen Schwachstellen und Komponenten ihrer Produkte ermitteln und dokumentieren, „u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“.
Drei Details lohnen den zweiten Blick:
- „maschinenlesbaren Format“ schließt PDF und Tabellenblätter aus. Die SBOM soll automatisiert verarbeitet werden, nicht gelesen.
- „gängigen“ nennt bewusst kein konkretes Format. Die Kommission kann Format und Elemente später per Durchführungsrechtsakt präzisieren.
- „zumindest die obersten Abhängigkeiten“ ist eine Mindestanforderung, keine Obergrenze.
Die SBOM muss nicht veröffentlicht werden. Sie gehört zur technischen Dokumentation, und die Marktüberwachungsbehörde kann sie nach Anhang VII Nummer 8 auf begründetes Verlangen anfordern, sofern das zur Prüfung der Anforderungen aus Anhang I erforderlich ist.
Formate: CycloneDX und SPDX
Im Verordnungstext taucht kein einziges Format namentlich auf. Durchgesetzt haben sich zwei:
- CycloneDX, aus dem Sicherheitsumfeld kommend und stark auf Schwachstellenbezug ausgelegt
- SPDX, mit Ursprung im Lizenz-Compliance-Umfeld und als ISO/IEC-Norm standardisiert
Beide gelten als gängig im Sinne der Verordnung. Die Wahl ist deshalb weniger eine Compliance- als eine Werkzeugfrage: Entscheidend ist, was die eingesetzte Toolchain und die Abnehmer verarbeiten können.
Oberste Abhängigkeiten sind nur der Anfang
Die Formulierung „zumindest die obersten Abhängigkeiten“ wird häufig als Erlaubnis gelesen, es dabei bewusst zu belassen. Praktisch trägt das nicht weit: Ein erheblicher Teil bekannter Schwachstellen steckt in transitiven Abhängigkeiten, also in Komponenten, die man nie selbst eingebunden hat, sondern die über eine andere Komponente hereinkommen.
Wer nur die oberste Ebene erfasst, erfüllt den Buchstaben der Anforderung, sieht aber einen großen Teil des eigenen Risikos nicht. Die meisten Werkzeuge erzeugen den vollständigen Baum ohnehin; ihn künstlich zu beschneiden spart nichts.
Häufige Missverständnisse
„Eine SBOM reicht pro Produkt.“ Eine SBOM beschreibt genau einen Stand. Mit jeder Version, die andere Komponenten enthält, wird sie neu erzeugt. Andernfalls dokumentiert sie ein Produkt, das so nicht mehr ausgeliefert wird.
„Die SBOM ist die Schwachstellenanalyse.“ Sie ist deren Voraussetzung. Erst der Abgleich mit Schwachstellendatenbanken macht aus dem Verzeichnis eine Aussage über Risiken.
„Wir haben keine Open-Source-Komponenten, also brauchen wir keine.“ Die Pflicht knüpft an Komponenten an, nicht an deren Lizenz. Auch zugekaufte und eigene Bausteine gehören hinein.
Fragen aus der Praxis
-
Der CRA verpflichtet nicht dazu. Die Software-Stückliste gehört zur technischen Dokumentation und muss der Marktüberwachungsbehörde nach Anhang VII Nummer 8 auf begründetes Verlangen vorgelegt werden, sofern das erforderlich ist, damit diese die Einhaltung der grundlegenden Cybersicherheitsanforderungen prüfen kann. Gegenüber Kunden besteht dagegen keine gesetzliche Herausgabepflicht. Unabhängig davon fordern immer mehr Abnehmer sie vertraglich ein, insbesondere im öffentlichen Sektor und in regulierten Branchen. Wer sie ohnehin maschinenlesbar pflegt, kann solche Anfragen ohne Zusatzaufwand bedienen.
-
Die Legaldefinition bezieht sich ausdrücklich auf Komponenten in den Softwareelementen eines Produkts. Reine Hardwarebauteile gehören damit nicht in die Software-Stückliste. Die Pflicht aus Anhang I geht allerdings weiter: Zu ermitteln und zu dokumentieren sind Schwachstellen und Komponenten des Produkts insgesamt. Für Hardware braucht es also eine eigene Dokumentation, nur eben nicht in Form einer SBOM.
-
Als Ausgangspunkt ja, als fertige Software-Stückliste nein. Paketmanager kennen nur ihr eigenes Ökosystem und liefern selten Lieferkettenbeziehungen, eindeutige Kennungen oder Lizenzangaben in einem der gängigen Austauschformate mit. Ein Produkt besteht aber meist aus mehreren Ökosystemen plus einbezogenen Binärdateien. Übliche SBOM-Werkzeuge setzen genau dort an und führen die Teilergebnisse zu einem Dokument zusammen.
Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.