SBOM und Vulnerability Management

Dieser Beitrag ist ein Entwurf und wird noch fachlich geprüft.

Eine SBOM macht Softwarebestandteile sichtbar. Erst mit Ownership, Risikoanalyse, Patch- und Updateprozessen entsteht daraus eine wirksame Grundlage für Produktsicherheit und langfristige Nachvollziehbarkeit.

Was eine SBOM ist – und was nicht

Eine Software Bill of Materials listet die Komponenten eines Produkts mit Version und Herkunft auf, üblicherweise in einem maschinenlesbaren Format wie CycloneDX oder SPDX. Sie beantwortet die Frage „Was steckt drin?“ – aber nicht, ob eine Schwachstelle in einer Komponente das Produkt tatsächlich betrifft, wer sich darum kümmert und bis wann.

Vom Verzeichnis zum Prozess

Erzeugen: Die SBOM entsteht automatisiert im Build, für jedes Release.
Abgleichen: Komponenten werden laufend gegen Schwachstellendatenbanken geprüft.
Bewerten: Ist die verwundbare Funktion im Produkt überhaupt erreichbar? Die Antwort wird dokumentiert.
Beheben: Updates werden priorisiert, getestet und ausgeliefert.
Kommunizieren: Kunden und, wo vorgeschrieben, Behörden werden informiert.

Was daraus folgt

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu kennen und Schwachstellen über den Supportzeitraum zu behandeln. Eine SBOM ist dafür Voraussetzung, aber kein Ersatz für den Prozess dahinter.

Quellen

Dieser Beitrag ist eine technische Einordnung und ersetzt keine Rechtsberatung. Maßgeblich sind die Primärquellen.