SBOM- und Komponentenaufzeichnungen nach dem CRA

Anforderung in Anhang I

Schwachstellen und Komponenten, die in Produkten mit digitalen Elementen enthalten sind, identifizieren und dokumentieren, unter anderem durch die Erstellung einer Software-Stückliste in einem gängigen und maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene des Produkts erfasst;

Verordnung (EU) 2024/2847, Anhang I, Teil II, Nummer 1

Die SBOM ist Teil einer umfassenderen Komponentenakte. Sie hilft dem Hersteller zu verstehen, welche Komponenten im Produkt enthalten sind und welche Schwachstellen diese Komponenten betreffen können.

Was zu unterscheiden ist

Beispiel: ein nachvollziehbarer Komponentendatensatz

Der folgende fiktive Datensatz beschreibt eine direkte Softwareabhängigkeit in einer Firmwareversion eines Steuergeräts. Er veranschaulicht nützliche technische Informationen; die Felder sind kein zusätzliches, vom CRA vorgeschriebenes Schema.

• Produkt: Firmware 1.2.0 für Steuergerät, Build 120; das Inventar wurde anhand des freigegebenen Builds und seiner Abhängigkeitsdaten erstellt.
• Komponente: example-parser 2.4.0, bereitgestellt vom fiktiven Projekt Example Components; direkte Abhängigkeit der Firmware.
• Identität und Herkunft: Paketkennung, exakte Quellrevision oder Lieferantenreferenz sowie ein tatsächlicher Hashwert des bereitgestellten Artefakts.
• Verwendung: Die Komponente analysiert eine Konfigurationsdatei, die über eine authentifizierte Wartungsschnittstelle hochgeladen wird. Relevante Build-Optionen und die aufrufende Komponente dokumentieren.
• Nachweise: Verknüpfung mit der maschinenlesbaren SBOM und den Build- oder Lieferantenaufzeichnungen, anhand derer dieser Eintrag überprüft wurde. Das Inventar der vorherigen Version aufbewahren, wenn sich die Komponente ändert.

Name und Version einer Komponente können helfen, mögliche Schwachstellen zu finden. Ob ein Produkt betroffen ist, erfordert weitere Analysen: ob der anfällige Code enthalten ist, ob die betroffene Funktion ausgeführt wird, welche Eingabe ein Angreifer erreichen kann und welche Kontrollen relevant sind. Ein nicht aufgelöster Treffer bleibt Gegenstand der Untersuchung; er belegt nicht, dass das Produkt nicht betroffen ist.

Eine Aussage wie „nicht betroffen“ sollte die Produktversion, die Schwachstelle, die technische Begründung und die unterstützenden Nachweise nennen. Sie ist erneut zu prüfen, wenn sich eine Build-Option, Komponentenversion, Schnittstelle oder Bereitstellungsannahme ändert.

Verknüpfung mit der technischen Dokumentation

Anhang VII ordnet Informationen zu Komponenten und SBOM der technischen Dokumentation zu. Außerdem verlangt er Informationen zum Prozess für den Umgang mit Schwachstellen, zur Richtlinie für die koordinierte Offenlegung von Schwachstellen, zur Meldestelle und zur sicheren Verteilung von Updates.

Die Prozessseite wird erläutert unter Aufzeichnungen zum Umgang mit Schwachstellen und prEN 40000-1-3 Umgang mit Schwachstellen.

Formatstatus

Anhang I verlangt eine gängige, maschinenlesbare SBOM, die mindestens die Abhängigkeiten der obersten Ebene erfasst. Artikel 13 Absatz 24 erlaubt der Kommission außerdem, ihr Format und ihre Elemente durch einen Durchführungsrechtsakt festzulegen und dabei europäische oder internationale Normen sowie bewährte Verfahren zu berücksichtigen. Bei der Formatwahl ist daher zwischen den Mindestanforderungen der Verordnung und anwendbaren Durchführungsanforderungen zu unterscheiden.

• Eine PDF-Liste von Komponenten erfüllt nicht die Anforderung an ein maschinenlesbares SBOM-Format.
• Die SBOM identifiziert Komponenten; der Umgang mit Schwachstellen erfordert zusätzlich Auswirkungsanalyse, Abhilfe und Kommunikation.
• Anhang VII sieht den Zugriff der Behörden auf die SBOM auf Anfrage vor; er begründet keine allgemeine Pflicht, die SBOM zu veröffentlichen.