SBOM mit Syft erstellen: Das Werkzeugpaar verändert spätere Funde

Syft erzeugt eine SBOM aus einem Container-Image oder Dateisystem. Für einen Release-Job wählen Sie das tatsächlich ausgelieferte Image, exportieren CycloneDX und SPDX und prüfen die Dateien vor dem Schwachstellenscan mit Grype. Der Scan wertet die Komponenten und Kennungen aus, die im jeweiligen Export stehen; deshalb kann dieselbe Image-Basis je nach Generator und Scanner unterschiedliche Funde liefern.

Für einen reproduzierbaren CI-Lauf halten Sie Image-Digest, Plattform, Werkzeugversionen und den Stand der Grype-Datenbank fest. Eine lesbare Komponentenliste erfüllt noch nicht automatisch ein regulatorisches Profil und ist auch kein Schwachstellenbericht. Export, Qualitätsprüfung und Scan gehören daher in getrennte Schritte.

Den Release-Inhalt als Eingabe fixieren

Setzen Sie die CI-Variable IMAGE auf die Registry-Referenz des fertigen Images mit SHA-256-Digest. Ein veränderlicher Tag kann bei einem späteren Lauf auf andere Inhalte zeigen. Bei einem Image für mehrere Plattformen notieren Sie zusätzlich die ausgewählte Plattform und sorgen dafür, dass Syft und ein möglicher Vergleichsgenerator dieselbe Variante erfassen.

Ein Scan des Projektverzeichnisses erfasst einen anderen Gegenstand: Dort können Build-Dateien und Abhängigkeiten liegen, die das fertige Image nicht enthält. Für die Release-SBOM zählt der ausgelieferte Zustand; eine eigene SBOM des Quellstands kann ergänzend sinnvoll sein. Wie beide Dateien einem Release zugeordnet werden, gehört zum Arbeitsablauf rund um die SBOM.

Aus einem Syft-Lauf beide Formate erzeugen

Die Syft-Formatdokumentation erlaubt mehrere Ausgaben mit wiederholtem -o und eine Formatversion hinter @. Für ein festgelegtes IMAGE lautet der Export: syft "$IMAGE" -o [email protected]=sbom.cdx.json -o [email protected]=sbom.spdx.json -o json=sbom.syft.json. Die native JSON-Datei enthält zusätzliche Syft-Daten; CycloneDX und SPDX dienen dem Austausch mit nachgelagerten Werkzeugen.

Die Schreibweise @3.0 bezeichnet hier eine Syft-Ausgabeoption. Sie garantiert allein nicht, dass die erzeugte Datei die für ein bestimmtes Profil benötigte SPDX-Spezifikationsversion deklariert. Bewahren Sie alle drei Ausgaben zusammen mit der Syft-Version auf: Wenn ein späterer Scan abweicht, lässt sich prüfen, ob sich bereits die Inventardaten oder erst deren Übertragung in ein Standardformat unterscheiden.

Syntax, Schema und Pflichtfelder einzeln prüfen

Beginnen Sie mit jq -e . sbom.cdx.json und jq -e . sbom.spdx.json. Das prüft die JSON-Syntax, aber weder die Dokumentstruktur noch die Vollständigkeit der Angaben. Für den CycloneDX-Export kann ein CI-Job cyclonedx-cli validate --input-file sbom.cdx.json --input-format json --input-version v1_6 --fail-on-errors ausführen; der Versionsparameter muss zur erzeugten Datei passen.

Die BSI-Zuordnung von sbomqs nennt für TR-03183-2 v2.1.0 mindestens CycloneDX 1.6 oder SPDX 3.0.1 und ordnet unter anderem Ersteller mit Kontaktmöglichkeit, Zeitstempel, SBOM-URI, Komponentennamen, Versionen und Abhängigkeitsbeziehungen konkreten Feldern zu. Der SPDX-Export muss die geforderte Version tatsächlich deklarieren; ein erfolgreicher Syft-Lauf ist dafür kein Ersatz. Fehlende Angaben müssen aus verlässlichen Build- oder Produktdaten ergänzt werden.

Für eine als SPDX 3.0.1 ausgewiesene Datei kann der Job beispielsweise check-jsonschema --schemafile schemas/spdx-3.0.1.json sbom.spdx.json verwenden, wenn dort eine festgelegte Kopie des passenden Schemas liegt. Eine Datei, die nur SPDX 3.0 deklariert, wird durch Umbenennen nicht zu einer 3.0.1-Datei. Auch ein erfolgreicher Schematest beantwortet noch nicht, ob alle verlangten Produkt- und Komponentenangaben vorhanden sind.

Erzeugen Sie deshalb für jede Datei einen eigenen Profilbericht mit sbomqs compliance --bsi-v2 DATEI --json --output BERICHT; ersetzen Sie die Platzhalter durch die jeweiligen Dateinamen. Prüfen Sie die fehlenden Pflichtfelder im Bericht und lassen Sie die Freigabe gegebenenfalls scheitern. Das Profil hält Schwachstelleninformationen von der SBOM getrennt: Der Grype-Bericht bleibt ein eigenes CI-Artefakt.

Grype-Funde auf denselben Artefaktstand beziehen

Scannen Sie zunächst die geprüfte CycloneDX-Datei mit grype sbom:sbom.cdx.json -o json --file grype-cdx.json. Für einen Formatvergleich können Sie zusätzlich grype sbom:sbom.spdx.json -o json --file grype-spdx.json ausführen. Das Präfix sbom: legt den Eingabetyp fest. Falls Grype eine Datei nicht einliest, dokumentieren Sie den Format- oder Versionsfehler und behandeln den Lauf nicht als Scan ohne Funde.

Ein Gastbeitrag bei TechRadar Pro beschreibt bei derselben Container-Image-Basis einen Unterschied von 66 Prozent in Grype-Funden zwischen einer Syft- und einer Trivy-SBOM. Der Beitrag führt die Abweichung auf einen Upstream-Qualifikator in Package URLs zurück, den Syft mitliefert und Trivy in der untersuchten Konstellation auslässt. Das Ergebnis gilt für diese Generator-Scanner-Kombination; es ist keine allgemeine Erkennungsquote der Werkzeuge.

Für einen eigenen Vergleich erzeugen Sie zusätzlich trivy image --format cyclonedx --output sbom.trivy.cdx.json "$IMAGE" und scannen auch diese Datei mit Grype. Halten Sie Image, Plattform, Scanzeitpunkt und Datenbankstand gleich; ändern Sie zunächst nur den Generator. Vergleichen Sie bei abweichenden Treffern Paketnamen, Versionen und Package URLs. So lässt sich eine fehlende Komponente von einer anders beschriebenen Paketidentität unterscheiden, bevor Sie die Anzahl der gemeldeten Schwachstellen bewerten.

Die CI-Ausgaben gemeinsam aufbewahren

Im Job folgt auf die Auswahl des Image-Digests der Syft-Export, darauf Syntax- und Schema-Prüfung, der Profilbericht und schließlich der Grype-Scan. Lassen Sie die Pipeline bei ungültigen Dateien oder fehlenden Pflichtfeldern für die gewählte Freigabe scheitern. Für Schwachstellen legen Sie eine separate Freigaberegel fest, weil eine niedrige Trefferzahl auch aus fehlenden Paketinformationen entstehen kann.

Archivieren Sie die SBOM-Dateien, Prüfberichte und Scanergebnisse mit Image-Digest, Plattform, Generator- und Scanner-Version sowie dem Stand der Schwachstellendatenbank. Wenn bei gleichem Image später neue Funde auftreten, lässt sich anhand dieser Angaben feststellen, ob das Inventar, die Paketkennung, die Scanner-Version oder die Datenbasis gewechselt hat. Bei wiederholten Release-Builds verhindert diese Zuordnung, dass ein Unterschied zwischen Berichten vorschnell als Änderung am Produkt gilt.

Lesen Sie auch:

• Eine SBOM erstellen: Die Stückliste hilft erst mit einem Arbeitsablauf
• Otter oder Fireflies: Deutsche Meetings verändern die Rechnung
• Jenseits des Neptun fehlen kleine Welten – 27 Funde erzählen die Vorgeschichte