CRA und SBOM: Wann Tools versagen & warum das ein Problem ist

Wenn Hersteller sich mit dem Cyber Resilience Act (CRA) beschäftigen, taucht ein Thema zuverlässig auf: die Software Bill of Materials, kurz SBOM. Die Reaktion vieler Unternehmen ist nachvollziehbar: Ein SBOM-Tool evaluieren, in die Build-Pipeline integrieren, fertig. Das Thema SBOM ist damit abgehakt.

Nur leider ist es das nicht. Denn wer die SBOM-Anforderung des CRA auf den Output eines Scan-Tools reduziert, versteht die Anforderung falsch und übersieht dabei blinde Flecken, die bei einer Konformitätsbewertung zum Problem werden.

Was der CRA tatsächlich verlangt

Der CRA fordert in Anhang I, Teil II, dass Hersteller eine Dokumentation der Softwarekomponenten bereitstellen, einschließlich einer SBOM. Diese Anforderung steht im Kontext der technischen Dokumentation, die den gesamten Lebenszyklus eines Produkts begleitet.

Entscheidend ist dabei: Die SBOM ist nicht das Ergebnis eines nachgelagerten Scans. Sie basiert auf einer gepflegten Komponentenliste, die im Entwicklungsprozess entsteht und kontinuierlich aktualisiert wird. Diese Liste dokumentiert, welche Software- und Firmware-Bausteine in einem Produkt enthalten sind – und zwar vollständig, nicht nur die Teile, die ein automatisiertes Tool erkennen kann.

Der CRA verlangt damit, die Komponenten eines Produkts mit digitalen Elementen zu ermitteln und zu dokumentieren; die SBOM muss zumindest die obersten Abhängigkeiten abbilden. Zu dieser obersten Ebene gehören in der Regel eigene Software, Drittanbieter-Bibliotheken, Open-Source-Komponenten und Firmware in zugekauften Bauteilen.

Wo SBOM-Tools an ihre Grenzen stoßen

SBOM-Scanner leisten durchaus einen sinnvollen Beitrag. Sie analysieren Quellcode und Build-Artefakte, identifizieren bekannte Softwarepakete und erzeugen daraus eine maschinenlesbare Komponentenliste – typischerweise im SPDX- oder CycloneDX-Format. Für reine Softwareprodukte mit bekannten Paketmanagern funktioniert das oft gut.

Bei Produkten mit digitalen Elementen im Sinne des CRA, also Geräten, Maschinen und eingebetteten Systemen, sieht die Realität anders aus. Viele dieser Produkte enthalten Komponenten, die ein Scanner schlicht nicht erkennen kann:

• Firmware in Zulieferteilen: Ein Mobilfunkmodem, ein Bluetooth-Chip oder ein spezialisierter Sensor bringt eigene Firmware mit. Diese läuft auf dem Gerät, ist aber weder im eigenen Quellcode sichtbar noch über Paketmanager aufzulösen. Für einen Scanner existiert diese Firmware nicht.
• Zugekaufte Softwaremodule: Proprietäre Bibliotheken von Zulieferern, die als Binärdateien eingebunden werden, tauchen in keinem automatisierten Scan auf.
• Betriebssystem-Schichten und Board Support Packages: BSPs für eingebettete Systeme enthalten oft Patches, Treiber und Konfigurationen, die über die Standardpakete hinausgehen.

Das Ergebnis: Ein SBOM-Scan liefert eine Teilmenge der tatsächlich im Produkt enthaltenen Komponenten. Wer diese Teilmenge für die vollständige SBOM hält, hat eine Lücke in der Dokumentation, die bei genauerer Prüfung auffällt.

Die Komponentenliste als Ausgangspunkt

Die eigentliche Grundlage der SBOM ist keine Tool-Ausgabe, sondern eine im Entwicklungsprozess gepflegte Komponentenliste. Diese Liste entsteht idealerweise zu Beginn des Produktdesigns und wächst mit jeder Designentscheidung: Welches Betriebssystem wird eingesetzt? Welche Bibliotheken werden eingebunden? Welche Zulieferteile bringen eigene Firmware mit?

Diese Komponentenliste ist ein Arbeitsdokument der Entwicklung. Sie wird ergänzt, wenn neue Abhängigkeiten hinzukommen, und bereinigt, wenn Komponenten entfernt werden. Am Ende des Entwicklungsprozesses bildet sie die Basis, aus der die SBOM für die technische Dokumentation erstellt wird.

Der SBOM-Scan übernimmt in diesem Bild eine andere Rolle als viele annehmen: Er ist eine Validierung, kein Ausgangspunkt. Der Scan gleicht ab, ob die gepflegte Komponentenliste mit dem tatsächlichen Build übereinstimmt. Weicht das Ergebnis des Scans von der Liste ab (z.B. fehlen Komponenten oder tauchen unbekannte auf), deutet das auf ein Problem im Entwicklungsprozess hin. Etwas wurde hinzugefügt, ohne es zu dokumentieren, oder eine dokumentierte Komponente wurde ersetzt, ohne die Liste zu aktualisieren.

Wer diese Reihenfolge umdreht und den Scan zur Quelle der SBOM macht, verliert genau diese Kontrollfunktion und damit einen wesentlichen Baustein der geforderten Nachvollziehbarkeit.

Der Bezug zum sicheren Entwicklungsprozess

Die Anforderung an eine vollständige Komponentenliste steht nicht isoliert. Der CRA verlangt von Herstellern insgesamt, dass Produkte mit digitalen Elementen unter Berücksichtigung der Cybersicherheit entwickelt werden. Die Dokumentation der eingesetzten Komponenten ist Teil dieses sicheren Entwicklungsprozesses.

Wer hier bereits mit etablierten Frameworks arbeitet, erkennt die Parallele: Die IEC 62443-4-1 etwa fordert im Rahmen des sicheren Entwicklungslebenszyklus explizit ein Komponentenmanagement. Komponenten werden erfasst, bewertet und über den gesamten Lebenszyklus nachverfolgt. Die gepflegte Komponentenliste ist dort kein optionales Artefakt, sondern integraler Bestandteil des Prozesses.

Hersteller, die einen solchen Prozess bereits etabliert haben, bringen damit eine wesentliche Voraussetzung für die CRA-konforme SBOM-Erstellung mit. Wer dagegen ausschließlich auf Scan-Tools setzt, hat zwar ein Werkzeug, aber keinen Prozess.

Fazit

Die SBOM-Anforderung des CRA lässt sich nicht mit einem Tool allein erfüllen. Der CRA verlangt eine dokumentierte Übersicht der Komponenten eines Produkts, die zumindest die obersten Abhängigkeiten abbildet, einschließlich Firmware in Zulieferteilen, die kein Scanner erkennen kann. Die Grundlage dafür ist eine gepflegte Komponentenliste im Entwicklungsprozess. Der Scan ist ein sinnvolles Mittel zur Validierung, aber kein Ersatz für den Prozess selbst.

Hersteller, die früh verstehen, dass die SBOM ein Ergebnis ihres Entwicklungsprozesses ist und kein nachgelagertes Scan-Artefakt, sparen sich nicht nur Nacharbeit bei der Konformitätsbewertung – sie schaffen die Grundlage für ein belastbares Schwachstellenmanagement über den gesamten Produktlebenszyklus.