Juni 2026
M D M D F S S
1234567
891011121314
15161718192021
22232425262728
2930  

Auf dem digital-business.blog habe ich beschrieben, warum 2026 kaum eine Software-Firma mehr ohne SBOM auskommt. Die logische Anschlussfrage ist: Wie erzeugt man so eine Software-Stückliste eigentlich, ohne sich ein teures Tool ins Haus zu holen? Hier zeige ich den schlanken Weg mit zwei freien Werkzeugen: Syft erzeugt die SBOM, Grype scannt sie gegen bekannte Schwachstellen.

Was wir bauen

Das Ziel: aus einem Container-Image oder einem Projektverzeichnis eine maschinenlesbare Stückliste erzeugen, sie in einem Standardformat ablegen und automatisch prüfen, ob darin verwundbare Komponenten stecken. Beide Tools kommen von Anchore, sind quelloffen und laufen lokal wie in der Pipeline.

Syft installieren und SBOM erzeugen

Installation unter Linux oder macOS in einer Zeile:

curl -sSfL https://get.anchore.io/syft | sh -s -- -b /usr/local/bin

Eine SBOM aus einem Image im CycloneDX-JSON-Format erzeugen:

syft myimage:latest -o cyclonedx-json=sbom.json

Statt eines Images geht auch ein lokales Verzeichnis, zum Beispiel das Projekt selbst:

syft dir:. -o spdx-json=sbom.spdx.json

CycloneDX oder SPDX?

Beides sind etablierte Standardformate. CycloneDX kommt aus dem OWASP-Umfeld und ist im Security-Kontext weit verbreitet. SPDX stammt von der Linux Foundation und ist im Lizenz- und Compliance-Bereich stark. Wenn ein Kunde kein Format vorgibt, nehme ich CycloneDX-JSON, weil die meisten Scanner und Plattformen es direkt verstehen.

Grype: die SBOM gegen Schwachstellen scannen

Grype installieren:

curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin

Jetzt das Entscheidende: Grype scannt nicht nur Images direkt, sondern auch die eben erzeugte SBOM. Das ist schnell und reproduzierbar, weil die Stückliste schon feststeht.

grype sbom:sbom.json

Damit ein Build bei kritischen Funden auch wirklich abbricht, setzt man eine Schwelle:

grype sbom:sbom.json --fail-on high

In die CI/CD-Pipeline

Der eigentliche Wert entsteht erst, wenn das bei jedem Build automatisch passiert. In GitHub Actions gibt es dafür fertige Actions von Anchore:

- name: SBOM erzeugen
uses: anchore/sbom-action@v0
with:
image: myimage:latest
format: cyclonedx-json
output-file: sbom.json
- name: SBOM scannen
uses: anchore/scan-action@v6
with:
sbom: sbom.json
fail-build: true
severity-cutoff: high

Ab jetzt entsteht die Stückliste bei jedem Build, wird als Artefakt abgelegt und gegen die aktuelle Schwachstellen-Datenbank geprüft. Genau das ist der Unterschied zwischen einer SBOM, die nur existiert, und einer, die tatsächlich schützt.

Fazit

Mit Syft und Grype hast du in einer halben Stunde eine funktionierende SBOM-Pipeline, ohne Lizenzkosten. Der schwierige Teil ist nicht das Erzeugen, sondern es sauber in den Build-Prozess zu verdrahten und die Funde auch zu bearbeiten. Wer das einmal richtig aufsetzt, spart sich im nächsten Log4Shell-Moment die Panik. Mehr zum Warum dahinter steht drüben auf digital-business.blog.

Hinterlasse einen Kommentar

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden..