Software-Lieferketten sichtbar machen – mit Syft, Grype & CycloneDX

Was wir über unsere Software wirklich wissen sollten

Software wird heute selten allein gebaut. Jede Anwendung stützt sich auf Hunderte von Bibliotheken, Frameworks und Container-Images – oft aus verschiedensten Quellen. Damit entstehen Lieferketten, die ebenso komplex wie verwundbar sind.

Spätestens seit der europäischen NIS2-Richtlinie und dem geplanten Cyber Resilience Act (CRA) ist klar: Softwarehersteller und Betreiber tragen Verantwortung für ihre gesamte Lieferkette – auch für Drittkomponenten. Das bedeutet: Transparenz ist kein Bonus mehr, sondern Pflicht.

Ich wollte herausfinden, wie weit man mit freien Werkzeugen kommt, um diese Transparenz selbst herzustellen – und wie praktikabel das im Alltag wirklich ist.

Hintergrund: SBOMs, CVEs und Open-Source-Tools

Eine Software Bill of Materials (SBOM) ist im Kern eine strukturierte Liste aller Bestandteile einer Anwendung. Sie dokumentiert Herkunft, Version, Lizenz und Prüfsumme jeder Komponente – ähnlich wie eine Zutatenliste.

{
  "components": [
    { "name": "rails", "version": "7.0.8", "licenses": ["MIT"] },
    { "name": "pg", "version": "1.5.3", "licenses": ["BSD-2-Clause"] }
  ]
}

Auch Sicherheitslücken (CVEs) spielen in diesem Kontext eine zentrale Rolle. Über CVE-Datenbanken lassen sich bekannte Schwachstellen den in einer SBOM genannten Komponenten zuordnen.

Die Werkzeuge: Open Source für Supply-Chain-Transparenz

Für die folgenden Schritte habe ich ausschließlich freie Tools verwendet, die aktiv gepflegt werden und industrietauglich sind.

Praxisteil: Von der Inventarisierung bis zur Lizenzprüfung

SBOM-Erstellung mit Syft

Syft erstellt SBOMs direkt aus Container-Images oder Verzeichnissen.

git clone https://github.com/anchore/syft.git
cd syft
make build

Das Binary findet sich unter snapshot/linux-build_linux_amd64_v1/.

Beispiel:

./syft registry.example.net/v2/redmine:latest -o cyclonedx-json > redmine-sbom.json

Ausgabe:

✔ Loaded image                       registry.example.net/v2/redmine:latest
✔ Parsed image                    sha256:bfc8f1a722f068a717101e862075e565c806
✔ Cataloged contents              9ea579f7efbd873af0b37d5f2a2c2782fdbbd3e5f73
  ├── ✔ Packages                        [267 packages]
  ├── ✔ Executables                     [548 executables]
  ├── ✔ File metadata                   [6,545 locations]
  └── ✔ File digests                    [6,545 files]

Schwachstellenanalyse mit Grype

Grype ist das Pendant zu Syft – es liest SBOMs ein und gleicht sie mit CVE-Datenbanken ab.

git clone https://github.com/anchore/grype.git
cd grype
make build

Analyse:

./grype redmine-sbom.json -o table

Beispielausgabe:

SBOM Utility: Abfragen, Filtern, Dokumentieren

Mit dem SBOM Utility lassen sich SBOMs gezielt analysieren, ohne externe Datenbanken.

go install github.com/CycloneDX/sbom-utility@latest

Beispiele:

1. Komponentenübersicht

   sbom-utility query -i redmine-sbom.json --from components --select name,version
   

2. Nur bestimmte Komponenten (z. B. ruby)

   sbom-utility query -i redmine-sbom.json --from components --where name=ruby --select name,version,licenses
   

3. CSV-Export

   sbom-utility query -i redmine-sbom.json --from components --select name,version,licenses --format json -o sbom.json
   jq -r '.[] | [.name, .version, (.licenses[0].license.id // "None")] | @csv' sbom.json > sbom.csv
   

Fazit

Die Kombination aus Syft, Grype und SBOM Utility zeigt, wie weit Open Source heute in der Software-Supply-Chain-Analyse ist – und wo ihre Grenzen liegen. Diese bewusst minimalistischen Werkzeuge sind ideal, um Transparenz zu schaffen, ohne teure Plattformen oder Cloud-Abhängigkeiten. Sie machen sichtbar, was in Containern steckt – doch die eigentliche Lieferkette beginnt schon davor, bei den Frameworks, Bibliotheken und Compilern, aus denen statische Binaries entstehen.

Open Source liefert heute alle Bausteine, um die eigene Lieferkette nachvollziehbar und prüfbar zu machen. Der nächste Schritt besteht darin, diese Transparenz konsequent in den Entwicklungsprozess zu integrieren – vom Build bis zum Release. Denn nur wer weiß, woraus seine Software besteht, kann auch für ihre Sicherheit Verantwortung übernehmen.