Kostenloser SBOM-Generator für CycloneDX und SPDX

Mit dem kostenlosen SBOM-Generator von crality entsteht aus einer oder mehreren Dateien zur Abhängigkeitsverwaltung eine Software-Stückliste (SBOM) im Format CycloneDX oder SPDX, direkt zum Download, ohne Konto und ohne E-Mail-Adresse.

Der Cyber Resilience Act (CRA) verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, unter anderem mit einer solchen Stückliste. Dieser Beitrag zeigt, was der Generator kann, wie sich sein Ergebnis zu den Anforderungen der Verordnung verhält, wo die eigentliche Arbeit beginnt und was das ebenfalls kostenlose crality-Konto darüber hinaus bietet.

Was der CRA verlangt

Nach Anhang I Teil II Nummer 1 müssen Hersteller 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“. Artikel 3 Nummer 39 definiert die Software-Stückliste als formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts enthalten sind. Ein bestimmtes Format nennt die Verordnung nicht. Nach Artikel 13 Absatz 24 kann die Kommission Format und Elemente der Stückliste durch Durchführungsrechtsakte festlegen, unter Berücksichtigung europäischer oder internationaler Normen und bewährter Verfahren. Verbreitet sind vor allem CycloneDX und SPDX.

Die Stückliste gehört zur technischen Dokumentation. Anhang VII Nummer 2 Buchstabe b nennt sie bei den Angaben zu den Verfahren zur Behandlung von Schwachstellen. Einer Marktüberwachungsbehörde ist sie nach Nummer 8 desselben Anhangs gegebenenfalls auf begründetes Verlangen vorzulegen, sofern die Behörde sie braucht, um die Einhaltung der grundlegenden Cybersicherheitsanforderungen zu überprüfen. Veröffentlichen müssen Hersteller sie nicht, das stellt Erwägungsgrund 77 klar. Wer sie den Nutzern zur Verfügung stellt, gibt nach Anhang II Nummer 9 in den Nutzerinformationen an, wo sie abgerufen werden kann.

Diese Anforderungen gelten nach Artikel 71 Absatz 2 ab dem 11. Dezember 2027. Produkte, die schon vorher in Verkehr gebracht wurden, fallen nach Artikel 69 Absatz 2 nur darunter, wenn sie ab diesem Tag wesentlich geändert werden. Einen Grund, schon heute eine Stückliste zu haben, gibt es trotzdem. Seit dem 11. September 2026 gelten die Meldepflichten aus Artikel 14, und zwar nach Artikel 69 Absatz 3 auch für den Bestand. Wer eine aktiv ausgenutzte Schwachstelle unverzüglich, spätestens 24 Stunden nachdem er davon Kenntnis erlangt hat, mit einer Frühwarnung melden muss, braucht als Erstes eine Antwort darauf, ob die betroffene Komponente überhaupt im eigenen Produkt steckt. Diese Frage beantwortet eine Stückliste, soweit sie vollständig ist und zur ausgelieferten Version passt.

Was der Generator macht

Der Generator liest Dateien, die im Projekt ohnehin vorliegen, meist die Lockdatei des Paketmanagers oder ein Manifest wie pom.xml. Er kennt 24 Dateitypen aus 12 Ökosystemen, von package-lock.json und yarn.lock für Node.js über poetry.lock, Cargo.lock, composer.lock und go.mod bis zu pom.xml für Java, packages.lock.json für .NET und conan.lock für C und C++. Bei einem Repository mit mehreren Sprachen lassen sich alle Dateien auf einmal hochladen, der Generator führt sie zu einer Stückliste zusammen. Heraus kommt ein schemavalides Dokument in CycloneDX 1.6 oder SPDX 2.3, wahlweise als JSON oder XML, mit Namen, Versionen, standardisierten Paketkennungen (PURL) und, soweit verfügbar, Lizenzen der Abhängigkeiten.

Für Unternehmen, die ihre Abhängigkeitslisten nicht aus dem Haus geben wollen, zählt, was mit den Dateien geschieht. Sie werden im Arbeitsspeicher verarbeitet, danach wird das Ergebnis zurückgegeben und die Eingabe verworfen. Auf die Festplatte geschrieben wird nichts, protokolliert wird nur ein Zähler der Anfragen. Eine Lockdatei enthält in der Regel Paketnamen, Versionen, Prüfsummen und Bezugsadressen, aber keinen eigenen Quellcode. Manifeste wie pom.xml können zusätzlich Build-Konfiguration und die Adressen interner Paketquellen enthalten, ein Blick vor dem Hochladen lohnt sich. Der Generator liest den deklarierten Stand aus den Dateien. Er installiert nichts und führt keine Build-Skripte aus, das Ergebnis ist reproduzierbar.

Was die Stückliste leistet

Beim Format steht eine so erzeugte Stückliste gut da, denn CycloneDX und SPDX sind gängige maschinenlesbare Formate. Auch in der Tiefe reicht sie weit. Eine Lockdatei hält in der Regel alle aufgelösten Pakete fest, also weit mehr als die obersten Abhängigkeiten, die Anhang I mindestens verlangt. Bei einem Manifest wie pom.xml oder einer von Hand gepflegten requirements.txt steht im Ergebnis dagegen nur, was dort eingetragen ist. Wer die Wahl hat, nimmt die Lockdatei. Ob damit alle Abhängigkeiten des Produkts erfasst sind, ist eine andere Frage, dazu unten mehr.

Nützlich ist die Stückliste sofort. Sie zeigt, welche fremden Pakete das Projekt einbindet und, soweit bekannt, unter welchen Lizenzen. Sie lässt sich mit Schwachstellendatenbanken für Open-Source-Pakete abgleichen, weil die Paketkennungen Ökosystem, Name und, wo die Datei sie festlegt, Version jedes Pakets einheitlich angeben. Sie taugt als erste Antwort an einen Kunden, der eine Stückliste sehen will, wenn man dazusagt, was sie abbildet. Und sie ist ein Ausgangspunkt für die Sorgfaltspflicht bei Komponenten Dritter, die Artikel 13 Absatz 5 den Herstellern auferlegt.

Wo die Stückliste aufhört

Eine Stückliste aus Dateien zur Abhängigkeitsverwaltung beschreibt, was ein Projekt deklariert, bei einer Lockdatei samt der aufgelösten Versionen. Die Verordnung fragt nach dem Produkt, und zwischen beidem liegt einiges.

• Das ausgelieferte Artefakt. Was am Ende im Produkt steckt, hängt vom Build ab, von plattformabhängigen Paketen, von einkompilierten Bibliotheken und bei Container-Images vom Basisimage mit seinen Betriebssystempaketen. Für die technische Dokumentation empfiehlt sich deshalb eine Stückliste, die im Build aus dem fertigen Artefakt entsteht.
• Code außerhalb des Paketmanagers. Kopierte Quelltexte, eingebundene Binärbibliotheken und Firmware tauchen in keiner Lockdatei auf.
• Das ganze Produkt. Ein Produkt besteht oft aus mehreren Komponenten, etwa Gerätesoftware, App und Backend. Nach Artikel 3 Nummer 1 gehören auch seine Datenfernverarbeitungslösungen dazu. Welche Stücklisten zu welchem Produkt gehören, hält ein Produktverzeichnis fest.
• Die nächste Version. Eine Stückliste ist eine Momentaufnahme. Mit neuen Releases ändern sich oft auch die Abhängigkeiten, und die technische Dokumentation ist nach Artikel 31 Absatz 2 gegebenenfalls, zumindest während des Unterstützungszeitraums, laufend zu aktualisieren.

Was danach kommt

Die Stückliste ist kein Selbstzweck. Anhang I Teil II nennt in Nummer 1 Schwachstellen und Komponenten in einem Atemzug und verlangt in Nummer 2, Schwachstellen im Hinblick auf die Risiken unverzüglich zu behandeln und zu beheben, unter anderem durch Sicherheitsaktualisierungen. In der Praxis heißt das, die Stücklisten der Produkte und Versionen während ihres Unterstützungszeitraums regelmäßig mit neu bekannt gewordenen Schwachstellen abzugleichen. Steckt eine davon im Produkt und wird sie aktiv ausgenutzt, greifen ab Kenntnis die Meldepflichten des Artikels 14.

Diese laufende Arbeit leistet der Generator ohne Anmeldung nicht, und er soll es auch nicht. Er erledigt den ersten Schritt, liefert eine Momentaufnahme und verwirft die Eingabe danach. Für die Pflege der Stücklisten und die Schwachstellenanalyse gibt es das kostenlose crality-Konto.

Was das kostenlose crality-Konto zusätzlich bietet

Im Konto gibt es einen eigenen SBOM-Generator, der deutlich mehr kann als die Fassung ohne Anmeldung. Die Anmeldung kostet nichts, und Produkte lassen sich in beliebiger Zahl anlegen.

• Anbindung von Repositories. Im Konto lässt sich der Generator mit Repositories auf GitHub und GitLab verbinden.
• Manuelle Einträge. Kopierte Quelltexte, eingebundene Binärbibliotheken oder Firmware stehen in keiner Lockdatei. Im Konto lassen sich solche Komponenten von Hand in die Stückliste eintragen.
• Stücklisten je Produkt und Version. Das Konto ordnet jede Stückliste einem Produkt und einer Version zu und hält so fest, welcher Stand zu welchem Release gehört.
• Schwachstellenanalyse. Anhand der Stückliste gleicht crality die Komponenten mit bekannten CVE-Einträgen ab und zeigt, wo eine Schwachstelle steckt und wie sie sich beheben lässt.
• Meldungen. Wird eine Schwachstelle im Produkt aktiv ausgenutzt, unterstützt crality bei der Meldung nach Artikel 14, von der Erfassung des Falls über die Fristen bis zu den Meldeinhalten.

Anders als beim Generator ohne Anmeldung bleiben die Stücklisten im Konto gespeichert, sodass sich die Schwachstellenanalyse später erneut durchführen lässt.