Vergleichen
CRA-Compliance: SBOM-Anforderungen und Tools
Der Cyber Resilience Act macht eine Software-Stückliste (SBOM) für Produkte mit digitalen Elementen zur Pflicht. Hier lesen Sie, was die Verordnung von ihr verlangt, was die Richtlinie des deutschen BSI ergänzt und wie CRA-Compliance-Tools im Vergleich abschneiden.
Aktualisiert am
Jeder Vergleich zeigt, was das andere Produkt gut macht, wo CRACI sich unterscheidet und wann Sie beide einsetzen würden. Alle Kategorien finden Sie unter alle Vergleiche.
Was der CRA von einer SBOM verlangt
Der Cyber Resilience Act, Verordnung (EU) 2024/2847, verankert die SBOM in seinen Anforderungen an die Behandlung von Schwachstellen. Er verlangt weniger, als viele annehmen: ein maschinenlesbares Verzeichnis mindestens der obersten Abhängigkeiten, aufbewahrt in der technischen Dokumentation und einer Behörde auf Anfrage vorgelegt. Hier steht, was die Verordnung sagt, Frage für Frage.
| Funktion | Was der CRA sagt | Fundstelle |
|---|---|---|
| Ist eine SBOM Pflicht? | Ja. Hersteller müssen die Komponenten in ihren Produkten ermitteln und dokumentieren, „unter anderem durch Erstellung einer Software-Stückliste“ | Anhang I Teil II Nummer 1 |
| Was ist eine SBOM? | „Ein formelles Verzeichnis mit Einzelheiten und Lieferkettenbeziehungen von Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“ | Artikel 3 Nummer 39 |
| Welches Format? | „In einem gängigen und maschinenlesbaren Format“. Die Kommission kann Format und Elemente durch Durchführungsrechtsakte festlegen | Anhang I Teil II Nummer 1; Artikel 13 Absatz 24 |
| Wie tief? | „Zumindest die obersten Abhängigkeiten der Produkte“ | Anhang I Teil II Nummer 1 |
| Wohin gehört sie? | In die technische Dokumentation, als Teil der Informationen zur Behandlung von Schwachstellen | Anhang VII Nummer 2 Buchstabe b |
| Muss sie öffentlich sein? | Nein. „Die Hersteller sollten nicht verpflichtet sein, die SBOM öffentlich zugänglich zu machen.“ Wenn Sie sie mit Nutzern teilen, geben die Informationen für Nutzer an, wo sie zu finden ist | Erwägungsgrund 77; Anhang II Nummer 9 |
| Wer kann sie anfordern? | Eine Marktüberwachungsbehörde auf begründetes Ersuchen, um die Konformität zu prüfen. Behörden können SBOMs auch für eine EU-weite Bewertung von Abhängigkeiten anfordern | Anhang VII Nummer 8; Artikel 13 Absatz 25 |
| Wie lange aufbewahren? | Die technische Dokumentation wird mindestens 10 Jahre nach dem Inverkehrbringen des Produkts aufbewahrt oder für den Unterstützungszeitraum, je nachdem, welcher Zeitraum länger ist | Artikel 13 Absatz 13 |
Die Verordnung gilt vollständig ab dem 11. Dezember 2027, ihre Meldepflichten gelten ab dem 11. September 2026. Lesen Sie zum Rest der Verordnung, was der CRA verlangt.
Über das Minimum hinaus: BSI TR-03183-2
Bis die Kommission das Format durch einen Durchführungsrechtsakt festlegt, stammen die ausführlichsten öffentlichen Vorgaben vom deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI). Seine Technische Richtlinie TR-03183-2 in der Version 2.1.0 vom August 2025 ist eine Empfehlung, nicht Teil der Verordnung, zeigt aber, wohin sich die Erwartungen entwickeln:
- Format: JSON oder XML, gültig gegen CycloneDX 1.6 oder höher oder SPDX 3.0.1 oder höher.
- Tiefe: rekursive Auflösung der Abhängigkeiten für jede Komponente im Lieferumfang, bis einschließlich der ersten Komponente außerhalb davon.
- Maßgebliche Quelle: Die SBOM muss „dieselben Informationen wie während des Build-Prozesses verfügbar“ enthalten oder gleichwertige Informationen, wo es keinen Build-Prozess gibt.
Die Richtlinie benennt auch die Arten von SBOMs. Eine Build SBOM „wird im Rahmen des Build-Prozesses erstellt“. Eine Analysed SBOM „wird nach dem Build-Prozess durch Analyse von Artefakten wie ausführbaren Dateien, Paketen, Containern und Images virtueller Maschinen erstellt“. Diese Unterscheidung ist der wesentliche Unterschied zwischen den Tools auf dieser Seite.
Oberste oder transitive Abhängigkeiten
Die obersten Abhängigkeiten sind die Untergrenze, nicht das Ziel. Eine Schwachstelle in einem transitiven Paket steckt trotzdem in Ihrem Produkt, und der CRA verlangt von Herstellern, Schwachstellen in den ausgelieferten Komponenten zu behandeln und zu beheben. Eine SBOM, die bei der ersten Ebene aufhört, lässt diese Pakete aus Ihrer Schwachstellenbehandlung heraus. Die praktische Frage ist nicht, ob transitive Abhängigkeiten erfasst werden sollen, sondern wie Sie sicher sein können, dass die Aufzeichnung dem entspricht, was ausgeliefert wurde. Unter Transitive Abhängigkeiten lesen Sie, wie Sie sie auflisten und verwundbare beheben.
Build SBOM oder Analysed SBOM
Die meisten SBOM-Tools erzeugen nach dem Build eine Analysed SBOM oder verwalten SBOMs, die andere Tools erzeugen. CRACI zeichnet eine Build SBOM auf, während der Build läuft. SBOM-Generatoren und -Verwaltungstools im Vergleich finden Sie unter SBOM-Management und SBOM-Tools im Vergleich. Für Tools, die rund um den CRA gebaut sind, siehe CRA-Compliance-Tools im Vergleich.
Wo CRACI passt
CRACI zeichnet die SBOM auf, während Ihr GitHub-Actions-Build läuft. Ein paketbewusster Proxy auf dem Runner zeichnet jedes Paket auf, das der Job geladen hat, einschließlich Paketen aus CI-Caches, sodass die SBOM den Build beschreibt, der das Artefakt erzeugt hat, und nicht einen Scan, der irgendwo daneben lief. Die SBOM jedes Jobs trägt einen Vollständigkeitsstatus, und Exporte in CycloneDX und SPDX enthalten transitive Abhängigkeiten und die deklarierte Lizenz jeder Komponente.
Nach dem Release bewertet CRACI überwachte SBOMs laufend neu, sobald neue Schwachstellen auftauchen, und reicht die CRA-Meldungen (Frühwarnung, Meldung und Abschlussbericht) in Ihrem Namen ein. Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI bewahrt Build-Daten standardmäßig 180 Tage auf, mit individueller Aufbewahrungsdauer im Enterprise-Plan; exportieren Sie also, was für 10 Jahre in Ihre technische Dokumentation gehört. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Lieferkette, die Ihr CRA-Prozess braucht; die Konformitätsbewertung und die technische Dokumentation bleiben Sache des Herstellers. Alle CRA-Anforderungen als Schritt-für-Schritt-Roadmap finden Sie im CRA-Leitfaden. Erfahren Sie mehr über SBOM-Generierung während des Builds, oder buchen Sie eine Demo, um eine SBOM zu sehen, die aus einem Ihrer Builds aufgezeichnet wurde.
CRACI im Vergleich mit jedem Tool
- CRACI vs. Cybeats Ein SBOM-System of Record vs. aufgezeichnete und überwachte SBOMs.
- CRACI vs. FOSSA SBOM-Verwaltung vs. Build, SBOM und Überwachung in einem.
- CRACI vs. Anchore Images scannen vs. Builds aufzeichnen und überwachen.
- CRACI vs. Black Duck Code-, Snippet- und Binärscans vs. Build-Nachweise.
- CRACI vs. Sonatype Repository-Gatekeeping und SCA vs. Build-Nachweise.
- CRACI vs. ONEKEY Binäranalyse von Firmware vs. Nachweise aus dem Build.
- CRACI vs. Finite State Analyse von Binärdateien und Lieferanten-SBOMs vs. eine Build-Aufzeichnung.
- CRACI vs. Exein Laufzeitsicherheit auf dem Gerät vs. Nachweise aus dem Build.
Im direkten Vergleich
Mehrere Tools auf einer Seite, wenn Sie eine Kategorie wählen und nicht ein einzelnes Produkt.
Fragen zur CRA-SBOM, beantwortet
Verlangt der CRA transitive Abhängigkeiten in der SBOM?
Die Verordnung setzt die Untergrenze bei „zumindest die obersten Abhängigkeiten der Produkte“ (Anhang I Teil II Nummer 1). Transitive Abhängigkeiten werden nicht genannt, aber ein verwundbares transitives Paket steckt trotzdem in Ihrem Produkt, und der CRA verlangt, dass Sie Schwachstellen in den ausgelieferten Komponenten behandeln. Die deutsche BSI-Richtlinie TR-03183-2 geht weiter und verlangt eine rekursive Auflösung der Abhängigkeiten.
Muss die CRA-SBOM öffentlich sein?
Nein. Laut Erwägungsgrund 77 sollten Hersteller nicht verpflichtet sein, die SBOM zu veröffentlichen. Sie gehört in die technische Dokumentation, und eine Marktüberwachungsbehörde kann sie mit einem begründeten Ersuchen anfordern. Wenn Sie sie mit Nutzern teilen, müssen die Informationen, die dem Produkt beiliegen, angeben, wo sie zu finden ist (Anhang II Nummer 9).
Sollte eine CRA-SBOM CycloneDX oder SPDX sein?
Der CRA verlangt „ein gängiges und maschinenlesbares Format“ und nennt keines; die Kommission kann das Format durch einen Durchführungsrechtsakt festlegen (Artikel 13 Absatz 24). CycloneDX und SPDX sind die beiden gängigen Optionen. BSI TR-03183-2 v2.1.0 akzeptiert CycloneDX 1.6 oder höher und SPDX 3.0.1 oder höher, in JSON oder XML.
Wie lange muss ich die SBOM aufbewahren?
Die SBOM ist Teil der technischen Dokumentation, die Hersteller mindestens 10 Jahre nach dem Inverkehrbringen des Produkts für die Marktüberwachungsbehörden bereithalten, oder für den Unterstützungszeitraum, falls dieser länger ist (Artikel 13 Absatz 13).
Ab wann gelten die SBOM-Anforderungen des CRA?
Die Meldepflichten des CRA gelten ab dem 11. September 2026, und die Verordnung gilt vollständig, einschließlich der SBOM-Anforderung in Anhang I, ab dem 11. Dezember 2027.
Weitere Kategorien
Sehen Sie CRACI in Ihrer eigenen Pipeline
Buchen Sie eine Demo, und wir gehen gemeinsam Ihre Builds, Ihre SBOMs und Ihre Compliance-Nachweise durch.
Demo buchen