Sie kann eigene und fremde Komponenten, Versionen, Lieferanten, eindeutige Kennungen, Abhängigkeitsbeziehungen sowie Informationen darüber identifizieren, wann und wie der Datensatz erstellt wurde.
Eine SBOM gibt Produzenten und Konsumenten ein gemeinsames Inventar für Fragen wie ob eine Komponente vorhanden ist, welche Produkte von neuen Informationen betroffen sein könnten und wo Lizenz- oder Wartungsprüfung nötig ist. Maschinenlesbare Standards wie SPDX und CycloneDX erleichtern Austausch und Automatisierung dieser Informationen. Die SBOM muss weiterhin an ein bestimmtes Release oder Artefakt gebunden sein und aktuell gehalten werden, während sich die Software ändert.
Wichtigste Punkte
KerninformationenSBOM-Autor, Software-Produzent, Komponentennamen und -versionen, Kennungen und Hashes, Lizenzen, Abhängigkeitsbeziehungen, Erzeugungswerkzeug und -kontext, Zeitstempel und deklarierte Abdeckung.
Operative NutzungKomponenten-Discovery, Schwachstellenuntersuchung, Lizenzprüfung, Lieferantenkommunikation, Asset-Korrelation und Vergleich zwischen Software-Releases.
QualitätskontrollenNahe am autoritativen Build erzeugen, transitive und eingebettete Komponenten einbeziehen, bekannte Vollständigkeitsgrenzen angeben, Kennungen validieren, die Integrität schützen und Sharing-Regeln definieren.
Wichtige EinschränkungEine SBOM ist ein Inventar, kein Schwachstellen- oder Ausnutzbarkeitsurteil. Sie kann zeigen, dass eine Komponente vorhanden ist, ohne zu zeigen, ob betroffener Code erreichbar, konfiguriert oder mitigiert ist.