Was dieses Tool leistet
- SBOM-Scanner: erstellt die Komponentenliste aus Lock-Dateien (npm, yarn, pnpm, pip, Poetry, Cargo, Go, Maven, Composer) sowie aus Yocto- oder Buildroot-Manifesten.
- SBOM-Leser: öffnet Ihre vorhandene CycloneDX- oder SPDX-JSON-Datei (etwa
bom.json,*.cdx.json,manifest.spdx.jsonoder*.spdx.json) und zeigt ihre Komponenten und bekannten Schwachstellen in einer übersichtlichen Tabelle. - SBOM-Prüfung: gleicht jede Komponente anhand von Name und Version mit der Schwachstellendatenbank OSV.dev ab und sortiert die Ergebnisse nach Schweregrad.
- Export: Laden Sie das Ergebnis als CycloneDX 1.7, SPDX 2.3 oder CSV herunter.
Ihre Dateien verlassen Ihren Computer nie. Die Dateien werden in Ihrem Browser gelesen. Bei aktiver Schwachstellenprüfung werden nur Paketname, Version und Ökosystem bei OSV.dev abgefragt; schalten Sie die Prüfung ab, scannen Sie vollständig lokal.
Was ist eine SBOM?
Eine SBOM (Software-Stückliste, engl. Software Bill of Materials) ist eine maschinenlesbare Liste der Komponenten in einer Software oder Firmware. Sie fasst die Open-Source-Bibliotheken, Betriebssystempakete und Komponenten von Drittanbietern eines Produkts samt ihren Versionen in einer Datei zusammen.
Ein typischer SBOM-Eintrag enthält:
- Name und Version der Komponente
- Lieferant oder Autor
- Eindeutige Kennungen: PURL und CPE
- Datei-Hashes und Lizenzangaben
- Abhängigkeitsbeziehungen zwischen Komponenten
Wird eine neue Schwachstelle (CVE) veröffentlicht, sieht ein Team mit aktueller SBOM innerhalb von Minuten, welche Produkte und Firmware-Versionen betroffen sind. Ohne SBOM wird dieselbe Frage zu einer tagelangen Untersuchung.
Eine ausführlichere Erklärung mit Firmware-Beispiel und den Einzelheiten zum CRA finden Sie unter Was ist eine SBOM?
SBOM im EU-Recht: Was der CRA verlangt
Die EU-Vorschrift, die eine SBOM zur gesetzlichen Pflicht macht, ist die Cyberresilienz-Verordnung, Verordnung (EU) 2024/2847. Sie gilt ab dem 11. Dezember 2027 für Produkte mit digitalen Elementen, die auf dem EU-Markt in Verkehr gebracht werden; einen Überblick gibt die Zusammenfassung der Cyberresilienz-Verordnung.
Nach Anhang I Teil II Nummer 1 des CRA müssen Hersteller Schwachstellen und Komponenten in ihren Produkten ermitteln und dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem gängigen und maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten der Produkte erfasst.
- Die SBOM ist Teil der technischen Dokumentation (Anhang VII). Sie muss nicht veröffentlicht werden.
- Sie wird einer Marktüberwachungsbehörde auf begründetes Verlangen vorgelegt.
- Ein bestimmtes Format ist nicht vorgeschrieben; CycloneDX und SPDX sind die beiden gängigen Formate.
- Sie sollte für jede Firmware-Version aktuell gehalten werden, und die Komponenten werden während des gesamten Unterstützungszeitraums auf neue Schwachstellen überwacht.
Artikel 13 ermächtigt die Kommission, Format und Elemente der SBOM durch Durchführungsrechtsakt festzulegen; ob ein solcher erlassen wurde, prüfen Sie auf EUR-Lex. Entscheidet sich der Hersteller, die SBOM den Nutzern zur Verfügung zu stellen, geben die Informationen für den Nutzer (Anhang II) an, wo sie abrufbar ist.
Eine SBOM allein bedeutet noch keine CRA-Konformität. Erforderlich sind außerdem die Behebung von Schwachstellen, sichere Updates, Meldungen nach Artikel 14 und die technische Dokumentation. Einen Überblick gibt der CRA-Leitfaden.
CycloneDX oder SPDX?
| Merkmal | CycloneDX | SPDX |
|---|---|---|
| Entwickelt von | OWASP | Linux Foundation |
| Norm | Ecma International ECMA-424 | ISO/IEC 5962 |
| Schwerpunkt | Sicherheit: Schwachstellen, VEX und Dienste | Lizenz-Compliance und Details auf Dateiebene |
| Ausgabe dieses Scanners | CycloneDX 1.7 JSON | SPDX 2.3 JSON |
Beide sind gängige Formate, die die Anforderung des CRA erfüllen. Entscheiden Sie danach, was Ihre Kunden und Ihre Toolchain erwarten; dieser Scanner erzeugt beide.
SBOMs für Embedded-Systeme: Yocto, Buildroot und Binärdateien
- Yocto: Das am Ende des Builds geschriebene Image-Manifest (
<image>.manifest) undlicense.manifestlisten die Pakete und Versionen im Image auf. Die Klassecreate-spdxerzeugt zusätzlich SPDX-Ausgaben. - Buildroot:
make legal-infoschreibtlegal-info/manifest.csvmit den Paketen und Versionen. - C/C++-Projekte ohne Paketmanager und vorkompilierte Binärdateien: Ohne Quellmanifest müssen die Komponenten aus dem Firmware-Image selbst identifiziert werden. Lassen sich einige nicht identifizieren, sollte die SBOM als unvollständig gekennzeichnet werden.
Der Scanner oben liest Yocto-Manifeste, die Buildroot-Datei manifest.csv, Lock-Dateien und vorhandene CycloneDX- oder SPDX-Dateien. Die Analyse des Firmware-Images selbst übernimmt unsere Plattform.
Nach der SBOM: Schwachstellenabgleich und VEX
Gleicht man jede SBOM-Komponente mit Datenbanken wie OSV und NVD ab, entsteht eine Rohliste von Schwachstellen. Sie ist oft lang; Signale zur Ausnutzung wie CISA KEV und EPSS helfen, die Reihenfolge festzulegen.
Eine Schwachstelle in einer Komponente ist im Produkt nicht unbedingt ausnutzbar: Der betroffene Code wird möglicherweise nicht mitkompiliert oder nicht verwendet. Der übliche Weg, diese Entscheidung Kunden und Behörden mitzuteilen, ist ein VEX-Dokument; CSAF und OpenVEX sind die beiden verbreitetsten Formate.
Fragen zur SBOM
Kann ich eine vorhandene SBOM-Datei öffnen und prüfen?
Ja. Legen Sie Ihre CycloneDX- oder SPDX-JSON-Datei ab; das Tool listet die Komponenten auf und prüft jede auf bekannte Schwachstellen in OSV.dev. Es liest CycloneDX- und SPDX-2.x-JSON-Dateien unabhängig vom Dateinamen; CycloneDX-XML (bom.xml) und SPDX-Tag-Value-Dateien werden noch nicht unterstützt.
Wie sehe ich mir eine CycloneDX-JSON-Datei an?
Legen Sie die Datei (etwa bom.json oder sbom.cdx.json) im Bereich oben auf dieser Seite ab. Der Viewer listet alle Komponenten, auch verschachtelte, mit Version, Ökosystem und Herkunftsdatei auf; Sie können die Liste durchsuchen und nur verwundbare Komponenten anzeigen. Unterstützt wird CycloneDX 1.x als JSON; CycloneDX-XML noch nicht.
Was zeigt der Viewer, und kann ich das Ergebnis herunterladen?
Für jede Komponente Name, Version, Ökosystem und Herkunftsdatei sowie, bei eingeschalteter Schwachstellenprüfung, die bekannten Schwachstellen in OSV.dev mit Schweregrad und der Version, die sie behebt. Das Ergebnis lässt sich als CycloneDX 1.7 JSON (mit den gefundenen Schwachstellen), SPDX 2.3 JSON oder CSV herunterladen.
Wie öffne ich eine manifest.spdx.json-Datei?
Legen Sie sie im Bereich oben auf dieser Seite ab oder wählen Sie sie über „vom Computer auswählen“ aus. Das Tool listet die Pakete in der SPDX-2.x-JSON-Datei auf und prüft sie bei aktiver Schwachstellenprüfung auf OSV.dev. Die Datei wird in Ihrem Browser gelesen und verlässt Ihren Computer nie.
Muss ich mich registrieren oder bezahlen?
Nein. Der SBOM-Scanner ist kostenlos und erfordert keine Registrierung.
Muss ich meine SBOM für Kunden veröffentlichen?
Nein. Nach dem CRA ist die SBOM Teil der technischen Dokumentation und wird einer Marktüberwachungsbehörde auf Verlangen vorgelegt. Ob Sie sie mit Kunden teilen, entscheiden Sie selbst.
Schreibt das EU-Recht eine SBOM vor?
Ja, für Produkte mit digitalen Elementen nach der Cyberresilienz-Verordnung (Verordnung (EU) 2024/2847). Anhang I Teil II Nummer 1 verlangt eine maschinenlesbare SBOM, die zumindest die obersten Abhängigkeiten erfasst und in der technischen Dokumentation geführt wird. Die Pflicht gilt ab dem 11. Dezember 2027.
Welches SBOM-Format verlangt der CRA?
Keines im Besonderen; es muss gängig und maschinenlesbar sein. CycloneDX und SPDX erfüllen beide diese Anforderung.
Wie oft sollte die SBOM aktualisiert werden?
Bei jedem Firmware- oder Software-Release. Die Komponenten sollten während des gesamten Unterstützungszeitraums auf neue Schwachstellen überwacht werden.
Kann dieser Scanner ein Firmware-Image lesen?
Nein. Der Web-Scanner liest Lock-Dateien, Yocto- und Buildroot-Manifeste sowie vorhandene SBOM-Dateien. Die Analyse von Firmware-Images erfolgt in unserer Plattform im Rahmen des Pilotprogramms für Unternehmen.
Lade ich meine Dateien auf Ihren Server hoch, um eine SBOM zu erhalten?
Nein. Die Dateien werden in Ihrem Browser gelesen. Bei aktiver Schwachstellenprüfung werden nur Paketname, Version und Ökosystem bei OSV.dev abgefragt.