Moderne Software besteht zum grössten Teil aus fremden Komponenten: Open-Source-Bibliotheken, Frameworks und deren Abhängigkeiten. Wird in einer davon eine Lücke bekannt, stellt sich sofort die Frage: Sind wir betroffen? Eine SBOM beantwortet sie in Minuten statt Tagen.
Was sie enthält
Für jede Komponente Name, Version, Lieferant oder Herkunft, Lizenz und die Abhängigkeitsbeziehung zu anderen Komponenten. Die Formate SPDX und CycloneDX sind weit verbreitet und werden von vielen Build-Werkzeugen direkt erzeugt.
Nutzen
Beim Schwachstellenmanagement lässt sich eine neue Lücke automatisch gegen alle SBOMs abgleichen. Bei Lizenzfragen zeigt die SBOM, welche Lizenzen im Produkt enthalten sind. Und bei einer Tech Due Diligence ist sie ein schneller Beleg für die Qualität des Abhängigkeitsmanagements.
Pflicht nach dem CRA
Der Cyber Resilience Act verlangt von Herstellern, eine SBOM zumindest für die obersten Abhängigkeiten des Produkts zu erstellen und in die technische Dokumentation aufzunehmen. Die Pflichten gelten weitgehend ab Dezember 2027; die Meldepflichten für aktiv ausgenutzte Lücken schon seit September 2026. Wer heute Software für den EU-Markt entwickelt, sollte die SBOM-Erzeugung jetzt in die Build-Pipeline aufnehmen.
Praxis
Eine SBOM ist nur nützlich, wenn sie bei jedem Build aktualisiert und zentral abgelegt wird. Ein einmal erstelltes Dokument veraltet mit dem nächsten Update. Die Erzeugung gehört deshalb automatisiert in die Pipeline, zusammen mit einer Prüfung auf bekannte Lücken.