Was Open-Source-SBOM-Generatoren übersehen

So erzeugen Sie eine SBOM mit jedem Tool

Bei jedem Tool genügt ein Befehl für ein Quellverzeichnis oder ein Container-Image, mit Ausgabe als CycloneDX oder SPDX:

# Syft: a source directory or a container image
syft ./my-project -o cyclonedx-json=sbom.cdx.json
syft my-image:latest -o spdx-json=sbom.spdx.json

# Trivy: a filesystem or a container image
trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output sbom.spdx.json my-image:latest

# cdxgen: the current directory, optionally with a project type
cdxgen -o bom.json .
cdxgen -t js -o bom.json .

Die Befehle sind der einfache Teil. Was in der Datei landet, hängt davon ab, was jedes Tool liest, und sie lesen nicht dasselbe.

Was jedes Tool liest

Tool	Quellverzeichnis	Container-Image	Wissenswert
Syft	Ein Standardsatz an Catalogers für Verzeichnisse, der deklarierte Abhängigkeiten liest	Ein Standardsatz an Catalogers für Images, der installierte Pakete liest	Catalogers werden nach Scan-Typ ausgewählt. syft cataloger list zeigt, welche laufen, und --select-catalogers fügt welche hinzu oder entfernt sie.
Trivy	Lockfiles, bei Node.js package-lock.json, yarn.lock, pnpm-lock.yaml und bun.lock	Bei Node.js package.json-Dateien unter node_modules	Lässt Entwicklungsabhängigkeiten weg, sofern Sie nicht --include-dev-deps angeben.
cdxgen	Zuerst Lockfiles, die Entwicklungsabhängigkeiten enthalten; bei Node.js analysiert es außerdem den Code auf Imports	Unterstützt	Legen Sie mit -t den Projekttyp fest, um einzugrenzen, wonach es sucht.

Warum sie beim selben Repository abweichen

Richten Sie alle drei auf denselben Commit, und Sie erhalten drei verschiedene Listen. Keines ist defekt. Jedes folgt seinen eigenen dokumentierten Regeln:

• Kein Lockfile, keine Abhängigkeiten. Express 5.2.1 committet kein Lockfile. Bei einem frischen Checkout hat ein Tool, das Abhängigkeiten aus Lockfiles oder installierten Paketen auflöst, weder das eine noch das andere, sodass die in package.json deklarierten npm-Abhängigkeiten nie in die SBOM gelangen. Es schreibt trotzdem ein gültiges Dokument mit allem, was es sonst erkannt hat.
• Installiert oder deklariert. Ob Sie vor dem Scan eine Installation ausgeführt haben, kann mehr ausmachen als die Wahl des Tools. Bei einer installierten Kopie desselben Repositorys entscheidet eine einzige Cataloger-Einstellung von Syft, ob die installierten npm-Pakete überhaupt erscheinen.
• Entwicklungsabhängigkeiten. Trivy lässt sie standardmäßig weg und cdxgen nimmt sie auf, sodass dasselbe Lockfile zwei Antworten auf die Frage „Was steckt in diesem Projekt?“ gibt.
• Benennung und Versionen. Tools identifizieren manche Komponenten unter verschiedenen Package-URL-Typen oder pinnen eine GitHub Action auf einen Commit-SHA, wo ein anderes einen Tag meldet. Eine Schwachstellensuche mit der falschen Kennung liefert selbstsicher eine falsche Antwort.
• Gar kein Manifest. Das Repository anthropics/claude-code hat kein Abhängigkeitsmanifest, und sein npm-Paket umschließt eine vorgefertigte Binärdatei. Was jedes Tool zurückgibt, sagt mehr über das Tool als über das Projekt.

Was alle übersehen: versteckte Abhängigkeiten

Die tiefere Grenze teilen sie alle. Ein Scanner liest das Lockfile oder das Build-Ergebnis und leitet daraus nachträglich ab, was eingeflossen ist. Was der Build außerhalb dieser Dateien geladen hat, gelangt nie in die SBOM. Das sind die versteckten Abhängigkeiten:

• Install-Hooks. npm-Skripte wie preinstall und postinstall laufen während der Installation und können weiteren Code herunterladen. So lief der Shai-Hulud-Wurm.
• Build-Skripte, etwa Rust-Build-Skripte, die zur Build-Zeit herunterladen, was sie brauchen.
• Basis-Images und ihre Betriebssystem-Schichten in einem Container-Build, die kein Sprach-Lockfile auflistet.
• Aus CI-Caches wiederhergestellte Pakete, die möglicherweise nicht zum aktuellen Lockfile passen. Siehe was der GitHub-Actions-Cache verbirgt.
• Build-Tools, die von Setup-Schritten installiert werden, mit ihren eigenen Abhängigkeitsbäumen.
• Transitive Versionen, die zur Build-Zeit aufgelöst werden, wenn das Lockfile fehlt, veraltet ist oder von keiner Frozen-Installation verwendet wird. Siehe transitive Abhängigkeiten.

Das Ergebnis nachträglich zu scannen schließt die Lücke nicht. Bei einer fertigen Binärdatei, besonders bei kompiliertem Code wie Rust, muss der Scanner raten, was eingeflossen ist. Kommerzielle SCA-Scanner arbeiten mit denselben Dateiarten und haben dieselben blinden Flecken. CRACI hat verwundbare Pakete gefunden, die Snyk und Aikido nicht gemeldet haben, weil die Komponenten nie in dem enthalten waren, was sie gescannt haben.

Auch die Tools gehören zu Ihrer Lieferkette

Ein Scanner läuft in Ihrem CI mit Zugriff auf Ihren Code und oft auf Ihre Secrets. Im März 2026 beschrieb das Advisory von Aqua Security (CVE-2026-33634) ein bösartiges Trivy-Release v0.69.4 und vergiftete Tags von trivy-action und setup-trivy, die Zugangsdaten von CI-Runnern stahlen. Pinnen Sie Scanner-Actions auf vollständige Commit-SHAs und prüfen Sie im Advisory die Versionen, die Sie nutzen.

So prüfen Sie Ihre eigene SBOM

1. Führen Sie zwei Generatoren auf demselben Commit aus und vergleichen Sie die gemeldeten Package-URLs.
2. Prüfen Sie, ob das Repository ein Lockfile committet und ob CI daraus mit einer Frozen-Installation installiert.
3. Scannen Sie sowohl nach dem Installationsschritt als auch davor, und vergleichen Sie.
4. Vergleichen Sie die Liste mit dem, was laut Build-Log heruntergeladen wird, einschließlich Setup-Schritten und Cache-Wiederherstellungen.

Weichen die Listen ab, hängt die von Ihnen veröffentlichte SBOM davon ab, welches Tool Sie zufällig ausgeführt haben, nicht davon, was Sie ausgeliefert haben.

Zeichnen Sie stattdessen den Build auf

CRACI sieht den Datenverkehr, Scanner nicht. Es ist ein GitHub-Actions-Runner, der den Netzwerkverkehr sieht, der in jeden Build hineinkommt. Seine SBOM zeichnet daher jedes Paket auf, das der Job geladen hat, auf jeder Ebene des Baums, einschließlich versteckter Abhängigkeiten und aus CI-Caches wiederhergestellter Pakete. Es gibt kein Verzeichnis, auf das Sie zeigen, und keinen Cataloger, den Sie wählen müssen. Konnte eine Aufzeichnung nicht alles sehen, etwa weil ein Job nicht überwachten Datenverkehr erlaubt hat, gibt die SBOM das mit ihrem Vollständigkeitsstatus an.

Die Aufzeichnung ist auch deshalb wichtig, weil Builds selten reproduzierbar sind. Bauen Sie denselben Commit zweimal direkt hintereinander, kann der Paketmanager in anderer Reihenfolge auflösen und installieren, sodass der zweite Build andere Pakete enthalten kann. Nur die SBOM, die während des Builds aufgezeichnet wurde, der ein Release erzeugt hat, belegt, was dieses Release enthält.

Behalten Sie Syft oder Trivy für Images und Binärdateien von Dritten, die Sie nicht selbst gebaut haben. Für Ihre eigenen Releases lesen Sie SBOMs zur Build-Zeit oder buchen Sie eine Demo, um an einem Ihrer Repositories eine aufgezeichnete SBOM mit der Ihres aktuellen Tools zu vergleichen.

Open-Source-SBOM-Generatoren: häufig gestellte Fragen

Was ist besser für SBOMs, Syft oder Trivy?

Sie sind für unterschiedliche Aufgaben gebaut. Syft ist ein spezialisierter SBOM-Generator mit vielen Catalogers und signierten Attestierungen; Trivy ist ein Sicherheitsscanner, der SBOMs als eine seiner Ausgaben schreibt. Beide lesen die Dateien, die ihnen vorliegen. Beim selben Repository liegt der größere Unterschied daher meist darin, ob ein Lockfile committet ist und ob die Abhängigkeiten vor dem Scan installiert wurden.

Warum zeigt meine SBOM keine Abhängigkeiten?

Meist, weil das Repository kein Lockfile committet und vor dem Scan nichts installiert wurde. Ein Generator, der Lockfiles oder installierte Pakete liest, hat dann nichts zu lesen und schreibt trotzdem eine gültige SBOM. Committen Sie das Lockfile oder scannen Sie nach dem Installationsschritt.

Nimmt Trivy Entwicklungsabhängigkeiten in die SBOM auf?

Standardmäßig nicht. Laut der Node.js-Dokumentation von Trivy meldet es Entwicklungsabhängigkeiten nur, wenn Sie --include-dev-deps angeben. cdxgen dagegen wertet Lockfiles aus und nimmt Entwicklungsabhängigkeiten auf. Schon allein deshalb können zwei Tools beim selben Projekt abweichen.

Kann ich einer SBOM aus einem Open-Source-Generator vertrauen?

Für das, was er gelesen hat, ja. Die Frage ist, was er nicht gelesen hat: Caches, Build-Tools, Downloads, Install-Skripte und Binärdateien ohne Paketmetadaten. Betrachten Sie eine gescannte SBOM als Beschreibung der Dateien, auf die Sie das Tool gerichtet haben, nicht des Builds, der Ihr Release erzeugt hat.

Was ist das beste SBOM-Tool?

Für Software, die Sie selbst bauen, entsteht die vollständigste SBOM, wenn Sie den Build aufzeichnen, statt Dateien zu scannen. CRACI zeichnet jedes Paket auf, das jeder GitHub-Actions-Job lädt, auch aus Caches, und hat verwundbare Pakete gefunden, die Snyk und Aikido nicht gemeldet haben. Für Images und Binärdateien von Dritten, die Sie nicht selbst gebaut haben, ist ein Scanner wie Syft oder Trivy weiterhin die praktische Wahl.