Ratgeber - Komponenten
Was ist eine SBOM und wie erstelle ich sie für den CRA?
Das Verzeichnis aller Komponenten, maschinenlesbar geführt
Kaum ein Produkt besteht nur aus eigenem Code. Die SBOM ist die Antwort auf die Frage, die bei jeder gemeldeten Schwachstelle zuerst kommt: Welche Versionen unseres Produkts enthalten die betroffene Komponente?
Die Kurzfassung
Eine SBOM ist das maschinenlesbare Inhaltsverzeichnis eines Softwareprodukts
SBOM steht für Software Bill of Materials, auf Deutsch Stückliste der Software. Sie listet alle Komponenten eines Produkts mit Name, Version, Lieferant und Lizenz, in einem maschinenlesbaren Format. Der CRA verlangt die SBOM nicht als eigenständige Datei an einer bestimmten Stelle, aber die Sorgfaltspflicht für integrierte Komponenten aus Artikel 13 und die Produktangaben der 72-Stunden-Meldung aus Artikel 14 setzen voraus, dass der Hersteller diese Liste führen kann.
Die Formate
CycloneDX und SPDX sind die beiden etablierten Formate
Was die Formate unterscheidet
| Format | Herkunft | Stärke | Geeignet für |
|---|---|---|---|
| CycloneDX | Open Worldwide Application Security Project | Auf Sicherheitsfragen zugeschnitten, kompakt | Schwachstellenmanagement und CRA-Meldung |
| SPDX | Linux Foundation | Lizenzinformationen im Detail | Lizenzprüfung und Compliance |
Für den CRA-Zweck, die Zuordnung von Schwachstellen zu Versionen, passt CycloneDX besser, weil das Format für genau diesen Fall gebaut wurde. Wer ohnehin eine SPDX-Liste für Lizenzen führt, muss nicht wechseln: Beide Formate lassen sich ineinander überführen. Der SBOM-Generator erstellt ein gültiges CycloneDX-1.6-Gerüst, das im Browser gefüllt wird.
Die Erstellung
Die SBOM entsteht aus dem Buildprozess oder aus der gepflegten Liste
Zwei Wege, je nach Größe des Produkts
Der erste Weg hängt die SBOM an den Buildprozess an: Werkzeuge lesen die Abhängigkeiten aus dem Paketmanager aus und schreiben die Datei bei jedem Build neu. Das Verfahren stimmt automatisch, verlangt aber eine Buildumgebung, die es erlaubt.
Der zweite Weg ist die gepflegte Liste: Ein kleines Produkt mit zehn Komponenten kann die SBOM von Hand führen, solange jede Änderung der Abhängigkeiten die Liste mitzieht. Der Nachteil ist die Disziplin, der Vorteil die Übersicht: Wer die Liste von Hand schreibt, kennt jede Komponente mit Namen.
Eine SBOM, die nicht zur ausgelieferten Version passt, ist schlimmer als keine: Sie beantwortet die Frage falsch, statt sie nicht zu beantworten.
Der Anwendungsfall
Der Nutzen zeigt sich erst im Meldefall
Was die SBOM im Ernstfall leistet
Wird eine Schwachstelle in einer Bibliothek bekannt, die in tausenden Produkten steckt, verwandelt sich die Frage nach den betroffenen Versionen in eine Frage nach Stunden. Die SBOM beantwortet sie in Minuten: Suchlauf über die Komponente, Ergebnis ist die Liste der eigenen Versionen. Die 72-Stunden-Frist der Meldung verlangt genau diese Angaben, und die betroffenen Nutzer zu unterrichten verlangt sie ebenfalls.
Wer bezahlt, ist der Hersteller, der die Liste führt und pflegt. Wer profitiert, sind die Nutzer, deren Info die Meldung schneller und vollständiger erreicht, und der Hersteller selbst, der die Frist hält.
Vertiefung