Wissen welche Software im ausgelieferten Produkt steckt
RTOS, Bootloader, SDK und Bibliotheken beeinflussen die Sicherheit Ihres Geräts. Eine Software Bill of Materials, kurz SBOM, verbindet diese Komponenten mit dem ausgelieferten Produktstand. Erst diese Zuordnung macht aus einer allgemeinen Schwachstellenwarnung eine konkrete technische Prüfung.
SBOM und Komponentenbestand prüfenKomponentenbestand mit dem Release verbinden
Der CRA verlangt im Rahmen der Schwachstellenbehandlung eine SBOM in einem gängigen maschinenlesbaren Format, mindestens mit den obersten Abhängigkeiten. SPDX und CycloneDX sind gebräuchliche Optionen; sie werden hier als technische Formate empfohlen. Eine tiefere Erfassung ist dort sinnvoll, wo transitive Abhängigkeiten Sicherheitsrisiken verdecken können.
Für neue Produkte sollte die SBOM aus dem Build-Prozess entstehen. Bei Legacy-Firmware können Quellcodeanalyse, vorhandene Lieferantenlisten und Binary-Analyse zusammenwirken. Unsicherheiten bleiben sichtbar: Eine aus Binärdateien rekonstruierte Liste ist kein garantierter Vollständigkeitsnachweis. Eine allgemeine Pflicht zur öffentlichen Veröffentlichung der SBOM folgt aus dem CRA nicht.
Beispiel einer Bibliothekswarnung
Eine Meldung betrifft eine Kryptobibliothek. Die releasebezogene SBOM zeigt, welche Geräteversionen den Baustein enthalten. Technisch ist danach zu prüfen, ob die verwundbare Funktion erreichbar ist und welche Abhilfe benötigt wird. Ein Datenbanktreffer allein belegt weder aktive Ausnutzung noch eine Meldepflicht. Das Beispiel ist illustrativ.
Was Solvetronix mit Ihnen erarbeitet
- SBOM für den vereinbarten Umfang mit Versions- und Build-Bezug.
- Dokumentierte Erfassungslücken und Fragen an Komponentenlieferanten.
- Ablauf für Aktualisierung, Betroffenheitsprüfung und Abhilfe.
Weiterführende Themen
Rechtsgrundlagen und Quellen
Allgemeine Information und technische Orientierung. Die konkrete Einordnung hängt von Produkt, Rolle und Einsatz ab. Stand 22. Oktober 2026.