Das Europäische Parlament hat am 12. März das EU-Gesetz zur Cyber-Resilienz (CRA) angenommen.
Das CRA nutzt die Software-Stückliste (SBOM), um die Produktsicherheit zu beschreiben, aufzuzeichnen und zu überwachen. Daher wird in Kürze ein formelles Dokument erwartet, das die CRA-Compliance-Anforderungen umreißt und insbesondere alle SBOM-spezifischen Anforderungen beschreibt.
In Erwartung der Verabschiedung des CRA hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) jedoch bereits an der Klärung der SBOM-Anforderungen gearbeitet. Die Technische Richtlinie TR-03183: Cyber-Resilienz-Anforderungen für Hersteller und Produkte (Teil 2: Software-Stückliste (SBOM)) ist seit dem 28. November veröffentlicht.
TR-03183: SBOM-Anforderungen für das CRA
Das 17-seitige Anforderungsdokument ist hier veröffentlicht.
Die wichtigsten Anforderungen lassen sich wie folgt zusammenfassen:
Die Erstellung einer SBOM ist zwingend erforderlich, um den CRA zu erfüllen.
Eine SBOM MUSS bestimmte Mindestinformationen enthalten, KANN jedoch nach Wunsch erweitert und detailliert werden.
Für jede Softwareversion MUSS eine neue, separate SBOM erstellt werden.
Eine neue Version der SBOM für eine bestimmte Softwareversion MUSS genau dann erstellt werden, wenn zusätzliche Informationen zu den enthaltenen Softwarekomponenten bereitgestellt oder Fehler in den SBOM-Daten korrigiert werden.
Es ist NICHT erforderlich, Schwachstelleninformationen in die SBOM aufzunehmen.
Die SBOM muss in einer der beiden Spezifikationen vorliegen: CycloneDX Version 1.4 oder höher ODER SPDX Version 2.3 oder höher.
Die SBOM MUSS als Teil des Build-Prozesses oder dessen Äquivalent erstellt werden, falls kein Build-Prozess existiert.
Der Ersteller der SBOM MUSS per E-Mail identifiziert werden, andernfalls muss auf eine URL zurückgegriffen werden.
Datum und Uhrzeit der SBOM-Datenerfassung MÜSSEN enthalten sein.
Für jede in der SBOM enthaltene Komponente gilt Folgendes —
Der Name der Komponente, die Version (bevorzugt SemVer oder Calendar) und eine Liste der Komponenten, von denen diese Komponente abhängt, MÜSSEN enthalten sein.
Die Lizenz der Komponente MUSS für jede Lizenz angegeben und mit ihrer SPDX-Kennung identifiziert werden.
Wenn die Lizenz in SPDX nicht gefunden wird, muss ScanCode LicenseDB AboutCode verwendet werden. Diese müssen mit
LicenseRef-scancode-gekennzeichnet werden.Wenn beides die Lizenz nicht findet, muss
LicenRef-<unique-inventorying-entity>verwendet werden, um die Kriterien für den Lizenzausdruck von SPDX zu erfüllen.Die Komponente MUSS einen Hashwert als SHA-256 enthalten.
Die SBOM KANN eine SBOM-URI enthalten.
Jede SBOM-Komponente KANN die Quellcode-URI, die URI der ausführbaren Form des Bausteins, den Hashwert des Quellcodes als SHA-256 (genaue Methode noch unbestimmt) und andere eindeutige Kennungen der Komponente wie CPE oder PURL enthalten.
Die Richtlinie empfiehlt außerdem CSAF (mit einem VEX-Profil) als Format für die separate Verteilung von Schwachstellen außerhalb der SBOM.
Die Technische Richtlinie TR-03183 ist ein wichtiger Schritt nach vorn, um die genauen Schritte zu klären, die Softwareentwickler unternehmen müssen, um die CRA-Konformität zu erfüllen. Dennoch müssen noch Fragen beantwortet werden.
Ohne CPE oder PURL als Identifikationsanforderung ist die Erstellung von Schwachstellenberichten aus der SBOM fehleranfällig.
Die Richtlinie verwendet den Begriff „Lieferumfang“, um die Tiefe zu definieren, in der die transitive Komponente aufgelistet werden muss. Sie enthält jedoch keine Anleitung zu einem akzeptablen „Lieferumfang“.
In den Richtlinien wird ausdrücklich eingeräumt, dass die Methode zur Berechnung des SHA-256 des Quellcodes noch fertiggestellt werden muss.
Die Richtlinien fordern die rekursive Einbeziehung aller transitiven Komponenten, verlangen aber nicht ausdrücklich die Angabe von Beziehungen zwischen diesen Komponenten. Nach unserer Erfahrung sind fehlende oder ausgelassene Beziehungen ein häufiges Problem bei SBOM-Generatoren und wirken sich negativ auf die Nutzung der SBOM für das Schwachstellenmanagement aus.