Wer heute Container-Images baut oder Software an Behörden verkauft, kommt an einer Software Bill of Materials nicht mehr vorbei. Der EU Cyber Resilience Act macht SBOMs ab Dezember 2027 zur Pflicht, die deutsche NIS2-Umsetzung verlangt schon jetzt lückenlose Lieferketten-Kontrolle, und Vorfälle wie der XZ-Utils-Backdoor oder die npm-Angriffswelle vom Mai 2026 zeigen, warum Unternehmen wissen müssen, welche Bibliotheken tatsächlich in ihrer Software stecken. Drei Open-Source-Tools dominieren dabei die Diskussion: Syft von Anchore, Trivy von Aqua Security und cdxgen, der offizielle Generator des CycloneDX-Projekts. Alle drei sind kostenlos, alle drei erzeugen SBOMs, aber sie unterscheiden sich deutlich bei Geschwindigkeit, Genauigkeit, Formatunterstützung und dem, was danach mit der SBOM passiert. Dieser Vergleich ordnet die Daten aus mehreren 2026er Benchmarks ein und zeigt, welches Tool zu welchem Team passt.

Was ist eine SBOM und warum wird sie 2026 zur Pflicht

Eine Software Bill of Materials ist eine maschinenlesbare Liste aller Komponenten, Bibliotheken und Abhängigkeiten, aus denen eine Software besteht, vergleichbar mit der Zutatenliste auf einer Lebensmittelverpackung. Die US-Handelsbehörde NTIA hat die “Minimum Elements for a Software Bill of Materials” bereits 2021 definiert: Lieferantenname, Komponentenname, Version, eindeutige Identifikatoren wie purl oder CPE, Abhängigkeitsbeziehungen, Autor und Zeitstempel. Die US-Executive-Order 14028 verpflichtet seit 2021 alle Software-Anbieter des Bundes, ihren Käufern eine SBOM bereitzustellen, mit verbindlichem Start für neue Beschaffungen ab dem Fiskaljahr 2023.

In Europa zieht der Cyber Resilience Act nach. Er ist seit dem 10. Dezember 2024 in Kraft, die Meldepflichten für Schwachstellen nach Artikel 14 greifen ab dem 11. September 2026, und die vollständigen Pflichten inklusive der SBOM-Anforderung werden ab dem 11. Dezember 2027 durchsetzbar. Wer dagegen verstößt, riskiert Bußgelder bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ausfällt. Für falsche oder irreführende Angaben gegenüber Marktüberwachungsbehörden drohen bis zu 5 Millionen Euro oder 1 Prozent des Umsatzes.

Parallel dazu verlangt die deutsche NIS2-Umsetzung, das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz, das am 6. Dezember 2025 in Kraft trat, systematisches Lieferketten-Risikomanagement. Betroffen sind “wichtige Einrichtungen” bereits ab 50 Mitarbeitenden und mehr als 10 Millionen Euro Umsatz, “besonders wichtige Einrichtungen” ab 250 Mitarbeitenden und mehr als 50 Millionen Euro Umsatz. Artikel 21 Absatz 3 der zugrunde liegenden NIS2-Richtlinie schreibt explizit vor, dass Unternehmen die Schwachstellen ihrer direkten Zulieferer und die Sicherheit von deren Entwicklungsprozessen bewerten müssen. Ohne SBOM lässt sich das kaum belegen.

Vor der Automatisierung durch Tools wie Syft, Trivy oder cdxgen pflegten viele Teams ihre Abhängigkeitslisten manuell in Excel-Tabellen oder README-Dateien, ein Verfahren, das schon bei einem mittelgroßen Microservice mit mehreren Hundert transitiven Abhängigkeiten praktisch unmöglich zu aktuell zu halten ist. Moderne Anwendungen ziehen oft zwei- bis dreistellige Anzahlen direkter Pakete und darüber hinaus vielfach mehr transitiver, also indirekt mitgezogener, Abhängigkeiten. Genau diese Lücke zwischen deklarierten und tatsächlich verwendeten Komponenten ist der Angriffspunkt, den Vorfälle wie XZ Utils oder die npm-Kampagne vom Mai 2026 ausnutzen: Niemand im betroffenen Unternehmen wusste zunächst genau, ob und wo die kompromittierte Version überhaupt lief.

Aktuelle Supply-Chain-Vorfälle als Weckruf

Der bekannteste Fall bleibt der XZ-Utils-Backdoor (CVE-2024-3094), im März 2024 entdeckt, als ein jahrelang eingeschleuster bösartiger Code in der weit verbreiteten Kompressionsbibliothek entdeckt wurde, der über OpenSSH Remote-Code-Ausführung ermöglicht hätte. Der Fall gilt bis heute als eines der ausgefeiltesten Beispiele für Social-Engineering in einer Open-Source-Lieferkette, weil der Angreifer sich über Jahre das Vertrauen der Maintainer erarbeitete. Brisant: Sicherheitsforscher von Binarly fanden im August 2025, mehr als ein Jahr nach der Aufdeckung, noch immer Debian-Docker-Images auf Docker Hub, die den Backdoor enthielten. Eine 2025 im IEEE Security & Privacy Magazine veröffentlichte Analyse nennt SBOMs explizit als proaktives Verteidigungsmittel gegen genau solche Langzeitrisiken, weil sie es erlauben, betroffene Versionen einer Bibliothek in Sekunden über den gesamten Softwarebestand hinweg zu identifizieren, statt Systeme einzeln von Hand zu prüfen.

Noch aktueller ist die koordinierte Angriffswelle vom 11. und 12. Mai 2026, bei der Angreifer laut dem Sicherheitsanbieter Safedep mehr als 170 npm-Pakete und zwei PyPI-Pakete kompromittierten, insgesamt 404 bösartige Paketversionen. Betroffen waren unter anderem 42 Pakete aus dem TanStack-Router-Ökosystem, SDKs von Mistral AI, 65 Pakete rund um die Automatisierungsplattform UiPath sowie Komponenten von OpenSearch und Guardrails AI. Der Sicherheitsanbieter Orca Security beschrieb die Kampagne als Fortsetzung der sogenannten “Shai-Hulud”-Angriffsfamilie und identifizierte unter anderem die kompromittierten Pakete guardrails-ai 0.10.1 und mistralai 2.4.6. Betroffene Unternehmen mussten in kurzer Zeit klären, ob und wo diese exakten Paketversionen in ihrer Software liefen, eine Aufgabe, die ohne aktuelle SBOM-Bestände Tage statt Minuten dauert. Genau dieses Szenario, schnelle Bestandsabfragen bei akuten Vorfällen, ist der eigentliche Praxisnutzen von Syft, Trivy und cdxgen, unabhängig vom regulatorischen Druck.

Die drei Tools im Überblick

Syft, Trivy und cdxgen lösen auf den ersten Blick dasselbe Problem, verfolgen aber unterschiedliche Philosophien. Syft ist ein reiner SBOM-Generator: schnell, detailliert, aber ohne eigene Schwachstellenanalyse. Für CVE-Scans kombinieren Anwender es typischerweise mit Grype, dem Schwester-Tool aus dem Anchore-Ökosystem. Trivy dagegen ist ein All-in-One-Scanner. Es generiert SBOMs, scannt Container, Dateisysteme, IaC-Konfigurationen und Kubernetes-Cluster auf Schwachstellen und liefert die Ergebnisse in einem einzigen Lauf. cdxgen wiederum ist kein Scanner, sondern das offizielle Referenz-Tool des OWASP-CycloneDX-Projekts, spezialisiert auf präzise CycloneDX-Dokumente für Build-Pipelines.

Die Popularität der drei Projekte unterscheidet sich erheblich. Trivy führt mit rund 37.500 GitHub-Stars (Stand August 2026), gefolgt von Syft mit etwa 9.000 Stars. cdxgen liegt mit knapp 936 Stars deutlich dahinter, was aber wenig über die tatsächliche Nutzung aussagt: cdxgen wird oft unsichtbar über Build-Plugins in Maven, npm oder Gradle eingebunden, ohne dass Teams das Repository selbst besuchen. Alle drei Projekte stehen unter der Apache-2.0-Lizenz, was die kommerzielle Nutzung ohne Copyleft-Auflagen erlaubt.

Syft im Detail: Der spezialisierte Generator

Anchore hat Syft als Kommandozeilen-Tool entwickelt, das SBOMs aus Container-Images, Dateisystemen, Archiven und Quellcode-Verzeichnissen erzeugt. Es deckt laut mehreren 2026er Vergleichen mehr als 30 Paket-Ökosysteme ab, von npm über PyPI, Maven und Go-Module bis zu Betriebssystempaketen wie APK, DPKG und RPM. Syft schreibt CycloneDX in Version 1.5 (JSON und XML), SPDX in Version 2.3 (JSON und Tag-Value) sowie ein eigenes Syft-JSON-Format mit besonders reichhaltigen Metadaten. Für Go- und Rust-Binaries bringt Syft eine vergleichsweise starke Binäranalyse mit, die auch Komponenten in statisch gelinkten Programmen findet.

Typischer Aufruf für ein Container-Image:

syft packages docker:nginx:latest -o [email protected] > nginx-sbom.json
syft packages dir:./src -o [email protected] > source-sbom.json

Für Schwachstellenscans fehlt Syft ein eigenes Modul. Anchore verweist Nutzer konsequent auf Grype, das die von Syft erzeugte SBOM einliest und gegen mehrere Vulnerability-Feeds prüft. Wer eine Compliance-taugliche Lösung mit Support sucht, greift zu Anchore Enterprise, das laut AWS-Marketplace-Listungen bei rund 34.500 US-Dollar pro Jahr für die Cloud-Image-Variante beginnt und bei der Kubernetes-Helm-Variante bei etwa 50.000 US-Dollar pro Jahr liegt, zuzüglich eines optionalen Support-Pakets für rund 15.000 US-Dollar jährlich.

Architektonisch arbeitet Syft mit sogenannten Catalogern, spezialisierten Modulen, die jeweils genau ein Paketformat auslesen, etwa den npm-Cataloger für package-lock.json oder den Java-Cataloger für JAR-Manifeste. Diese Modularität erklärt, warum Syft neue Ökosysteme vergleichsweise schnell nachrüsten kann, ohne den Kern des Tools anzufassen. Für regulierte und teils luftisolierte Umgebungen wie Behörden oder Rüstungszulieferer ist zudem relevant, dass Syft vollständig offline betrieben werden kann, weil es anders als Trivy keine externe Datenbank für den eigentlichen SBOM-Erzeugungsschritt benötigt. Erst der nachgelagerte CVE-Scan mit Grype braucht eine aktuelle Vulnerability-Datenbank, die sich aber vorab herunterladen und in geschlossene Netze spiegeln lässt.

Trivy im Detail: Der All-in-One-Scanner

Aqua Security positioniert Trivy als Werkzeug, das SBOM-Generierung und Schwachstellenscan in einem Schritt erledigt. Ein einziger Befehl liefert sowohl die Komponentenliste als auch die dazugehörigen CVEs, inklusive Bewertung nach CVSS-Score. Trivy scannt Container-Images, Dateisysteme, Git-Repositories, Kubernetes-Cluster und Infrastructure-as-Code-Dateien wie Terraform oder CloudFormation. Es unterstützt sowohl CycloneDX (Version 1.5 und 1.6) als auch SPDX (Version 2.3) und kann SBOMs nicht nur erzeugen, sondern auch fremde SBOM-Dateien als Eingabe einlesen und gegen aktuelle Schwachstellendaten prüfen.

trivy image --format cyclonedx --output nginx-sbom.json nginx:latest
trivy sbom nginx-sbom.json --format json

Der Praxisvorteil zeigt sich in DevSecOps-Pipelines, die ohnehin einen Schwachstellenscanner brauchen: Statt zwei Tools zu pflegen, reicht eines. GitLab nutzt Trivy als Standard-Container-Scanner in seiner integrierten Sicherheitsprüfung, und die Registry-Software Harbor sowie Mirantis Docker Enterprise haben Trivy fest als Default-Scanner verbaut. Die kommerzielle Aqua-Plattform, die Trivy als Basis nutzt, beginnt laut mehreren Preisrecherchen bei etwa 12.000 US-Dollar jährlich für reine Cloud-Security-Pakete und reicht bei vollständigen CNAPP-Lizenzen über AWS Marketplace von 50.000 über 100.000 bis zu 150.000 US-Dollar pro Jahr, je nach Funktionsumfang.

Ein Wermutstropfen aus dem März 2026: Zwischen dem 19. und 23. März wurden offizielle Trivy-Images auf Docker Hub (aquasec/trivy, Tags 0.69.4 bis 0.69.6 sowie latest) kompromittiert. Docker und Aqua entfernten die betroffenen Images und rieten Nutzern, auf die letzte saubere Version 0.69.3 zurückzuwechseln und CI/CD-Zugangsdaten zu rotieren. Der Vorfall zeigt, dass selbst ein Sicherheitswerkzeug Teil einer Lieferkette ist und seine eigene Herkunft überprüft werden muss.

Über die reine Paketanalyse hinaus deckt Trivy auch Cloud-Konfigurationsfehler ab, etwa offene S3-Buckets oder zu weit gefasste IAM-Rollen, sowie Geheimnisse wie versehentlich eingecheckte API-Schlüssel. Ein eigener Kubernetes-Operator installiert sich direkt im Cluster und scannt laufende Workloads kontinuierlich, statt nur einmalig beim Build. Diese Breite macht Trivy zum naheliegenden Werkzeug für Teams, die ohnehin schon eine Cloud-native Sicherheitsstrategie fahren und die SBOM-Funktion eher als Zusatznutzen eines bereits vorhandenen Scanners betrachten als als eigenständiges Projekt.

cdxgen im Detail: Der CycloneDX-Spezialist

cdxgen ist das offizielle Generator-Tool des OWASP-CycloneDX-Projekts und erzeugt ausschließlich CycloneDX-Dokumente, kein SPDX. Diese Fokussierung zahlt sich bei der Genauigkeit aus: In der 2026er Studie “Best SBOM Generators Ranked by Accuracy” von Safeguard erreichte cdxgen 11.1 einen Recall von 97 Prozent und eine Präzision von 96 Prozent, die höchsten Werte im Test. Besonders bei JavaScript- und JVM-Projekten identifiziert cdxgen transitive Abhängigkeiten zuverlässiger als Syft oder Trivy. Es deckt mehr als 20 Programmiersprachen ab und lässt sich über Plugins direkt in Build-Tools wie Maven, Gradle oder npm einhängen, wodurch die SBOM ohne separaten Scan-Schritt entsteht.

npx @cyclonedx/cdxgen -o bom.json -t js .
cdxgen --project-type java -o bom.xml

Ein eigenes “CycloneDX Enterprise” gibt es nicht. Das CycloneDX-Format ist ein offener OWASP-Standard, kein Produkt, daher kommerzialisieren Drittanbieter wie Interlynk oder Dependency-Track das Format über eigene SBOM-Management-Plattformen. Dependency-Track selbst ist quelloffen und kostenlos, verlangt aber eigenen Betriebsaufwand für Server und Datenbank. Wer strikt CycloneDX-standardisiert arbeiten muss, etwa weil ein Kunde oder eine Behörde das Format vorschreibt, bekommt mit cdxgen die kanonischste Umsetzung des Schemas, inklusive Unterstützung für VEX-Dokumente (Vulnerability Exploitability eXchange) und signierte BOM-Link-Attestierungen.

Der VEX-Mechanismus löst ein Problem, das Syft und Trivy in dieser Form nicht adressieren: Eine reine Komponentenliste sagt nichts darüber aus, ob eine bekannte Schwachstelle in einer Bibliothek im konkreten Produkt überhaupt erreichbar ist. Mit VEX kann ein Hersteller pro CVE explizit dokumentieren “betroffen”, “nicht betroffen” oder “wird untersucht”, was Sicherheitsteams beim Empfänger enorm viel manuelle Triage-Arbeit erspart. BOM-Link-Attestierungen wiederum erlauben es, mehrere SBOMs entlang einer mehrstufigen Lieferkette kryptografisch miteinander zu verknüpfen, etwa vom Zulieferer einer Bibliothek bis zum fertigen Produkt. Für Organisationen, die selbst Software an andere Unternehmen liefern und dabei CRA-konform Auskunft über Schwachstellen geben müssen, ist das ein handfester praktischer Vorteil gegenüber den generischeren SBOM-Formaten von Syft und Trivy.

Technischer Spezifikationsvergleich

Die folgende Tabelle fasst die wichtigsten technischen Eckdaten aller drei Tools zusammen, basierend auf den offiziellen Dokumentationen und mehreren unabhängigen 2026er Vergleichsstudien.

KriteriumSyftTrivycdxgen
HerstellerAnchoreAqua SecurityOWASP CycloneDX Projekt
GitHub-Stars (Aug. 2026)≈ 9.000≈ 37.500≈ 936
LizenzApache 2.0Apache 2.0Apache 2.0
Primärer ZweckSBOM-GenerierungAll-in-One-Scanner + SBOMCycloneDX-Generierung
Unterstützte FormateCycloneDX, SPDX, Syft-JSONCycloneDX, SPDXnur CycloneDX
CycloneDX-Version1.51.5 / 1.6aktuell (v11.1)
SPDX-Version2.32.3nicht unterstützt
Paket-Ökosysteme30+vergleichbar breit (Scanner-Basis)20+ Sprachen
Schwachstellenscan integriertNein (Grype nötig)Ja, nativNein
Typische Scan-Zeit (Container)15–30 Sekunden20–60 Sekunden (mit DB-Download)am schnellsten bei Build-Integration
Recall (SBOM-Genauigkeit)94 %91 %97 %
Lizenzerkennungs-Genauigkeit88 %84 %91 %
Binäranalyse (Go/Rust)starkmoderatkeine native Unterstützung
Kommerzielle VarianteAnchore Enterprise ab ≈ 34.500 $/JahrAqua Platform ab ≈ 12.000 $/Jahrkeine dedizierte (Drittplattformen)
CI/CD-IntegrationGitHub Action, GitLab, JenkinsGitHub Action, GitLab, K8s-OperatorBuild-Plugins (Maven, npm, Gradle)

Benchmarks aus drei Quellen: Wer ist wirklich am schnellsten

Geschwindigkeit hängt stark vom Testszenario ab, deshalb lohnt sich der Blick auf mehrere unabhängige Messungen statt auf eine einzelne Zahl. Der Anbieter Safeguard verglich Syft, Tern und Trivy 2026 anhand eines 500-Megabyte-Container-Images und kam zu dem Ergebnis, dass Trivy in den meisten Szenarien am schnellsten scannt, während Syft je nach Cataloger-Konfiguration 1,5- bis 3-mal länger benötigt. Tern, ein drittes Open-Source-Tool, fiel in diesem Test deutlich ab.

Eine zweite Quelle, der Vergleichsdienst Secure-Pipelines, maß für ein typisches Container-Image 15 bis 30 Sekunden bei Syft und 20 bis 60 Sekunden bei Trivy, wobei der größte Teil der Trivy-Zeit auf den erstmaligen Download der Vulnerability-Datenbank entfällt. Läuft Trivy mit bereits gecachter Datenbank, etwa über das Flag --skip-db-update in einer vorgewärmten CI-Umgebung, gleichen sich beide Tools in der Praxis an. cdxgen schnitt in diesem Vergleich als schnellstes Tool ab, weil es direkt in den Build-Prozess eingebunden wird und keinen separaten Scan-Schritt braucht.

Eine dritte, akademische Quelle, eine 2025 vorgestellte koreanische Vergleichsstudie (ASK-Konferenz), maß nicht nur die Zeit, sondern auch die Dateigröße der erzeugten SBOMs. Für das Image httpd:latest fiel die von Syft erzeugte SBOM-Datei rund 2,4-mal größer aus als die von Trivy, bei mysql:8.0 sogar rund 11-mal größer. Die Autoren folgerten, dass Trivy für die getesteten Images kleinere Dateien und schnellere Generierung liefert, wobei die höhere Detailtiefe von Syft in vielen Compliance-Szenarien trotzdem gewünscht ist. Insgesamt zeichnet sich ein konsistentes Bild: Trivy gewinnt bei roher Geschwindigkeit, Syft liefert mehr Metadaten pro Sekunde investierter Wartezeit, und cdxgen ist am schnellsten, sobald es fest im Build verankert ist.

Genauigkeit und Formatqualität im Detail

Geschwindigkeit ist nur die halbe Wahrheit. Eine SBOM, die Komponenten übersieht, hilft bei einem Audit wenig. Safeguards Genauigkeitsranking 2026 testete alle drei Tools gegen bekannte Referenz-Abhängigkeitsbäume und maß Recall (wie viele echte Komponenten gefunden wurden), Präzision (wie viele gefundene Komponenten tatsächlich existieren) und die Trefferquote bei der Lizenzerkennung. cdxgen 11.1 lag bei allen drei Metriken vorn: 97 Prozent Recall, 96 Prozent Präzision, 91 Prozent korrekt erkannte Lizenzen. Syft 1.19 folgte mit 94 Prozent Recall, 98 Prozent Präzision (dem höchsten Wert im Test) und 88 Prozent Lizenzgenauigkeit. Trivy 0.59 erreichte 91 Prozent Recall, 97 Prozent Präzision und 84 Prozent Lizenzgenauigkeit.

Interessant ist der Kontrast zu einer akademischen Untersuchung von 2024 (DSN-Konferenz, “On the Correctness of Metadata-Based SBOM Generation”), die auf einem eigenen, strengeren Testkorpus für Trivy und Syft deutlich niedrigere Werte fand, teilweise nur 10 Prozent Recall und 25 Prozent Präzision. Der Unterschied erklärt sich durch die Testmethodik: Während Safeguard bekannte, gut gepflegte Projekte scannte, prüfte die DSN-Studie gezielt Edge Cases mit unsauberen Metadaten. Für die Praxis bedeutet das: Die Genauigkeit einer SBOM hängt nicht nur vom Tool ab, sondern auch davon, wie sauber die gescannte Codebasis selbst dokumentiert ist. Wer harte Zahlen für einen Compliance-Nachweis braucht, sollte eigene Testläufe gegen die eigene Codebasis durchführen statt sich blind auf Herstellerbenchmarks zu verlassen.

Die Lizenzerkennungsrate verdient dabei besondere Aufmerksamkeit, weil sie oft unterschätzt wird. Eine SBOM, die eine GPL-lizenzierte Komponente fälschlich als MIT-lizenziert ausweist, kann im schlimmsten Fall zu einer rechtlich riskanten Weiterverbreitung führen, etwa wenn ein Unternehmen proprietäre Software mit einer copyleft-pflichtigen Bibliothek verbindet, ohne es zu wissen. Mit 91 Prozent korrekt erkannten Lizenzen liegt cdxgen hier deutlich vor Syft (88 Prozent) und Trivy (84 Prozent), ein Vorsprung, der bei Unternehmen mit strengen Open-Source-Compliance-Richtlinien, etwa in der Automobil- oder Finanzbranche, den Ausschlag für die Toolwahl geben kann. Rechtsabteilungen sollten sich unabhängig vom gewählten Tool nicht allein auf die automatische Lizenzerkennung verlassen, sondern bei kritischen Komponenten stichprobenartig manuell nachprüfen.

Preise und Lizenzmodelle im Vergleich

Alle drei Kern-Tools sind und bleiben kostenlos unter Apache-2.0-Lizenz. Die Kosten entstehen erst, wenn Teams zusätzliche Funktionen wie zentrales SBOM-Management, Policy-Enforcement, Support-SLAs oder Compliance-Reporting brauchen. Die folgende Tabelle zeigt die öffentlich bekannten Preispunkte, größtenteils aus AWS-Marketplace-Listungen, Stand 2026.

ProduktModellStartpreisZielgruppe
Syft (Open Source)kostenlos0 €alle Teamgrößen
Anchore Enterprise Cloud ImageJahreslizenz≈ 34.500 $/JahrMittelstand mit Compliance-Pflicht
Anchore Enterprise HelmJahreslizenz≈ 50.000 $/JahrKubernetes-Umgebungen
Anchore Customer-Success-PaketZusatzoption≈ 15.000 $/JahrEnterprise-Support
Trivy (Open Source)kostenlos0 €alle Teamgrößen
Aqua Cloud SecurityJahreslizenzab ≈ 12.000 $/JahrCloud-native Teams
Aqua Platform Shift LeftJahreslizenz≈ 50.000 $/JahrMittelstand
Aqua Platform Protect (Advanced)Jahreslizenz≈ 100.000 $/JahrEnterprise
Aqua Platform UltimateJahreslizenz≈ 150.000 $/JahrGroßkonzerne
cdxgen (Open Source)kostenlos0 €alle Teamgrößen
Dependency-Track (SBOM-Management)Open Source, Eigenbetrieb0 € (Serverkosten separat)Teams mit CycloneDX-Fokus

Für größere Aqua-Deployments jenseits der Marketplace-Pakete nennen mehrere Preisrecherchen realistische Praxiskosten von 20 bis 55 US-Dollar pro Workload und Monat, was bei 5.000 überwachten Workloads schnell 1,5 bis 3 Millionen US-Dollar pro Jahr ergibt. Mittelständische Deployments liegen laut mehreren Quellen häufig zwischen 75.000 und 200.000 US-Dollar jährlich. Anchore bietet dagegen keine öffentliche Preisliste, sondern verhandelt individuell nach SBOM-Volumen und Support-Level. Wer nur eine SBOM-Pflicht erfüllen muss, ohne Enterprise-Funktionen wie rollenbasierte Zugriffskontrolle oder SLA-Support zu brauchen, kommt mit den kostenlosen Varianten plus Dependency-Track für das Monitoring oft komplett ohne Lizenzkosten aus.

CycloneDX gegen SPDX: Welches Format zählt

Die Formatfrage entscheidet oft schon vorab, welches Tool infrage kommt. SPDX, gepflegt von der Linux Foundation, ist das ältere und in behördlichen US-Kontexten stärker verankerte Format, unterstützt von der NTIA-Richtlinie als eine von mehreren zulässigen Optionen neben CycloneDX und SWID. CycloneDX, entwickelt unter dem OWASP-Dach, ist jünger, aber technisch breiter aufgestellt: Es unterstützt native VEX-Dokumente, mit denen Hersteller angeben können, ob eine bekannte Schwachstelle in ihrem konkreten Produkt tatsächlich ausnutzbar ist, sowie signierte BOM-Link-Attestierungen für die Lieferkette.

Syft und Trivy sprechen beide Formate fließend und lassen sich mit einem einzigen Flag umschalten. cdxgen dagegen bindet sich bewusst nur an CycloneDX und erreicht dafür die höchste Genauigkeit im direkten Vergleich. Für deutsche und europäische Unternehmen spricht einiges für CycloneDX als Standardformat, weil der Cyber Resilience Act und mehrere BSI-Publikationen es explizit als Referenzformat nennen, auch wenn SPDX formal ebenfalls zulässig bleibt. Wer bereits SPDX-Pflichten aus US-Geschäft (etwa als Zulieferer einer Bundesbehörde) erfüllen muss, sollte auf Syft oder Trivy setzen, weil cdxgen dieses Format schlicht nicht ausgibt.

SBOM-Generierung in CI/CD-Pipelines: Gängige Muster

In der Praxis läuft SBOM-Generierung selten als isolierter Schritt, sondern eingebettet in bestehende Build- und Release-Prozesse. Ein verbreitetes Muster ist Shift-Left-Scanning: Die SBOM entsteht direkt beim Build, nicht erst beim Deployment, sodass Probleme auffallen, bevor ein Image überhaupt eine Registry erreicht. Bei cdxgen ist das der Standardfall, weil das Tool ohnehin als Build-Plugin läuft. Bei Syft und Trivy richten Teams dafür typischerweise einen eigenen Pipeline-Schritt nach dem Image-Build und vor dem Push ein, häufig mit einer Policy-Gate-Logik: Enthält die SBOM eine Komponente mit einer kritischen, bereits auf der CISA-KEV-Liste geführten Schwachstelle, stoppt die Pipeline automatisch.

Ein zweites verbreitetes Muster ist die kryptografische Signierung der SBOM selbst, meist über das Sigstore-Projekt mit dem Werkzeug Cosign oder über in-toto-Attestierungen. Damit lässt sich später beweisen, dass eine SBOM tatsächlich vom deklarierten Build-System stammt und nicht nachträglich manipuliert wurde, ein Punkt, der bei CRA-Audits zunehmend nachgefragt wird. Ergänzend nutzen viele Teams die kostenlosen Scorecards der Open Source Security Foundation (OpenSSF), um neben der reinen Komponentenliste auch die Projekthygiene einzelner Abhängigkeiten einzuschätzen, etwa ob ein Paket aktiv gepflegt wird oder Zwei-Faktor-Schutz für Maintainer-Konten nutzt. Diese Kombination aus SBOM-Generator, Policy-Gate, Signierung und Scorecard-Check bildet inzwischen den De-facto-Standard für Software-Lieferketten-Sicherheit in größeren Organisationen, unabhängig davon, ob am Ende Syft, Trivy oder cdxgen die eigentliche Liste erzeugt.

Reale Einsatzbeispiele aus Wirtschaft und Behörden

Die US-Marine nutzt Anchores Werkzeugkette, einschließlich Syft als Generator, um im Rahmen des Platform-One-Programms Software-Freigaben (Authority to Operate) innerhalb weniger Tage statt Monate zu erteilen, gestützt auf kontinuierliches Compliance-Monitoring statt manueller Einzelprüfung. Die Schweizer Hypothekarbank Lenzburg setzt Anchore Enterprise ein, um Container-Sicherheit und SBOM-Pflichten im regulierten Bankenumfeld zu erfüllen, ein Beispiel, das für DACH-Finanzinstitute unter NIS2 und DORA direkt relevant ist. Der Kollaborationsanbieter Mattermost berichtet, mit Anchores SBOM- und Scan-Werkzeugen die Zahl unnötiger Alarme reduziert und NIST-Compliance-Nachweise beschleunigt zu haben, während der Dienstleister Sabel Systems eigenen Angaben zufolge die Zeit für Schwachstellen-Reviews um 75 Prozent senken konnte.

Auf der Trivy-Seite hat sich GitLab entschieden, Trivy als Standard-Container-Scanner in die eigene integrierte Sicherheitsprüfung einzubauen, sodass jeder GitLab-Nutzer die Funktion ohne Zusatzinstallation erhält. Die Container-Registry Harbor sowie Mirantis Docker Enterprise haben Trivy ebenfalls fest als Default-Scanner verankert, was seine große Verbreitung in Kubernetes-nahen Umgebungen erklärt. Aqua selbst nennt unter anderem die irische Allied Irish Banks und den norwegischen Energieversorger Elvia als Kunden, die Trivy beziehungsweise die Aqua-Plattform im regulierten Umfeld einsetzen.

Der eingangs erwähnte Docker-Hub-Vorfall vom März 2026, bei dem kompromittierte Trivy-Images selbst zur Bedrohung wurden, unterstreicht ein sechstes, ungewolltes Beispiel: Selbst etablierte Sicherheitswerkzeuge sind Teil der Software-Lieferkette und müssen mit demselben Misstrauen behandelt werden wie jede andere Abhängigkeit. Teams, die Trivy in CI/CD einsetzen, sollten Image-Digests statt Tags pinnen und Signaturen prüfen, statt blind “latest” zu ziehen.

Für den deutschen Mittelstand liefert die Kombination aus einem SBOM-Generator und einer offenen Monitoring-Schicht oft das praktikabelste Bild. Ein typisches Setup, wie es mehrere DACH-Softwarehäuser inzwischen fahren, sieht so aus: Trivy erzeugt beim Build automatisch eine CycloneDX-SBOM für jedes Container-Image, die SBOM landet in einer selbst gehosteten Dependency-Track-Instanz, und das Sicherheitsteam bekommt eine tägliche Zusammenfassung neu bekannt gewordener Schwachstellen über den gesamten Produktbestand hinweg, statt jedes Repository einzeln zu prüfen. Diese Kombination kostet, abgesehen vom Betriebsaufwand für den Dependency-Track-Server, keine Lizenzgebühren und erfüllt trotzdem die zentralen NIS2-Anforderungen an fortlaufende Lieferketten-Überwachung.

Welches Tool passt zu welchem Anwendungsfall

  • Kleine Teams ohne akuten Compliance-Druck: Syft kombiniert mit Grype liefert detaillierte SBOMs und CVE-Scans, beides kostenlos, bei überschaubarem Wartungsaufwand.
  • Teams, die bereits Trivy als Scanner nutzen: Die integrierte SBOM-Funktion von Trivy erspart ein zweites Tool und hält die Pipeline schlank.
  • US-Bundeszulieferer und Behörden mit EO-14028-Pflicht: Anchore Enterprise mit Syft als Unterbau bietet die vom Platform-One-Referenzfall belegte Compliance-Automatisierung.
  • JavaScript- und Java-lastige Entwicklungsteams: cdxgen liefert laut Safeguard-Studie die höchste Genauigkeit bei transitiven Abhängigkeiten in genau diesen Ökosystemen.
  • Deutsche Finanzinstitute und KRITIS-Betreiber unter NIS2 und DORA: Eine Kombination aus SBOM-Generator (Syft oder Trivy) und einer zentralen Monitoring-Plattform wie Dependency-Track deckt sowohl Generierung als auch fortlaufende Überwachung ab.
  • Kubernetes-native Großunternehmen: Trivy mit seinem Kubernetes-Operator oder Anchore Enterprise Helm lassen sich direkt in Cluster-Pipelines integrieren, ohne separate Scan-Jobs zu orchestrieren.

Diese sechs Fälle decken die häufigsten Konstellationen ab, schließen sich aber nicht gegenseitig aus. Viele Organisationen landen nach einigen Monaten Praxiserfahrung bei einer hybriden Lösung, etwa Trivy für den täglichen CI/CD-Durchlauf und cdxgen gezielt für die wenigen Anwendungen, bei denen ein Kunde vertraglich eine CycloneDX-SBOM mit VEX-Unterstützung verlangt. Die Toolwahl sollte sich dabei stets an der tatsächlichen Anforderung orientieren, nicht an der reinen GitHub-Popularität eines Projekts.

Migrationsleitfaden: SBOM-Tooling in bestehende Pipelines einführen

Der Umstieg auf oder zwischen SBOM-Tools folgt in der Praxis einem wiederkehrenden Muster, unabhängig davon, ob ein Team von Grund auf startet oder von einem Tool zum anderen wechselt.

  1. Bestandsaufnahme: Zunächst klären, welche Formate Kunden, Behörden oder interne Compliance-Vorgaben verlangen, CycloneDX, SPDX oder beides.
  2. Pilotprojekt wählen: Ein einzelnes, überschaubares Repository oder Container-Image als Testfall nutzen, bevor die gesamte Pipeline umgestellt wird.
  3. Tool parallel betreiben: Beim Wechsel von Trivy zu Syft (oder umgekehrt) beide Tools für zwei bis drei Sprints parallel laufen lassen und die erzeugten SBOMs auf Abweichungen bei Recall und Lizenzerkennung vergleichen.
  4. CI/CD-Integration einbauen: Das gewählte Tool als eigenen Pipeline-Schritt einbinden, etwa über die offiziellen GitHub Actions von Anchore oder Aqua, mit Caching der Vulnerability-Datenbank, um Laufzeiten niedrig zu halten.
  5. Schwachstellenscan koppeln: Bei Syft und cdxgen einen separaten Scanner wie Grype anschließen, bei Trivy ist dieser Schritt bereits integriert.
  6. Zentrales SBOM-Management aufsetzen: Erzeugte SBOMs in eine Plattform wie Dependency-Track einspeisen, um Bestände über viele Repositories hinweg zu verfolgen und bei neu bekannt gewordenen CVEs automatisch Alarm zu schlagen.
  7. Compliance-Mapping dokumentieren: Festhalten, welche SBOM welche Anforderung erfüllt, etwa CRA-Artikel-14-Meldepflicht oder NIS2-Lieferantenbewertung, damit der Nachweis im Auditfall sofort vorliegt.
  8. Altsysteme nachziehen: Legacy-Anwendungen ohne moderne Build-Pipeline zuletzt behandeln, oft reicht hier ein einmaliger Syft-Scan des Dateisystems als Startpunkt.

Wichtig bei jedem Wechsel: SBOMs aus unterschiedlichen Tools sind nicht automatisch identisch, selbst wenn beide dasselbe Format ausgeben. Unterschiede bei Cataloger-Logik, Versionsauflösung oder Lizenzerkennung führen zu abweichenden Ergebnissen. Ein direkter Diff der SBOM-Inhalte vor der endgültigen Umstellung verhindert böse Überraschungen bei der ersten Audit-Vorlage.

Teams, die zum ersten Mal überhaupt eine SBOM-Pflicht umsetzen, unterschätzen häufig den organisatorischen Anteil der Migration. Die technische Installation eines der drei Tools dauert in der Regel wenige Stunden, die eigentliche Arbeit liegt danach in der Klärung von Zuständigkeiten: Wer reagiert, wenn eine neu gemeldete CVE eine Komponente betrifft, die in zwanzig verschiedenen SBOMs auftaucht? Ohne eine klare Eskalationskette bleibt selbst die beste SBOM ein ungenutztes PDF im Auditordner. Erfahrene Sicherheitsteams empfehlen deshalb, die Rollout-Reihenfolge nach Risiko statt nach technischer Einfachheit zu sortieren: zuerst die Anwendungen mit Internetkontakt und Kundendaten, zuletzt interne Werkzeuge ohne Außenkontakt.

Vor- und Nachteile im Überblick

Syft

  • Vorteil: Sehr detaillierte Metadaten, starke Binäranalyse für Go und Rust, unterstützt CycloneDX und SPDX gleichzeitig.
  • Vorteil: Enge Integration mit Grype für CVE-Scans, großes Anchore-Ökosystem im Behördenumfeld.
  • Nachteil: Kein eigener Schwachstellenscan, 1,5- bis 3-mal langsamer als Trivy bei großen Images.
  • Nachteil: Erzeugt teils deutlich größere SBOM-Dateien als Trivy, was Speicher- und Übertragungsaufwand erhöht.

Trivy

  • Vorteil: All-in-One-Lösung mit integriertem CVE-Scan, IaC- und Kubernetes-Prüfung, größte Community und breiteste Plattform-Integration (GitLab, Harbor, Mirantis).
  • Vorteil: In den meisten Benchmarks das schnellste Tool, kompakte SBOM-Dateien.
  • Nachteil: Erste Ausführung durch Datenbank-Download verlangsamt, niedrigste Recall- und Lizenzgenauigkeit im Safeguard-Vergleich.
  • Nachteil: War im März 2026 selbst Ziel eines Supply-Chain-Vorfalls über kompromittierte Docker-Hub-Images.

cdxgen

  • Vorteil: Höchste Genauigkeit bei Recall, Präzision und Lizenzerkennung im 2026er Vergleich, native VEX- und BOM-Link-Unterstützung.
  • Vorteil: Direkte Build-Integration ohne separaten Scan-Schritt, dadurch in der Praxis oft am schnellsten.
  • Nachteil: Kein SPDX-Export, daher ungeeignet für reine US-Bundesaufträge mit SPDX-Pflicht.
  • Nachteil: Keine eigene Schwachstellenanalyse, kleinere Community und weniger kommerzieller Support als Anchore oder Aqua.

Fazit: Welches Tool gewinnt den Vergleich

Es gibt keinen absoluten Sieger, die Daten zeigen stattdessen drei klar unterschiedliche Stärken. Trivy gewinnt bei Tempo und Praxistauglichkeit für Teams, die ohnehin einen Schwachstellenscanner brauchen, unterstützt durch die mit Abstand größte Community von rund 37.500 GitHub-Stars und feste Verankerung in GitLab, Harbor und Docker-Umgebungen. Syft gewinnt bei Detailtiefe und Formatflexibilität und bleibt die richtige Wahl für Teams, die SPDX brauchen oder Anchores Compliance-Ökosystem im Behördenkontext nutzen. cdxgen gewinnt eindeutig bei der Genauigkeit, mit 97 Prozent Recall gegenüber 94 Prozent bei Syft und 91 Prozent bei Trivy laut der Safeguard-Studie 2026, und ist damit die logische Wahl für CycloneDX-standardisierte Umgebungen und JavaScript- oder Java-lastige Projekte.

Für deutsche und DACH-Unternehmen, die sich auf den Cyber Resilience Act (volle Pflicht ab 11. Dezember 2027) und die deutsche NIS2-Umsetzung vorbereiten, lautet die pragmatische Empfehlung: mit dem bereits im Stack vorhandenen Scanner starten, meist Trivy, weil es CVE-Prüfung und SBOM in einem Schritt liefert, und bei Bedarf an Detailtiefe oder Formatgenauigkeit gezielt Syft oder cdxgen für einzelne kritische Anwendungen ergänzen. Wichtiger als die Wahl des einzelnen Generators ist ohnehin der zweite Schritt, den viele Teams überspringen: ein zentrales SBOM-Management, das neu bekannt gewordene Schwachstellen automatisch gegen den vorhandenen Bestand abgleicht, statt SBOMs nur einmalig für den Auditordner zu erzeugen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer SBOM und einem Schwachstellenscan?

Eine SBOM listet alle Komponenten einer Software auf, unabhängig davon, ob sie Schwachstellen enthalten. Ein Schwachstellenscan gleicht diese Liste anschließend gegen bekannte CVE-Datenbanken ab. Syft und cdxgen erzeugen nur die Liste, Trivy erledigt beides in einem Durchlauf.

Welches der drei Tools ist am schnellsten?

In den meisten Benchmarks ist Trivy bei Standard-Container-Images am schnellsten, sofern die Vulnerability-Datenbank bereits gecacht ist. cdxgen kann bei Build-Zeit-Integration noch schneller sein, weil kein separater Scan-Schritt nötig ist. Syft benötigt je nach Konfiguration 1,5- bis 3-mal länger als Trivy.

Brauche ich CycloneDX oder SPDX?

Das hängt von den Anforderungen der Kunden oder Behörden ab. Der Cyber Resilience Act und mehrere BSI-Veröffentlichungen nennen CycloneDX als Referenzformat, während US-Bundesbehörden häufig SPDX verlangen. Syft und Trivy unterstützen beide Formate, cdxgen ausschließlich CycloneDX.

Ab wann sind SBOMs in der EU verpflichtend?

Der Cyber Resilience Act ist seit dem 10. Dezember 2024 in Kraft. Meldepflichten für aktiv ausgenutzte Schwachstellen nach Artikel 14 gelten ab dem 11. September 2026, die vollständigen Pflichten inklusive SBOM-Anforderung werden ab dem 11. Dezember 2027 durchsetzbar.

Gilt die SBOM-Pflicht auch für kleinere deutsche Unternehmen?

Die deutsche NIS2-Umsetzung erfasst bereits “wichtige Einrichtungen” ab 50 Mitarbeitenden und mehr als 10 Millionen Euro Jahresumsatz. Diese müssen ihre Lieferkette und die Entwicklungsprozesse ihrer Zulieferer bewerten, wofür eine SBOM in der Praxis die Grundlage bildet, auch ohne direkte gesetzliche SBOM-Nennung im BSIG-Text.

Kann ich Syft und Trivy gemeinsam einsetzen?

Ja, einige Teams nutzen Syft für besonders detaillierte SBOMs kritischer Anwendungen und Trivy für den täglichen CI/CD-Scan der übrigen Pipeline. Beide Tools lesen und schreiben kompatible CycloneDX- und SPDX-Formate, ein Parallelbetrieb verursacht keine technischen Konflikte.

Was kostet der Umstieg auf eine kommerzielle SBOM-Plattform?

Anchore Enterprise beginnt laut AWS-Marketplace bei rund 34.500 US-Dollar jährlich, die Aqua-Plattform bei rund 12.000 US-Dollar für Einstiegspakete und reicht bei vollständigen Enterprise-Lizenzen bis 150.000 US-Dollar und mehr pro Jahr. Für CycloneDX-Formate gibt es kein dediziertes Enterprise-Produkt, hier übernehmen Drittplattformen wie Dependency-Track die kommerzielle Ebene.

Ersetzt eine SBOM einen klassischen Schwachstellenscanner komplett?

Nein. Eine SBOM ist die Grundlage für Transparenz und Nachweisführung, ersetzt aber keinen fortlaufenden Scan gegen aktuelle CVE-Datenbanken. Erst die Kombination aus SBOM-Generator und Scanner, ob getrennt wie bei Syft plus Grype oder integriert wie bei Trivy, liefert einen vollständigen Überblick über neue Risiken in bestehenden Komponenten.

Hätte eine SBOM einen Vorfall wie den XZ-Utils-Backdoor schneller sichtbar gemacht?

Direkt verhindert hätte eine SBOM den Backdoor nicht, weil das Problem im Quellcode selbst lag, nicht in einer fehlenden Inventarisierung. Sie hätte aber die Reaktionszeit danach erheblich verkürzt: Unternehmen mit aktuellen SBOM-Beständen hätten per einfacher Textsuche in Sekunden feststellen können, in wie vielen Systemen die betroffene xz-Version 5.6.0 oder 5.6.1 tatsächlich verbaut war, statt jedes System einzeln zu prüfen. Genau diese schnelle Bestandsabfrage bei akuten Vorfällen nennt die IEEE-Analyse von 2025 als Hauptnutzen von SBOMs in der Post-Incident-Phase.

Weitere Hintergründe zu aktuellen Sicherheitsthemen finden Sie im Security-Bereich von shattered.io.

Quellen und weiterführende Informationen: OWASP CycloneDX-Projekt, Syft auf GitHub, offizielle Trivy-Dokumentation, SPDX-Spezifikation, Open Source Security Foundation, Sonatype State of the Software Supply Chain, BSI zu Software Bill of Materials und die EU-Kommission zum Cyber Resilience Act.