SBOM: Komponenteninformationen, Formate und Wartung
Sytance · Aktualisiert
Eine Software-Stückliste (SBOM) beschreibt die Softwarekomponenten einer Anwendung oder eines Systems und deren Beziehungen. Sie bietet einem Team einen Ausgangspunkt für das Komponentenverzeichnis, die Lizenzprüfung und die Untersuchung von Schwachstellen. Ihr Nutzen hängt davon ab, wie genau sie die tatsächlich ausgelieferte Software beschreibt.
Das in einer SBOM beschriebene Produkt
Eine SBOM beschreibt eine bestimmte Produktversion, einen Build oder ein Artefakt, etwa ein Firmware-Image oder Installationspaket. Komponenteneinträge identifizieren Bibliotheken und andere Software innerhalb dieses Umfangs. Versionen, Hersteller, Kennungen und Beziehungen zeigen, was enthalten war.
Bei einem fiktiven Industrie-Gateway ist die Firmwareversion das Zielprodukt. Die Verwaltungsanwendung und eingebettete Bibliotheken sind Komponenten. Ein Telemetriedienst aus der Ferne ist eine externe Abhängigkeit; seine Beschreibung bedeutet nicht, dass seine serverseitigen Pakete in der Firmware enthalten sind.
Das öffentliche Beispiel verwendet erfundene Komponenten, um die Struktur verständlich zu machen. Es enthält kein Komponentenverzeichnis von Sytance oder einem ausgelieferten Gateway.
Komponentenkennungen
Zwei Pakete mit ähnlichen Namen können zu verschiedenen Paketökosystemen gehören. Eine Package URL (purl) identifiziert ein Paket anhand von Feldern wie Typ, Namensraum, Name und Version. Ein Datei-Hash hilft, eine exakte Datei zu identifizieren, wenn Hashalgorithmus und gehashte Datei bekannt sind.
Verwenden Sie Paketmetadaten oder Lieferanteninformationen, um Kennungen zu bestimmen. Eine purl, die auf Grundlage eines vermuteten Herstellers zusammengestellt wurde, kann auf das falsche Paket verweisen. Bewahren Sie die ursprüngliche Versionszeichenfolge auf, da ein nachgelagerter Build eine eigene Patch-Revision enthalten kann.
SPDX und CycloneDX stellen beide Informationen zu Softwarekomponenten und ihren Beziehungen dar. Die verfügbaren Felder und ihre genaue Bedeutung hängen von der Formatversion ab. Wählen Sie eine Version, die von den erzeugenden und empfangenden Werkzeugen verarbeitet werden kann.
Genauigkeit und Abdeckung des Inventars
Eine Datei kann gültiges JSON sein und trotzdem die falsche Version beschreiben. Vergleichen Sie die SBOM mit den Build-Eingaben und dem ausgelieferten Artefakt und untersuchen Sie anschließend Abweichungen. Eine Liste der Abhängigkeiten aus dem Quellcode kann Entwicklungswerkzeuge enthalten, die nie ausgeliefert wurden, und Bibliotheken auslassen, die in das Image kopiert wurden.
- Ziel: Produkt, Version und Artefakt stimmen mit der Veröffentlichung überein.
- Identität: Versionen und Kennungen der Komponenten lassen sich auf Nachweise zurückführen.
- Beziehungen: Abhängigkeitspfade sind vorhanden und aussagekräftig.
- Abdeckung: Fehlende Lieferantendaten und nicht analysierte Teile sind sichtbar.
- Austausch: Ein empfangendes Werkzeug erhält die für den vorgesehenen Einsatz nötigen Felder.
Die SBOM-Mindestelemente 2026
Die 2026 gemeinsam von CISA und Partnerbehörden veröffentlichten SBOM-Mindestelemente aktualisieren die NTIA-Leitlinie von 2021. Sie behandeln Dokumentmetadaten, Komponentendaten sowie Verfahren zur Pflege und Weitergabe von SBOMs. Die Veröffentlichung enthält Leitlinien und stellt klar, dass damit keine neuen Anforderungen entstehen.
Geben Sie für eine Lieferung die vereinbarte Spezifikation, die Formatversion und zusätzliche Kundenanforderungen an. Ein erfolgreiches Schema-Validierungsergebnis allein belegt nicht, dass die vom Kunden angeforderten Informationen vollständig sind.
Schwachstellenabgleich und Produktauswirkungen
Ein Schwachstellenabgleich verknüpft ein gemeldetes Problem mit einer Komponentenkennung oder Version. Als Nächstes ist zu klären, ob der betroffene Code in diesem Produkt vorhanden und ausnutzbar ist. Prüfen Sie Build-Optionen, Änderungen, Ausführungspfade und die im Sicherheitshinweis beschriebenen Bedingungen.
Vulnerability Exploitability eXchange (VEX) vermittelt die Bewertung einer bestimmten Schwachstelle für identifizierte Produkte. Verknüpfen Sie diese Bewertung mit der Version und den unterstützenden Analysen. Ein fehlender Abgleich kann auf eine begrenzte Abdeckung oder unvollständige Kennungen zurückzuführen sein.
Aufzeichnungen zu unterstützten Versionen
Archivieren Sie das ursprüngliche Inventar mit der Veröffentlichung. Wenn neue Informationen die SBOM korrigieren, ohne die Software zu ändern, erstellen Sie eine nachvollziehbare Dokumentrevision. Ändert sich die Software, erstellen Sie einen Datensatz für die neue Version.
Wenn ein neuer Sicherheitshinweis eine Schwachstelle in einer Komponente meldet, durchsuchen Sie die Inventare aller unterstützten Versionen. Kunden verwenden möglicherweise noch eine ältere Version mit anderen Komponenten als im aktuellen Produkt.