{"id":11536,"date":"2026-10-27T14:40:00","date_gmt":"2026-10-27T13:40:00","guid":{"rendered":"https:\/\/erminas.com\/?p=11536"},"modified":"2026-10-14T14:53:18","modified_gmt":"2026-10-14T12:53:18","slug":"sbom-in-ci-cd-integrieren-workflow-fuer-entwicklungsteams","status":"publish","type":"post","link":"https:\/\/erminas.com\/de\/blog\/sbom-in-ci-cd-integrieren-workflow-fuer-entwicklungsteams\/","title":{"rendered":"SBOM in CI\/CD integrieren: Workflow f\u00fcr Entwicklungsteams"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Eine SBOM kann beim ersten Versuch schnell entstehen. Schwieriger ist die Frage, ob sie auch beim n\u00e4chsten Release noch stimmt. Neue Pakete, aktualisierte Bibliotheken und ver\u00e4nderte Build-Konfigurationen \u00e4ndern den Softwarebestand. Eine manuell gepflegte Datei verliert dabei leicht den Bezug zur tats\u00e4chlichen Anwendung.<\/p>

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\u00fcr einen Workflow von der .NET-Anwendung \u00fcber Azure DevOps bis zu Dependency-Track vor. Die lokale Live-Demo zeigt die Generierung und die anschlie\u00dfenden Analyseansichten; sie dient als anschauliches Beispiel f\u00fcr die einzelnen Bausteine.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Die SBOM an einen konkreten Softwarestand binden<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Bevor ein zus\u00e4tzlicher Pipeline-Schritt eingerichtet wird, sollte das Team festlegen, welchen Stand die SBOM beschreibt. Ein Entwicklungsbuild und eine freigegebene Produktversion haben unterschiedliche Zwecke. F\u00fcr sp\u00e4tere R\u00fcckfragen muss erkennbar sein, welche SBOM zu welchem Release geh\u00f6rt.<\/p>

Als Umsetzung empfehlen wir, Produktversion und Build-Kennung zusammen mit der SBOM zu archivieren. So l\u00e4sst sich sp\u00e4ter nachvollziehen, ob eine Sicherheitsmeldung einen ausgelieferten Stand betrifft. Eine einzige Datei mit dem Namen \u201eaktuelle SBOM\u201c w\u00e4re daf\u00fcr unzureichend: Sie beantwortet keine Fragen zu \u00e4lteren Versionen, die bei Kunden weiterhin im Einsatz sind.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

SBOM in CI\/CD integrieren: Generierung und Pr\u00fcfung automatisieren<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

F\u00fcr ein Pilotprojekt kann ein Team zun\u00e4chst den lokal erprobten Generator in seiner Build-Umgebung ausf\u00fchren. Anschlie\u00dfend sollte gepr\u00fcft 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 \u00fcbergeben.<\/p>

Der genaue Zeitpunkt h\u00e4ngt vom untersuchten Gegenstand ab. F\u00fcr eine Projektanalyse m\u00fcssen die ben\u00f6tigten Abh\u00e4ngigkeitsinformationen verf\u00fcgbar 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\u00e4ter aussagen soll.<\/p>

Es lohnt sich au\u00dferdem, Generatorversion und Konfiguration kontrolliert zu \u00e4ndern. Eine unerwartet stark ver\u00e4nderte Komponentenliste sollte Anlass f\u00fcr eine Untersuchung sein. So wird die Pipeline nicht nur zum Dateierzeuger, sondern unterst\u00fctzt auch die Qualit\u00e4t der Informationen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Die Daten an Dependency-Track \u00fcbergeben\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Nach der Erzeugung m\u00fcssen die Daten dort ankommen, wo sie genutzt werden. Dependency-Track unterst\u00fctzt die \u00dcbermittlung von CycloneDX-Dateien \u00fcber Integrationen und seine API. Die Dokumentation zur CI\/CD-Anbindung<\/a> beschreibt unter anderem die Zuordnung \u00fcber eine Projektkennung sowie alternativ \u00fcber Projektname und Version.<\/p>\n\n

F\u00fcr die eigene Umsetzung sollte diese Zuordnung eindeutig sein. Ein Upload in das falsche Projekt kann sp\u00e4tere Bewertungen verf\u00e4lschen. API-Zugangsdaten geh\u00f6ren in die daf\u00fcr vorgesehene Secret-Verwaltung der CI-Plattform. Der technische Upload ist zudem nur ein Teil des Ablaufs: Das Team sollte auch erkennen k\u00f6nnen, ob die erwarteten Daten erfolgreich verarbeitet wurden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Technische Fehler und Analyseergebnisse getrennt behandeln\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

F\u00fcr die Pipeline sollten drei Zust\u00e4nde unterscheidbar sein: Die Generierung ist fehlgeschlagen, die \u00dcbergabe oder Verarbeitung ist fehlgeschlagen, oder die Verarbeitung war erfolgreich und hat Sicherheitsbefunde geliefert. Diese F\u00e4lle erfordern unterschiedliche Reaktionen und sollten in den Build-Ergebnissen getrennt erkennbar sein.<\/p>\n\n

Diese Unterscheidung sollte vor dem breiten Rollout umgesetzt werden. Ein fehlgeschlagener Upload sagt nichts \u00fcber die Sicherheit des Produkts aus, kann aber dazu f\u00fchren, dass die Analyse auf einem veralteten Bestand beruht. Eine Pipeline sollte solche Fehler deshalb sichtbar melden.<\/p>\n\n

Ob bestimmte Befunde eine Freigabe verhindern, ist eine bewusste Prozessentscheidung. F\u00fcr einen Einstieg empfehlen wir nachvollziehbare Regeln, klare Zust\u00e4ndigkeiten und eine dokumentierte Behandlung von Ausnahmen. Pauschale Sperren ohne Bewertung k\u00f6nnen ebenso problematisch sein wie Warnungen, die niemand bearbeitet.<\/p>\n\n

Die \u00fcbergeordnete Frage nach Verantwortung und Zusammenarbeit behandeln wir bereits im Beitrag \u201eCybersicherheit ist nicht nur etwas f\u00fcr Tech-Giganten \u2013 KMU m\u00fcssen jetzt handeln\u201c<\/a>. Die technische Aufgabe dieses Workflows ist, der zust\u00e4ndigen Stelle einen verl\u00e4sslich zugeordneten und verarbeiteten Softwarebestand bereitzustellen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Mit einem Release beginnen und den Ablauf vervollst\u00e4ndigen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein sinnvoller Pilot umfasst ein Produkt und einen Release: SBOM erzeugen, pr\u00fcfen, archivieren, \u00fcbertragen und die Ergebnisse einer zust\u00e4ndigen Stelle zuweisen. Erst wenn dieser Ablauf zuverl\u00e4ssig funktioniert, sollte er auf weitere Projekte ausgeweitet werden.<\/p>

Die SBOM wird damit zu einem wiederkehrenden Entwicklungsartefakt. Was mit den daraus gewonnenen Sicherheitsbefunden geschieht, erl\u00e4utert der n\u00e4chste Beitrag: \u201eSBOM im Vulnerability Management:\u00a0 Befunde gezielt pr\u00fcfen\u201c<\/strong>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Quellen und weiterf\u00fchrende Informationen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t