SBOM und Schwachstellenmanagement: Nachweise für den Cyber Resilience Act aufbauen

Die SBOM als Arbeitsgrundlage

Das BSI beschreibt die Software Bill of Materials als Inventarliste der verwendeten Softwarekomponenten. Nach seiner CRA-Übersicht ist die Erstellung einer SBOM vorgesehen; sie muss nicht veröffentlicht werden. Der praktische Wert liegt darin, Abhängigkeiten zwischen Produktversionen und Komponenten nachvollziehen zu können. Wird eine Schwachstelle in einer Bibliothek bekannt, muss schnell ermittelt werden können, welche Produkte und Versionen diese Komponente tatsächlich enthalten.

Mehr als eine Komponentenliste

Anhang VII der CRA-Dokumentation verbindet die SBOM mit weiteren Informationen zur Schwachstellenbehandlung. Dazu gehören Angaben zum Konzept für koordinierte Offenlegung von Schwachstellen, eine Kontaktadresse für Meldungen und die gewählten technischen Lösungen zur sicheren Verbreitung von Aktualisierungen. Damit ist eine SBOM kein isoliertes Compliance-Dokument, sondern Teil eines größeren Betriebsprozesses.

Drittkomponenten bleiben eine Herstellerfrage

Die EU-Zusammenfassung verlangt bei integrierten Drittkomponenten gebotene Sorgfalt, damit diese die Cybersicherheit des eigenen Produkts nicht beeinträchtigen. Das betrifft auch Open-Source-Komponenten. Für Hersteller bedeutet das organisatorisch: Komponenten müssen nicht nur bei der Entwicklung ausgewählt, sondern über Versionen und Supportzeiträume hinweg beobachtet werden. Die Lieferkette wird dadurch Bestandteil des eigenen Schwachstellenmanagements. Die Kommission weist außerdem darauf hin, dass Hersteller relevante Schwachstellen in integrierten Komponenten an die Person oder Stelle melden sollen, die diese Komponente pflegt.

Was in der technischen Dokumentation zusammenläuft

Neben Komponenten- und Schwachstelleninformationen gehören auch die Cybersicherheits-Risikobewertung, angewandte Standards oder technische Lösungen, Testberichte und die EU-Konformitätserklärung in die technische Dokumentation. Diese Unterlagen werden vor dem Inverkehrbringen erstellt und müssen während des relevanten Zeitraums aktuell gehalten werden. Fehlende Nachweise sollten deshalb nicht erst als reine Schlussdokumentation behandelt werden.

Ein pragmatischer Start

Der erste Schritt ist eine Bestandsaufnahme: Gibt es eine maschinenlesbare Komponentenliste? Ist sie Produktversionen zugeordnet? Existiert ein definierter Eingang für Schwachstellenmeldungen? Wer bewertet eine Meldung? Wie werden Security-Updates gebaut, getestet und verteilt? Eine unverbindliche Vorprüfung kann diese Kette von SBOM bis Schwachstellenprozess gegen die belegten CRA-Anforderungen spiegeln. Sie ist keine Zertifizierung und ersetzt keine Rechtsberatung.

Häufige Fragen