Die meisten Hersteller entdecken SBOM-Lücken erst bei ihrer ersten Compliance-Prüfung, nicht davor. Zu diesem Zeitpunkt ist die Durchsetzungsfrist näher gerückt und der Umfang der Nachbesserungsmaßnahmen größer. Die SBOM-Pflicht aus Anhang I des CRA ist einfach formuliert: maschinenlesbares Format, zumindest die obersten Abhängigkeiten der Produkte, abgelegt in der technischen Dokumentation nach Anhang VII. Was Hersteller in Schwierigkeiten bringt, ist die Formulierung „zumindest". Dieser Artikel beschreibt sechs Fehler, die die größte Lücke zwischen einer formalen SBOM und einer SBOM erzeugen, die eine Prüfung durch eine Marktüberwachungsbehörde überstehen würde.
Zusammenfassung
- Wer bei direkten Abhängigkeiten stoppt, lässt transitive Schwachstellen außerhalb der SBOM
- Eine einmalig erstellte SBOM wird innerhalb weniger Wochen nach Veröffentlichung neuer CVEs veraltet
- Fehlende Hash-Werte und PURL-Kennungen scheitern an den BSI-TR-03183-Qualitätsprüfungen
- Manuelle SBOM-Erstellung erfüllt die fortlaufende Aktualisierungspflicht des CRA nicht
- Interne und proprietäre Komponenten müssen neben Open-Source-Bibliotheken erscheinen
- Lieferanten-SBOMs sind Rohmaterial, kein fertiges Compliance-Artefakt
Fehler auf einen Blick
| # | Fehler | Warum er scheitert | Lösung |
|---|---|---|---|
| 1 | Stopp bei direkten Abhängigkeiten | Transitive CVEs für Scanner unsichtbar | Lock-Dateien plus Scan von Build-Artefakten |
| 2 | SBOM als einmaliges Dokument behandeln | Veraltet innerhalb von Wochen nach neuen CVEs | CI/CD-Generierung pro Build |
| 3 | Fehlende Identitätsfelder | Kein CVE-Abgleich, TR-03183 schlägt fehl | Genaue Version, SHA-256, PURL, Lieferant |
| 4 | Manuelle Generierung | Kann mit dem Veröffentlichungsrhythmus nicht mithalten | Automatisierung mit Syft, Trivy oder cdxgen |
| 5 | Interne oder proprietäre Komponenten übergehen | Anhang I macht diese Unterscheidung nicht | Interne IDs, eigene Organisation als Lieferant, SHA-256 |
| 6 | Lieferanten-SBOMs als fertiges Artefakt behandeln | Hersteller trägt die Anhang-I-Pflicht | In eine einzige Produkt-SBOM konsolidieren |
Fehler 1: Stopp bei direkten Abhängigkeiten
Anhang I, Teil II, Nummer 1 setzt die gesetzliche Mindestanforderung bei den obersten Abhängigkeiten. Viele Hersteller stoppen genau dort. Das Problem ist nicht das Erfüllen der gesetzlichen Mindestanforderung. Das Problem ist das Risiko, das die Mindestanforderung außerhalb Ihrer Sichtbarkeit lässt. Eine transitive Abhängigkeit (eine Bibliothek, von der Ihre direkte Abhängigkeit abhängt) ist genauso ausnutzbar wie eine direkte. Wenn ein CVE gegen ein transitives Paket veröffentlicht wird, das Ihre SBOM nicht aufführt, können Sie es nicht abgleichen, nicht melden und sind exponiert, ohne es zu wissen.
Ihr Produkt
+-- Bibliothek A (direkt) ← gesetzliche Mindestanforderung, Anhang-I-Schwelle
| +-- Bibliothek B (transitiv) ← außerhalb der SBOM, für Schwachstellen-Scanner unsichtbar
| \-- Bibliothek C (transitiv) ← außerhalb der SBOM, für Schwachstellen-Scanner unsichtbar
\-- Bibliothek D (direkt) ← gesetzliche Mindestanforderung, Anhang-I-Schwelle
Die Lösung liegt in Werkzeugen und Konfiguration. Nutzen Sie Lock-Dateien und scannen Sie Build-Artefakte statt nur den Quellcode. Trivy, Syft und cdxgen unterstützen alle die Erfassung transitiver Abhängigkeiten, wenn sie korrekt konfiguriert sind. BSI TR-03183 behandelt die vollständige transitive Abdeckung als Qualitätsindikator, der eine minimal-konforme SBOM von einer wirklich nützlichen unterscheidet. Siehe BSI TR-03183-Qualitätsstufen für die Feldanforderungen auf jeder Stufe.
Fehler 2: Die SBOM als einmaliges Dokument behandeln
Eine einmalig erstellte und nie aktualisierte SBOM erzeugt ein falsches Sicherheitsgefühl. Täglich werden neue CVEs gegen Komponenten veröffentlicht, die bereits in Ihrem Produkt enthalten sind. Eine SBOM, die zum Zeitpunkt des Builds korrekt war, wird innerhalb von Wochen veraltet. Die Anhang-I-Pflicht des CRA ist fortlaufend: Die SBOM muss den aktuellen Zustand des Produkts während des gesamten Supportzeitraums widerspiegeln.
Pflichtauslöser für Aktualisierungen nach dem CRA:
| Auslöser | Was sich ändert | SBOM-Aktualisierung erforderlich? |
|---|---|---|
| Neue Firmware- oder Softwareversion | Neues Build-Artefakt | Ja, vollständige Neugenerierung |
| Sicherheits-Patch eingespielt | Komponentenversion erhöht | Ja, betroffene Komponenten |
| Schwachstelle entdeckt und behoben | VEX oder Ausnutzbarkeits-Status | Ja, VEX-Felder |
| Komponente hinzugefügt, entfernt oder ersetzt | Abhängigkeitsgraph | Ja, vollständige Neugenerierung |
| Designänderung mit Sicherheitsauswirkung | Komponenten und Architektur | Ja, vollständige Neugenerierung |
Die Lösung ist CI/CD-Integration. Jeder Build sollte ein aktuelles SBOM-Artefakt erzeugen, das zusammen mit dem Release gespeichert wird. Ein manueller Export kann nicht mit der Aktualisierungsfrequenz Schritt halten, die der CRA verlangt. Siehe CRA-SBOM-Anforderungen für die vollständige Liste der Auslöser und die 10-jährige Aufbewahrungsfrist.
Ab dem 11. September 2026 müssen Sie aktiv ausgenutzte Schwachstellen binnen 24 Stunden an ENISA melden. Eine veraltete SBOM bedeutet, dass Sie nicht feststellen können, ob Ihr Produkt betroffen ist, bevor die Frist zu laufen beginnt. Sie benötigen aktuelle Komponentendaten vor dem Vorfall, nicht danach.
Fehler 3: Fehlende Identitätsfelder
Eine SBOM ohne genaue Versions-, Hash- und Kennungsfelder ist für den Schwachstellen-Abgleich nahezu wertlos. Diese Felder verbinden einen Komponenteneintrag mit einem CVE-Datensatz in der National Vulnerability Database (NVD), OSV oder CISA KEV. Ohne sie können Schwachstellen-Scanner Ihre Komponenten nicht abgleichen, und die BSI-TR-03183-Qualitätsprüfungen schlagen fehl.
Jede Komponente muss enthalten:
| Feld | Warum es wichtig ist | Quelle |
|---|---|---|
| Genaue Versionsnummer | Erforderlich für CVE/NVD/OSV-Abgleich (nicht „latest" oder Bereiche) | Anhang I; TR-03183 Pflichtfeld |
| SHA-256-Hash | Integritätsprüfung für binäre Komponenten | TR-03183 Pflichtfeld |
| PURL-Kennung | Verknüpft die Komponente mit ihrem Registry-Eintrag | TR-03183 Pflichtfeld |
| Lieferantenname | Auf jeder Qualitätsstufe erforderlich | Anhang I; TR-03183 |
Ein häufiger Versionsfehler ist die Verwendung von CycloneDX 1.3 oder älter. Die grundlegende VEX-Unterstützung wurde in CycloneDX 1.4 (Januar 2022) eingeführt, und die umfangreichere evidence-Struktur (identity, occurrences), die zur Nachvollziehbarkeit der CRA-Compliance dient, wurde in Version 1.5 (Juni 2023) hinzugefügt. Setzen Sie auf CycloneDX 1.6 oder höher für die CRA-Konformität. Prüfen Sie die Ausgabeversion Ihres Werkzeugs, bevor Sie von Compliance ausgehen.
Fehler 4: SBOMs manuell erstellen
Die manuelle SBOM-Erstellung ist fehleranfällig und skaliert nicht über Produktversionen hinweg. Eine von Hand erstellte SBOM übersieht Komponenten, die automatisierte Werkzeuge finden würden, enthält Tippfehler in Versionszeichenketten und kann nicht zuverlässig neu erstellt werden, wenn sich eine Komponente ändert. Noch wichtiger: Ein manueller Prozess kann die fortlaufende Aktualisierungspflicht des CRA nicht erfüllen. Jedes Release, jeder Patch und jede Komponentenänderung erfordern eine aktualisierte SBOM.
Automatisieren Sie die Generierung mit Syft, Trivy oder cdxgen. Manuelle Einträge sollten Komponenten vorbehalten sein, die automatisierte Werkzeuge nicht erkennen können, etwa kommerzielle Bibliotheken ohne Paketdatenbank-Einträge oder proprietäre Firmware-Blobs. Alles andere sollte aus dem Build kommen. Marktüberwachungsbehörden können die SBOM jederzeit anfordern; sie muss den aktuellen Produktzustand widerspiegeln.
Fehler 5: Interne und proprietäre Komponenten übergehen
Eine häufige Abkürzung ist es, nur Open-Source-Abhängigkeiten zu dokumentieren und interne Bibliotheken, proprietäre Module oder Firmware-Blobs wegzulassen. Anhang I macht diese Unterscheidung nicht. Wenn eine Komponente im Produkt enthalten ist, gehört sie in die SBOM.
Interne Komponenten haben oft keine PURL-Kennung oder keinen Registry-Eintrag. Der richtige Ansatz ist, eine interne Kennung zu vergeben, die eigene Organisation als Lieferant anzugeben und den SHA-256-Hash des binären Artefakts aufzunehmen. BSI TR-03183 deckt proprietäre Komponenten ausdrücklich auf allen Qualitätsstufen ab.
Bei Produkten mit eingebetteter Firmware von einem ODM oder Chip-Hersteller können Sie nicht prüfen, was Sie nicht selbst gebaut haben. Die Lösung ist vertraglich: Verlangen Sie SBOM-Lieferung von Ihren Firmware-Lieferanten. Nach dem CRA sind Sie für das gesamte Produkt verantwortlich, unabhängig davon, wer den Code geschrieben hat. Bei Hardware-Software-Produkten siehe HBOM nach dem CRA dazu, wann eine Hardware Bill of Materials neben der SBOM benötigt wird.
Fehler 6: Lieferanten-SBOMs als fertiges Artefakt behandeln
Lieferanten-SBOMs sind ein zulässiger Ausgangspunkt, und der CRA erwartet, dass Hersteller vorgelagerte Dokumentation nutzen. Sie sind jedoch kein Ersatz für eine integrierte Produkt-SBOM. Die Anhang-I-Pflicht liegt beim Hersteller des auf dem EU-Markt bereitgestellten Produkts: Sie müssen Lieferanten-SBOMs mit Ihren eigenen First-Party-Komponenten, Build-Abhängigkeiten und Verbindungscode in einer einzigen SBOM für das integrierte Produkt konsolidieren.
Fehlen in einer Lieferanten-SBOM Felder, die BSI TR-03183 vorschreibt (PURL, Hash, Lizenz), sind Sie dafür verantwortlich, diese Lücken zu schließen, bevor Ihr Produkt ausgeliefert wird. Behandeln Sie Lieferanten-SBOMs als Rohmaterial. Ihre Produkt-SBOM ist das fertige Compliance-Artefakt.
Häufig gestellte Fragen
Kann ich SBOMs meiner Lieferanten verwenden, um den CRA zu erfüllen?
Teilweise. Lieferanten-SBOMs sind ein zulässiger Ausgangspunkt für die von ihnen gelieferten Komponenten, und der CRA erwartet, dass Hersteller vorgelagerte Dokumentation nutzen, anstatt sie neu zu erstellen. Die Pflicht nach Anhang I liegt jedoch beim Hersteller des auf dem EU-Markt bereitgestellten Produkts: Sie müssen eine SBOM für das integrierte Produkt erstellen und pflegen, was bedeutet, Lieferanten-SBOMs mit Ihren eigenen First-Party-Komponenten, Ihren Build-Abhängigkeiten und etwaigem Verbindungscode zu konsolidieren. Fehlen in einer Lieferanten-SBOM Felder, die BSI TR-03183 vorschreibt (PURL, Hash, Lizenz), sind Sie dafür verantwortlich, diese Lücken zu schließen, bevor Ihr Produkt ausgeliefert wird. Behandeln Sie Lieferanten-SBOMs als Rohmaterial, nicht als fertiges Compliance-Artefakt.
Was ist die gesetzliche Mindestanforderung für die SBOM-Abhängigkeitsabdeckung nach dem CRA?
Anhang I, Teil II, Nummer 1 setzt die Untergrenze bei den obersten Abhängigkeiten. Der offizielle Wortlaut lautet: „Schwachstellen und Komponenten der Produkte mit digitalen Elementen 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". Damit sind direkte Abhängigkeiten die gesetzliche Mindestanforderung. Transitive Abhängigkeiten sind gesetzlich nicht vorgeschrieben, werden aber als Best Practice dringend empfohlen: Sie sind es, was Schwachstellen-Scanner tatsächlich benötigen, um CVEs genau abzugleichen, und BSI TR-03183 zählt die transitive Abdeckung als Qualitätsindikator.
Muss eine SBOM mit jedem Patch-Release aktualisiert werden?
Ja. Jedes Sicherheits-Patch-Release ist ein Pflichtauslöser für eine SBOM-Aktualisierung nach dem CRA. Die technische Dokumentation, die die SBOM einschließt, muss während des gesamten Produktlebenszyklus aktuell bleiben. Wenn Sie eine verwundbare Komponente patchen, muss Ihre SBOM die neue Version widerspiegeln. Automatisieren Sie die SBOM-Generierung im CI/CD-Prozess, damit Patch-Releases automatisch ein aktualisiertes SBOM-Artefakt erzeugen, ohne einen manuellen Schritt, der unter Termindruck übersehen werden kann.