SBOM-Wartung über Produktreleases hinweg
Sytance · Aktualisiert
Eine SBOM muss der Softwareversion zugeordnet bleiben, die sie beschreibt. Ein Softwareupdate kann Komponenten ändern, während eine Korrektur der SBOM lediglich Angaben zu einer unveränderten Version berichtigt. Werden beide Versionen dokumentiert, lässt sich feststellen, was Kunden erhalten haben und welches Verzeichnis die Software korrekt beschreibt.
Die von jedem Verzeichnis beschriebene Software
Legen Sie im Build- oder Releaseprozess einen wiederholbaren Zeitpunkt zur Erstellung der SBOM fest. Bewahren Sie den Quellcode-Stand, aufgelöste Abhängigkeiten, die Build-Konfiguration und die Identität des endgültigen Artefakts auf, die zur Reproduktion oder Untersuchung des Verzeichnisses erforderlich sind.
Der Leitfaden zu CycloneDX unterscheidet zwischen Verzeichnissen, die aus dem Quellcode, während eines Builds und im Betrieb erstellt werden. Diese Phasen können unterschiedliche Software umfassen. Die Angabe der Phase zeigt Empfängern, ob die SBOM deklarierte Abhängigkeiten, ein Build-Ergebnis oder bereitgestellte Software beschreibt.
Führen Sie bei einem Gateway Informationen aus dem Anwendungs-Build, dem Basis-Image und den mitgelieferten Firmwarekomponenten zusammen. Bewahren Sie die Zuordnung zu den jeweiligen Lieferanten-SBOMs auf. Für einen vom Gateway genutzten Cloud-Dienst kann ein separates Verzeichnis mit einem eigenen Releasezyklus erforderlich sein.
Komponentenänderungen zwischen Releases
Ein Releasevergleich zeigt, welche Komponenten hinzugefügt, entfernt, aktualisiert oder neu erstellt wurden und welche Abhängigkeitspfade sich geändert haben. Die bloße Anzahl der Komponenten kann einen Austausch übersehen: Eine Bibliothek kann entfernt und eine andere hinzugefügt werden, ohne dass sich die Gesamtzahl ändert.
Verwenden Sie für den Vergleich normalisierte Identitäten und bewahren Sie zugleich die ursprüngliche Version und die ursprünglichen Kennungen auf. Wenn ein Tool zuvor unbekannte Pakete nun erkennt, ist zwischen besserer Sichtbarkeit und einer tatsächlichen Softwareänderung zu unterscheiden.
- Hinzugefügte oder entfernte Komponenten und ihre übergeordneten Abhängigkeitspfade.
- Versionsänderungen, nachgelagerte Patches und geänderte Artefakt-Hashes.
- Änderungen an Lizenzangaben oder Komponentenerstellern.
- Neue Informationslücken, korrigierte Kennungen und überarbeitete Lieferanten-SBOMs.
Prüfungen vor der Freigabe
Validieren Sie die Datei anhand der Formatversion und prüfen Sie anschließend ihre Bedeutung. Vergewissern Sie sich, dass alle Verweise aufgelöst werden, das Stammprodukt dem vorgesehenen Release entspricht und der Empfänger auf alle verknüpften Komponenten-SBOMs zugreifen kann.
Führen Sie für den Kandidaten Schwachstellen- und Lizenzprüfungen durch und dokumentieren Sie die Ergebnisse für dieses Release. Für ein neu eingeführtes Problem mit hoher Priorität ist eine Behandlungsentscheidung erforderlich. Eine ältere Ausnahme sollte erneut geprüft werden, wenn sich die Komponentenversion oder die Betriebsannahmen geändert haben.
Archivieren Sie das freigegebene Artefakt, die SBOM, die Build-Referenzen und das Prüfergebnis gemeinsam. Wenn eine Signatur verwendet wird, prüfen Sie sie und bestätigen Sie, dass sie vom erwarteten Aussteller stammt.
Korrekturen an einer bestehenden SBOM
Die gemeinsame SBOM-Leitlinie von 2026 fordert eine SBOM für jede Softwareversion oder jedes Update sowie eine überarbeitete SBOM, wenn Fehler korrigiert werden oder neue Angaben zu Komponenten bekannt werden. Sie unterscheidet außerdem zwischen unbekannten und bewusst zurückgehaltenen Informationen.
Beispielsweise korrigiert ein Lieferant die Herstellerangabe einer Komponente, während die Firmwarebytes unverändert bleiben. Behalten Sie die Firmwareidentität bei, geben Sie eine neue SBOM-Revision heraus, erläutern Sie die Korrektur und bewahren Sie das vorherige Dokument auf. So können Empfänger eine Datenkorrektur von einem Softwareupdate unterscheiden.
Veröffentlichen Sie ein Update über den vereinbarten Bereitstellungskanal. Eine stabile Einstiegsseite kann auf die aktuelle Revision verweisen, während unveränderliche Dateien die Historie erhalten. Stellen Sie sicher, dass Empfänger erkennen können, welche Revision eine frühere ersetzt.
Neue Schwachstellen in unterstützten Releases
Wenn eine Sicherheitsmeldung eingeht, durchsuchen Sie die Komponentenidentitäten in allen unterstützten Releases. Prüfen Sie die tatsächlichen Builds und die Produktverwendung, bevor Sie die Auswirkungen bestimmen. Halten Sie das Komponentenverzeichnis von der Schwachstellenbewertung getrennt, damit dieselbe SBOM bei neuen Informationen erneut bewertet werden kann.
Enthält Gateway-Release 1.0 eine betroffene Bibliothek und entfernt Release 1.1 diese, ändert das neue Release nicht die Zusammensetzung der installierten Geräte mit Version 1.0. Das Team muss dennoch eine Reaktion für diese Geräte festlegen und genau dokumentieren, welche Versionen von einer Sicherheitsmeldung oder VEX-Aussage erfasst werden.
Legen Sie fest, wer Aktualisierungen von Lieferanten pflegt, die Auswirkungen bewertet, eine Reaktion freigibt und sie kommuniziert. Bestimmen Sie den Prüfzeitpunkt anhand der Supportpflichten des Produkts und der Schwere neuer Informationen, statt sich ausschließlich auf das nächste planmäßige Release zu verlassen.
Aufbewahrung und Übergabe von Aufzeichnungen
Bewahren Sie am Ende des Supports die Zuordnung zwischen Releases und SBOMs sowie die Entscheidungen auf, die zur Erläuterung früherer Lieferungen erforderlich sind. Schränken Sie sensible Aufzeichnungen angemessen ein und stellen Sie zugleich sicher, dass berechtigte Empfänger die ihnen zugesagten Informationen erhalten können.
Bei einer Übergabe muss eine neue wartende Person das Verzeichnis für eine Produktversion finden, eine Komponente auffinden und die aktuelle Auswirkungsbewertung einsehen können. Ein Durchlauf anhand eines unterstützten Releases hilft, fehlende Aufzeichnungen oder Zugriffsberechtigungen zu erkennen.