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“
Verordnung (EU) 2024/2847, Art. 3 Nr. 39 CRA

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

Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.