Eine SBOM kann beim ersten Versuch schnell entstehen. Schwieriger ist die Frage, ob sie auch beim nächsten Release noch stimmt. Neue Pakete, aktualisierte Bibliotheken und veränderte Build-Konfigurationen ändern den Softwarebestand. Eine manuell gepflegte Datei verliert dabei leicht den Bezug zur tatsächlichen Anwendung.
Wenn Sie eine SBOM in CI/CD integrieren, koppeln Sie ihre Erzeugung und Weitergabe an wiederkehrende Entwicklungsschritte. Unsere Experten und Referenten Ruben Brick und Yvette Teiken stellen im Vortrag dafür einen Workflow von der .NET-Anwendung über Azure DevOps bis zu Dependency-Track vor. Die lokale Live-Demo zeigt die Generierung und die anschließenden Analyseansichten; sie dient als anschauliches Beispiel für die einzelnen Bausteine.
Die SBOM an einen konkreten Softwarestand binden
Bevor ein zusätzlicher Pipeline-Schritt eingerichtet wird, sollte das Team festlegen, welchen Stand die SBOM beschreibt. Ein Entwicklungsbuild und eine freigegebene Produktversion haben unterschiedliche Zwecke. Für spätere Rückfragen muss erkennbar sein, welche SBOM zu welchem Release gehört.
Als Umsetzung empfehlen wir, Produktversion und Build-Kennung zusammen mit der SBOM zu archivieren. So lässt sich später nachvollziehen, ob eine Sicherheitsmeldung einen ausgelieferten Stand betrifft. Eine einzige Datei mit dem Namen „aktuelle SBOM“ wäre dafür unzureichend: Sie beantwortet keine Fragen zu älteren Versionen, die bei Kunden weiterhin im Einsatz sind.
SBOM in CI/CD integrieren: Generierung und Prüfung automatisieren
Für ein Pilotprojekt kann ein Team zunächst den lokal erprobten Generator in seiner Build-Umgebung ausführen. Anschließend sollte geprüft werden, ob die Ausgabedatei erzeugt wurde, technisch eingelesen werden kann und dem vorgesehenen Schema entspricht. Erst danach wird sie als Artefakt gespeichert oder an die weitere Auswertung übergeben.
Der genaue Zeitpunkt hängt vom untersuchten Gegenstand ab. Für eine Projektanalyse müssen die benötigten Abhängigkeitsinformationen verfügbar sein. Soll die SBOM ein fertiges Container-Image beschreiben, muss dieses Image bereits vorliegen. Entscheidend ist, dass Generator und Eingabedaten zu dem passen, was die SBOM später aussagen soll.
Es lohnt sich außerdem, Generatorversion und Konfiguration kontrolliert zu ändern. Eine unerwartet stark veränderte Komponentenliste sollte Anlass für eine Untersuchung sein. So wird die Pipeline nicht nur zum Dateierzeuger, sondern unterstützt auch die Qualität der Informationen.
Die Daten an Dependency-Track übergeben
Nach der Erzeugung müssen die Daten dort ankommen, wo sie genutzt werden. Dependency-Track unterstützt die Übermittlung von CycloneDX-Dateien über Integrationen und seine API. Die Dokumentation zur CI/CD-Anbindung beschreibt unter anderem die Zuordnung über eine Projektkennung sowie alternativ über Projektname und Version.
Für die eigene Umsetzung sollte diese Zuordnung eindeutig sein. Ein Upload in das falsche Projekt kann spätere Bewertungen verfälschen. API-Zugangsdaten gehören in die dafür vorgesehene Secret-Verwaltung der CI-Plattform. Der technische Upload ist zudem nur ein Teil des Ablaufs: Das Team sollte auch erkennen können, ob die erwarteten Daten erfolgreich verarbeitet wurden.
Technische Fehler und Analyseergebnisse getrennt behandeln
Für die Pipeline sollten drei Zustände unterscheidbar sein: Die Generierung ist fehlgeschlagen, die Übergabe oder Verarbeitung ist fehlgeschlagen, oder die Verarbeitung war erfolgreich und hat Sicherheitsbefunde geliefert. Diese Fälle erfordern unterschiedliche Reaktionen und sollten in den Build-Ergebnissen getrennt erkennbar sein.
Diese Unterscheidung sollte vor dem breiten Rollout umgesetzt werden. Ein fehlgeschlagener Upload sagt nichts über die Sicherheit des Produkts aus, kann aber dazu führen, dass die Analyse auf einem veralteten Bestand beruht. Eine Pipeline sollte solche Fehler deshalb sichtbar melden.
Ob bestimmte Befunde eine Freigabe verhindern, ist eine bewusste Prozessentscheidung. Für einen Einstieg empfehlen wir nachvollziehbare Regeln, klare Zuständigkeiten und eine dokumentierte Behandlung von Ausnahmen. Pauschale Sperren ohne Bewertung können ebenso problematisch sein wie Warnungen, die niemand bearbeitet.
Die übergeordnete Frage nach Verantwortung und Zusammenarbeit behandeln wir bereits im Beitrag „Cybersicherheit ist nicht nur etwas für Tech-Giganten – KMU müssen jetzt handeln“. Die technische Aufgabe dieses Workflows ist, der zuständigen Stelle einen verlässlich zugeordneten und verarbeiteten Softwarebestand bereitzustellen.
Mit einem Release beginnen und den Ablauf vervollständigen
Ein sinnvoller Pilot umfasst ein Produkt und einen Release: SBOM erzeugen, prüfen, archivieren, übertragen und die Ergebnisse einer zuständigen Stelle zuweisen. Erst wenn dieser Ablauf zuverlässig funktioniert, sollte er auf weitere Projekte ausgeweitet werden.
Die SBOM wird damit zu einem wiederkehrenden Entwicklungsartefakt. Was mit den daraus gewonnenen Sicherheitsbefunden geschieht, erläutert der nächste Beitrag: „SBOM im Vulnerability Management: Befunde gezielt prüfen“.
Quellen und weiterführende Informationen
- Vortrag, Folie „Workflow mit CI/CD“ um Minute 28.
- Dependency-Track: Continuous Integration & Delivery.
- Dependency-Track: Best Practices.
