CRA-SBOM-Fehler: 7 konkrete Korrekturen für Hersteller
Ihr SBOM-Generator läuft, die Datei validiert, und die nächste Produktprüfung findet trotzdem Lücken. Die wiederkehrenden CRA-Bereitschaftsmängel sind selten obskure Rechtsfragen. Es sind flache Abhängigkeitsbäume, reine Quellinventare, veraltete Einträge und Komponenten, die Scanner keiner Schwachstelle zuordnen können. Der Cyber Resilience Act verlangt eine gängige, maschinenlesbare SBOM, die zumindest die obersten Abhängigkeiten abdeckt und mit der technischen Dokumentation aufbewahrt wird. Dieser Artikel beschreibt sieben Lücken zwischen einer SBOM, die formal existiert, und einer SBOM, die das Schwachstellenmanagement unterstützt. Das ist die SBOM, die eine Marktüberwachungsbehörde erwartet.
Zusammenfassung
- Eine aus Quell-Manifests erstellte SBOM kann übersehen, was tatsächlich im Artefakt ausgeliefert wird
- Komponenten ohne genaue Version, Hash und PURL lassen sich kaum CVEs zuordnen
- Direkte Abhängigkeiten sind die gesetzliche CRA-Untergrenze, für nützliches Schwachstellenmanagement reicht das nicht
- Eine einmalig erstellte SBOM veraltet mit neuen Schwachstellen und Produktversionen
- Interne, proprietäre, kommerzielle und Firmware-Komponenten gehören ebenfalls in den Geltungsbereich
- Lieferanten-SBOMs sind Eingaben zum Abgleichen, nicht Ihre fertige Produkt-SBOM
- Ein Produktrelease braucht einen maßgeblichen SBOM-Eintrag, keine verstreuten Fragmente
Fehler auf einen Blick
- Quellbaum, nicht ausgeliefertes Artefakt: aus dem gebauten Artefakt oder Image generieren, damit kompilierter Code, OS-Pakete und Firmware sichtbar sind.
- Lückenhafte Identitätsfelder: genaue Versionen, Hashes, PURLs wo verfügbar und Lieferantennamen verwenden, damit Scanner CVEs zuordnen können.
- Nur direkte Abhängigkeiten: Lock-Datei- und Artefakt-Scanning hinzufügen, damit indirekte und paketierte Abhängigkeiten in die SBOM eingehen.
- Einmalige Datei: die SBOM für jedes Release neu generieren und archivieren, dann den Schwachstellen-Abgleich aktuell halten.
- Übergangener Produktcode: interne, proprietäre, kommerzielle und Firmware-Komponenten brauchen trotzdem Kennungen und Nachweise.
- Lieferanten-Übernahme: Lieferanten-SBOMs sind Eingaben. Mit First-Party-Code und dem finalen Release-Artefakt abgleichen.
- SBOM-Zersplitterung: eine maßgebliche Produkt-SBOM pro Release führen, damit Version 1.4.2 einen verteidigbaren Eintrag hat.
Anwendungscode, OS-Pakete, Firmware-Blobs und generierte Dateien erfassen.
Genaue Versionen, Hashes, Lieferantennamen und PURLs verwenden, wo verfügbar.
Vorgelagerte SBOMs mit First-Party- und Integrationscode kombinieren.
Die Produkt-SBOM mit dem Release und der technischen Dokumentation archivieren.
Schwachstellen-Abgleich bei neuen Advisories und Exploit-Signalen wiederholen.
Was für SBOM-Nachweise zählt
- Verwenden Sie ein gängiges, maschinenlesbares Format.
- Decken Sie zumindest die obersten Abhängigkeiten ab, dann gehen Sie für nützliches Schwachstellenmanagement tiefer.
- Bewahren Sie die SBOM mit der technischen Dokumentation und den Release-Nachweisen auf.
- Gehen Sie nicht davon aus, dass der CRA ein bestimmtes Format, einen Hash-Typ oder eine öffentliche Veröffentlichung vorschreibt.
Diese gesetzliche Untergrenze ist nicht dasselbe wie eine operative Untergrenze für das Schwachstellenmanagement. Eine SBOM mit nur direkten Abhängigkeiten erfüllt möglicherweise die Mindestanforderung, ist aber zu flach, um betroffene Produkte schnell zu identifizieren. BSI TR-03183, ENISA-Leitlinien, CISA SBOM Guidance und aktuelle Werkzeugpraxis sind am besten als Qualitätsmaßstäbe zu lesen, die Herstellern helfen, die CRA-Pflicht operativ umzusetzen.
Fehler 1: Ihre SBOM beschreibt den Quellbaum, nicht das ausgelieferte Produkt
Quell-Manifests sind praktisch, aber sie sind nicht das Produkt. Ein Quell-Scan kann mehr Entwicklungsabhängigkeiten ausweisen, als tatsächlich ausgeliefert werden, und gleichzeitig übersehen, was erst nach Build, Paketierung, Container-Layering, statischem Linken oder Firmware-Integration entsteht. Für einen Hersteller muss die SBOM beantworten, was im Produktrelease enthalten war, nicht nur, was in einer Paketdatei deklariert wurde.
Der Unterschied ist am wichtigsten bei eingebetteten und containerisierten Produkten. Ein sprachbasierter Scan kann OS-Pakete in einem Container-Basis-Layer übersehen. Ein Yocto- oder Buildroot-Export kann Firmware von Siliziumanbietern, Bootloader, Kernel-Module oder Binär-Blobs verpassen, die außerhalb des Build-Systems eingeflossen sind. Wenn diese Komponenten im ausgelieferten Artefakt enthalten sind, gehören sie in die Release-Dokumentation, auch wenn ein automatisierter Paket-Scanner sie nicht ableiten kann.
Die Lösung: aus dem Release-Artefakt oder Image generieren und das Ergebnis mit Quell- und Lock-Datei-Output vergleichen. Bei Containern: das finale Image per Digest scannen. Bei Firmware: SBOM-Output des Build-Systems mit Binäranalyse und manuellen Einträgen für Komponenten kombinieren, die Tools nicht automatisch identifizieren können.
Fehler 2: Fehlende Hashes und PURLs machen Komponenten nicht abgleichbar
Eine SBOM ohne genaue Version, Hash, Lieferant und Paket-Kennungen ist für den Schwachstellen-Abgleich kaum nutzbar. Die Datei mag maschinenlesbar sein, aber ein Scanner braucht trotzdem eine stabile Komponentenidentität, um zu entscheiden, ob ein CVE, ein OSV-Advisory, ein GitHub Security Advisory oder ein CISA-KEV-Eintrag zutrifft.
Jede Komponente sollte ausreichend Identität tragen, um den automatisierten Abgleich zu überstehen:
Vermeiden Sie „latest", lose Versionsbereiche und mehrdeutige Fork-Namen.
KernidentitätsfeldVerknüpft den Eintrag mit dem konkreten Archiv, Image oder der Binärdatei.
SHA-256 oder stärker in der PraxisTrennt gleichnamige Komponenten und proprietären Code.
Nützlich für jede KomponenteZeigt, ob die SBOM aus Quellcode, Build, Artefakt, ausgeliefertem System oder Laufzeit stammt.
PrüfungsnachweisDas ist nicht nur Hygiene. NIST gab am 15. April 2026 bekannt, dass die NVD-Anreicherung jetzt für ausgewählte CVEs priorisiert wird, weil das Schwachstellenvolumen die vollständige Anreicherungskapazität übersteigt. Das macht rein CPE-basiertes Matching zu einem schwächeren Plan für das künftige Schwachstellenmanagement. Verwenden Sie PURL, wo verfügbar, bewahren Sie Hashes für ausgelieferte Artefakte auf und behandeln Sie einen Komponentennamen allein nicht als ausreichend.
Ein häufiger Format-Fehler ist die Verwendung von CycloneDX 1.3 oder früher. Grundlegende VEX-Unterstützung kam mit CycloneDX 1.4, die reichhaltigere evidence-Komponentenstruktur mit CycloneDX 1.5. Für die aktuelle CRA-Vorbereitung ist CycloneDX 1.6 oder später das Ziel, oder ein aktuelles SPDX-Profil, das Ihre Tools zuverlässig verarbeiten können. Prüfen Sie die Ausgabe Ihres Generators, bevor Sie davon ausgehen, dass das Format die Felder unterstützt, die Ihr Prozess benötigt.
Fehler 3: Bei direkten Abhängigkeiten stoppen
Direkte Abhängigkeiten sind die gesetzliche CRA-Untergrenze. Für nützliches Schwachstellenmanagement reichen sie nicht. Eine transitive Abhängigkeit ist eine Komponente, die von einer anderen Komponente eingebunden wird, und sie kann die relevante Schwachstelle tragen. Wenn ein CVE gegen ein transitives Paket erscheint, das Ihre SBOM nicht aufführt, kann das Produkt betroffen sein, während Ihre Matching-Pipeline still bleibt.
- Produktrelease
- Bibliothek A aufgeführt
- Bibliothek D aufgeführt
- Bibliothek B und Bibliothek C sind für den Scanner nicht sichtbar
- Produktrelease
- Bibliothek A aufgeführt
- Bibliothek B und Bibliothek C unter Bibliothek A verlinkt
- Bibliothek D aufgeführt
- Weniger blinde Flecken
- Geltungsbereich ist leichter zu erklären
- Betroffene Versionen sind klarer
- VEX-Entscheidungen haben bessere Nachweise
Eine peer-reviewed NDSS-2025-Studie, JBomAudit, fand, dass 7.907 von 25.882 Java-SBOMs mindestens eine direkte Abhängigkeit nicht offenlegten. Die praktische Lektion ist einfach: Wenn schon direkte Abhängigkeiten häufig fehlen, erfordert die transitive Abdeckung bewusste Prüfungen.
Um diese Lücke zu schließen: Lock-Dateien verwenden, wo das Ökosystem sie unterstützt, gebaute Artefakte sowie Quellcode scannen und Pakete prüfen, die Abhängigkeiten bündeln oder einbinden. Betrachten Sie transitive Abdeckung als Audit-Qualitätspraxis, nicht als beiläufige, nachrangig behandelte Einstellung, die in einer Scanner-Voreinstellung verborgen ist.
Fehler 4: Die SBOM als einmaliges Dokument behandeln
Eine einmalig erstellte und nie aktualisierte SBOM erzeugt ein falsches Sicherheitsgefühl. Neue CVEs werden gegen Komponenten veröffentlicht, die bereits im Produkt sind. Neue Firmware-Versionen, Patches und Lieferanten-Updates ändern das Produkt. Der CRA erwartet außerdem, dass die technische Dokumentation während des Supportzeitraums wo angemessen fortlaufend aktualisiert wird.
Häufige Aktualisierungsauslöser:
Das Software- oder Firmware-Artefakt verwenden, das Sie auf dem Markt bereitstellen.
Die Komponentenversion oder der behobene Status hat sich geändert.
Der Abhängigkeitsgraph hat sich geändert, weil eine Komponente hinzugefügt, entfernt oder ersetzt wurde.
Die Upstream-Komponentenidentität hat sich geändert, daher die Lieferantendatei nicht unverändert speichern.
OS-Pakete oder eingebettete Dateien haben sich in der Binärdatei, dem Firmware-Paket oder Container-Image geändert.
CI/CD ist die praktische Maßnahme. Jedes Release sollte ein aktuelles SBOM-Artefakt erzeugen, das zusammen mit dem Build gespeichert und mit der technischen Dokumentation verknüpft ist. Manuelle Einträge sollten Komponenten vorbehalten sein, die Tools nicht erkennen können, und auch diese Einträge müssen bei Produktänderungen überprüft werden.
Ab dem 11. September 2026 gilt die Meldepflicht nach Artikel 14 für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle. Bei einer aktiv ausgenutzten Schwachstelle ist der Ablauf: Frühwarnung binnen 24 Stunden, Schwachstellenmeldung binnen 72 Stunden und Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme. Eine veraltete SBOM macht die erste Triage-Entscheidung langsamer.
Fehler 5: Interne, proprietäre und Firmware-Komponenten auslassen
Eine verbreitete Abkürzung ist, nur Open-Source-Abhängigkeiten zu dokumentieren und interne Bibliotheken, kommerzielle Module, proprietäre Firmware oder Anbieter-Blobs wegzulassen. Das ist keine Produkt-SBOM. Wenn eine Komponente im Produkt ausgeliefert wird, gehört sie in den Geltungsbereich, auch wenn sie keinen öffentlichen Registry-Eintrag hat.
Interne Komponenten haben oft keine Ökosystem-PURL oder keinen öffentlichen Paketeintrag. Verwenden Sie eine interne Kennung, die eigene Organisation als Lieferant, die genaue Version oder Build-ID und den Hash des Binär-Artefakts. Bei kommerziellen Komponenten: Lieferantenname, Version, Lizenznachweis und Vertragsreferenzen in der technischen Dokumentation aufbewahren.
Bei Hardware-Software-Produkten wird das bei Firmware sichtbar. WLAN-Module, Modems, Secure Elements, Bootloader, Trusted-Execution-Environment-Binaries und Out-of-Tree-Kernel-Module können Schwachstellen tragen, bleiben aber für Sprachpaket-Scanner unsichtbar. Nutzen Sie Lieferanten-SBOMs, wo vorhanden, erstellen Sie manuelle Einträge, wo nicht, und setzen Sie eine Binäranalyse als Prüfung ein. Für den Hardware-Teil des Nachweis-Pakets siehe HBOM nach dem CRA.
Fehler 6: Lieferanten-SBOMs als fertiges Artefakt behandeln
Lieferanten-SBOMs sind zulässige Eingaben. Sie sind nicht Ihre fertige Produkt-SBOM. Der Hersteller stellt das integrierte Produkt auf dem EU-Markt bereit. Die Produkt-SBOM muss Lieferantenkomponenten, First-Party-Code, Build-Outputs, Firmware, Integrationscode und produktspezifische Abhängigkeitsbeziehungen kombinieren.
Das Scheiternsmuster ist leicht zu übersehen: Ein Lieferant gibt Ihnen eine CycloneDX-Datei, ein anderer SPDX, ein dritter eine PDF-Inventarliste, und der finale Produktordner enthält Links zu allen dreien. Das ist Lieferantennachweis, kein Produkteintrag. Ein Prüfer muss trotzdem wissen, welche Komponenten in Produktversion 1.4.2 enthalten waren.
Abgleichen statt kopieren. Lieferanten-SBOMs in die Produkt-SBOM einarbeiten, Identitätsfelder normalisieren, bekannte Unbekannte dokumentieren und die vorgelagerten SBOMs als Belegnachweise aufbewahren. Fehlt einer Lieferanten-SBOM PURL, Hash, Lizenz oder genaue Version, dokumentieren Sie die Lücke und schließen Sie, was möglich ist, vor dem Release. Eine URL zu einer vorgelagerten Datei ist nicht dasselbe wie eine integrierte Produkt-SBOM.
Fehler 7: Viele SBOMs, kein einziger Produkteintrag
SBOM-Zersplitterung ist die Phase nach der Werkzeugeinführung. Es gibt eine App-SBOM, eine Container-SBOM, eine Firmware-SBOM, mehrere Lieferanten-SBOMs und eine Tabelle, die ein Produktmanager pflegt. Keine davon ist die maßgebliche Antwort für das Produktrelease, das auf dem Markt bereitgestellt wurde.
Das erzeugt Audit- und Betriebsrisiko. Wenn eine neue aktiv ausgenutzte Schwachstelle auftaucht, muss das Team Fragmente durchsuchen, bevor es sagen kann, ob das Produkt betroffen ist. Wenn eine Behörde einen begründeten Antrag stellt, sollte das Nachweispaket nicht davon abhängen, dass jemand weiß, in welchem Ordner der letzte Zusammenführungsstand liegt.
Verwenden Sie eine maßgebliche Produkt-SBOM pro Release, mit unterstützenden Komponenten-SBOMs darunter. Bewahren Sie sie mindestens 10 Jahre nach der Marktbereitstellung des Produkts auf oder für die Dauer des Supportzeitraums, je nachdem, was länger ist. Speichern Sie sie dort, wo Release, Schwachstellenüberwachung, VEX-Entscheidungen und technische Dokumentation alle auf dieselbe Version verweisen können.
Häufig gestellte Fragen
Mein Scanner meldet keine Schwachstellen. Ist die SBOM damit gut genug?
Nicht für sich allein. Ein sauberer Schwachstellen-Scan belegt nur, dass der Scanner keine bekannten Schwachstellen gegen die sichtbaren Komponenten gefunden hat. Wenn die SBOM nur aus Quell-Manifests erstellt wurde, Firmware-Blobs fehlen, PURLs oder Hashes fehlen oder Lieferantenkomponenten ausgelassen wurden, kann das saubere Ergebnis ein Abdeckungsproblem sein, kein Sicherheitsergebnis.
Müssen wir die SBOM veröffentlichen oder jedem Kunden aushändigen?
Nein. Der CRA begründet keine allgemeine Pflicht zur Veröffentlichung der SBOM. Bewahren Sie sie in der technischen Dokumentation auf und stellen Sie sie einer Marktüberwachungsbehörde auf begründeten Antrag bereit, wenn dies zur Überprüfung der Konformität erforderlich ist. Sie können SBOM-Informationen vertraglich mit Kunden teilen, aber das ist etwas anderes als eine allgemeine CRA-Veröffentlichungspflicht.
Was ist die gesetzliche Mindestanforderung für die Abhängigkeitsabdeckung?
Der CRA verlangt, dass die SBOM zumindest Top-Level-Abhängigkeiten abdeckt. Das ist die Untergrenze. Für echtes Schwachstellenmanagement ist die Abdeckung mit nur direkten Abhängigkeiten schwach, weil viele Schwachstellen in transitiven, gebündelten oder neu verpackten Komponenten liegen. Richten Sie Ihr operatives Ziel am ausgelieferten Artefakt und den Abhängigkeitsbeziehungen aus, nicht nur am gesetzlichen Mindestsatz.
Wir generieren aus dem Quellcode. Reicht das?
Meist nicht. Quell-SBOMs sind für die Entwicklungsüberprüfung nützlich, aber der Produktnachweis muss widerspiegeln, was ausgeliefert wurde. Generieren Sie aus dem gebauten Artefakt oder Image, vergleichen Sie mit Lock-Datei- und Quell-Output und fügen Sie manuelle Einträge für Komponenten hinzu, die automatisierte Tools nicht ableiten können.
Unser Lieferant gibt uns keine vollständige SBOM. Was sollen wir tun?
Beginnen Sie mit dem Vertrag und dem Einkaufsprozess. Kann der Lieferant trotzdem keine vollständigen Daten liefern, dokumentieren Sie die bekannten Unbekannten, erfassen Sie die Felder, die Sie selbst prüfen können, fügen Sie Hashes und Versionsnachweise für die gelieferten Binärdateien hinzu und dokumentieren Sie die Lücke in der technischen Dokumentation. Lassen Sie die Komponente nicht stillschweigend aus der Produkt-SBOM weg.