Continuous Transparency mit SBOM und CI/CD

11.11.2025 08:00

von Tobias Kraft

Eine erstellte Software durchläuft einen Lebenszyklus, während dessen sie in der Regel stetigen Anpassungen unterliegt. Diese Änderungen können neue Features, das Schließen von Sicherheitslücken, Bugfixes innerhalb der Anwendung oder auch Aktualisierungen von Abhängigkeiten umfassen.

Damit verliert eine ursprünglich erstellte SBOM (Software Bill of Materials) mit der Zeit ihre Aktualität und muss entsprechend angepasst werden. Eine manuelle Pflege ist aufwändig und fehleranfällig – Abhängigkeiten können hierbei leicht übersehen und werden somit nicht erfasst.

Neben der kontinuierlichen Überprüfung bestehender SBOM-Dateien auf neue Sicherheitslücken, wie im Artikel Steuerung und Überwachung von Software mit einem SBOM-Management-System vorgestellt, ist auch die fortlaufende Erstellung aktueller SBOMs bei Änderungen in der Software von zentraler Bedeutung. Dieser Artikel zeigt, wie sich der gesamte Prozess – von der Erstellung bis zur Überprüfung – automatisieren lässt.

SBOM Erstellung ohne Handarbeit

Für viele Programmiersprachen und Frameworks gibt es mittlerweile Erweiterungen, die eine automatische Generierung von SBOMs direkt im Projektkontext ermöglichen. Damit entfällt die manuelle Pflege weitgehend – ein klarer Vorteil, der in CI/CD-Pipelines genutzt werden kann.

Als einfaches Beispiel kann JavaScript zur Illustration herangezogen werden. Wird Node.js mit npm genutzt, steht das Paket CycloneDX SBOM for npm bereit.
Es wird idealerweise als dev-Abhängigkeit installiert:

npm install --save-dev @cyclonedx/cyclonedx-npm@4.0.2

Mit einem einzigen Befehl lässt sich die SBOM-Datei erzeugen:

npx cyclonedx-npm --gather-license-texts --output-file sbom-webapp.cdx.json

Auch für Java-Anwendungen, die Gradle als Build-Werkzeug einsetzen, gibt es eine vergleichbar einfache Lösung. In der Datei build.gradle wird lediglich das passende Plugin angezogen:

plugins {
    id 'org.cyclonedx.bom' version '3.0.1'
}

Danach reicht folgender Befehl, um die SBOM-Datei zu erzeugen:

./gradlew cyclonedxBom

Beide Beispiele zeigen: Mit einem einzigen Kommando lässt sich die SBOM-Erstellung vollautomatisch in jede CI/CD-Pipeline integrieren. Die Tools analysieren alle Abhängigkeiten – inklusive transitive (Kind-)Bibliotheken – und erzeugen daraus die vollständige SBOM-Datei. Diese kann anschließend in der Pipeline weiterverarbeitet werden, etwa durch den Upload in Dependency-Track oder die Auswertung mit einem Vulnerability-Scanner.

Die gezeigten Anwendungsfälle zeigen exemplarisch existierende Möglichkeiten. Für andere Programmiersprachen stehen ähnliche Werkzeuge zur Verfügung. Existiert keine direkte Unterstützung innerhalb des Projekts, helfen universelle Werkzeuge wie Trivy oder Syft weiter. Diese Tools betrachten die Software „von außen“: Sie analysieren Quellcode, Container-Images oder Projektverzeichnisse und erstellen daraus eine SBOM. Mit diesen Werkzeugen können auch ältere JavaScript-Anwendungen untersucht werden, die keine Node.js-Laufzeitumgebung verwenden und Bibliotheken entweder lokal im Dateisystem ablegen oder über CDN-Links im Quelltext einbinden.

SBOM in Dependency-Track über CI/CD bereitstellen

Dependency-Track bietet für alle Funktionen eine REST-API an. Darüber lassen sich auch SBOM-Dateien hochladen – ideal für den Einsatz in einer CI/CD-Pipeline. Mit einem passenden API-Key kann der Upload einfach automatisiert werden. Das folgende Beispiel zeigt den Schritt einer GitLab-Pipeline, der ein curl-Image für den Upload nutzt.

upload-sbom:
  stage: release
  image: curlimages/curl:8.16.0
  script:
    # upload for project worldweb
    - |
      curl -f -v POST "${DTRACK_URL}/api/v1/bom" -H "X-Api-Key: ${DTRACK_API_KEY}" \
      -F "projectName=worldweb" \
      -F "parentName=customer-x" \
      -F "projectVersion=${RELEASE_TAG}" \
      -F "autoCreate=true" \
      -F "bom=@${TRIVY_REPORT_DIR}/sbom-worldweb.cdx.json"
  dependencies:
    - scanning-vulnerabilities
  needs:
    - job: release
    - job: scanning-vulnerabilities

Damit Dependency-Track die SBOM-Datei richtig zuordnet, wird ein Projektname benötigt. Das Attribut Projekt-Version eignet sich, um beispielsweise verschiedene Releases zu unterscheiden. Besonders praktisch ist das Attribut autoCreate: Ist das Projekt noch nicht vorhanden, legt Dependency-Track es automatisch an. Damit entfällt manuelle Konfigurations-Arbeit komplett.

Bei einem automatisierten Prozess kommt unweigerlich die Frage auf, wann und wie oft SBOM-Dateien bereitgestellt werden. In den meisten Software-Projekten wird eine CI/CD Pipeline über einen Commit angestoßen, damit könnte jedes Mal eine neue SBOM-Datei erstellt und analysiert werden. Dies ist jedoch nicht die gängige Empfehlung. Der Vorteil ist zwar, eine frühe Transparenz zur Erkennung neuer Schwachstellen und die Aktualität. Allerdings bedingt dies auch einen höheren Datenverkehr, die Pipeline läuft länger und Dependency-Track wird stärker belastet.

Wird ein SBOM nur für jedes Release erzeugt, entsteht ein klarer Lifecycle-Bezug: Jede SBOM-Version gehört eindeutig zu einem Release-Artefakt. Das verbessert Nachvollziehbarkeit und Audit-Fähigkeit. Eine Bereitstellung pro Release ist zudem im Hinblick auf künftige gesetzliche Anforderungen empfehlenswert. Wer trotzdem frühzeitig Hinweise auf potenzielle Probleme möchte, kann beispielsweise zusätzlich bei jedem Merge in den Hauptbranch eine SBOM bereitstellen.

Die folgende Visualisierung einer GitLab Pipeline zeigt die SBOM-Bereitstellung beim Durchlaufen des Releases-Prozesses. Der Release Prozess wird nach einem erfolgreichen Build und Test durch den Benutzer angestoßen. Beim Erstellen des Docker-Images erzeugt der Schritt docker-build-release zunächst die SBOM-Datei mit Trivy. Im letzten Schritt upload-sbom wird die SBOM-Datei nach Dependency-Track geschoben und erhält als Version den Release-Tag, der im Schritt zuvor erzeugt wurde.

Keine halben Sachen bei der SBOM Bereitstellung

Werden SBOM-Dateien für ein Softwareprodukt bereitgestellt, sollte darauf geachtet werden, dass alle Abhängigkeiten vollständig beschrieben sind. Softwareprodukte nutzen häufig verschiedene Technologien und Frameworks. Eine Webanwendung verwendet beispielsweise JavaScript im Frontend, greift aber auf ein Backend zu, das mit Java implementiert ist.

Sind hier die oben vorgestellten Werkzeuge zur SBOM-Erstellung im Einsatz, entstehen zwei separate Dateien. Nach außen soll ein Softwareprodukt jedoch als eine Einheit dargestellt werden. Wie lässt sich dies erreichen?

Das Werkzeug CycloneDX CLI bietet hierfür eine Option zum Zusammenführen mehrerer SBOM-Dateien an. Dies lässt sich – wie im folgenden Beispiel gezeigt – mit geringem Aufwand durch Ausführen eines Docker-Images in eine CI/CD-Pipeline integrieren:

- cp sbom-trivy.cdx.json ./cdx/
- cp sbom-javascript.cdx.xml ./cdx/
- docker run --rm -v ./cdx:/data cyclonedx/cyclonedx-cli merge \
    --input-files /data/sbom-trivy.cdx.json /data/sbom-javascript.cdx.xml \
    --output-file /data/sbom.cdx.json

Die bereits erwähnten Tools Trivy und Syft analysieren auf mehreren Ebenen und können auch komplette Docker-Images untersuchen. Abhängig von der jeweiligen Parametrierung werden dabei sowohl die Docker-Abhängigkeiten als auch sämtliche in das Image integrierte Softwarekomponenten berücksichtigt.

Bei der Generierung von SBOM-Dateien sollte zudem klar sein, welche Abhängigkeiten aufgenommen werden. SBOMs, die nach außen veröffentlicht werden, enthalten in der Regel nur die produktiven Abhängigkeiten – also diejenigen, die auch tatsächlich im Betrieb vorhanden sind. Es kann jedoch sinnvoll sein, zusätzlich Test- und Entwicklungsabhängigkeiten, gegebenenfalls in separaten Dateien, mit einzubeziehen. So können beispielsweise Entwickler frühzeitig auf veraltete Testbibliotheken aufmerksam gemacht werden.

Automatisierte SBOMs – mehr als nur ein Compliance-Thema

Eine automatisierte SBOM-Erstellung und -Bereitstellung ist kein Selbstzweck, sondern ein wichtiger Schritt zu mehr Transparenz und Sicherheit in modernen Software-Lieferketten. Wer den Prozess konsequent in seine CI/CD-Pipeline integriert, reduziert manuelle Fehlerquellen, spart Zeit und stellt sicher, dass jede veröffentlichte Version nachvollziehbar dokumentiert ist.
So wird aus einer einmaligen Sicherheitsmaßnahme ein kontinuierlicher Bestandteil des Entwicklungszyklus – Continuous Transparency in der Praxis.

Weitere Blogposts zum Thema SBOM / Software-Stückliste:

Zurück