SBOM Tools im Vergleich 2026 — Open Source und kommerzielle Lösungen

Wer sich mit SBOM Management unter dem Cyber Resilience Act beschäftigt, steht vor einer unübersichtlichen Toollandschaft. Es gibt Dutzende Werkzeuge, aber sie lösen unterschiedliche Probleme. Die entscheidende Unterscheidung: SBOM-Generatoren erzeugen die Software-Stückliste aus Quellcode, Build-Artefakten oder Container-Images. SBOM-Management-Plattformen nehmen diese SBOMs entgegen, speichern sie zentral, korrelieren sie mit Schwachstellendatenbanken und ermöglichen Richtlinien-basierte Workflows.

Viele Unternehmen brauchen beides: einen Generator in der CI/CD-Pipeline und eine Plattform für die zentrale Verwaltung. Einige kommerzielle Anbieter bündeln beide Funktionen, was die Auswahl vereinfacht — aber auch die Abhängigkeit erhöht.

Hauptvergleich: 12 SBOM-Tools im Überblick

Die folgende Tabelle vergleicht die wichtigsten Funktionen aller relevanten Tools. „Erzeugt SBOM" bedeutet, dass das Tool selbst SBOMs aus Quellcode oder Artefakten generieren kann. „Verwaltet SBOM" bedeutet, dass importierte SBOMs zentral gespeichert, versioniert und durchsucht werden können. Die Preiskategorien beziehen sich auf typische Unternehmensgrößen von 50 bis 500 Entwicklern.

Ein paar Erläuterungen: Grype ist kein SBOM-Generator, sondern ein Schwachstellen-Scanner, der SBOMs als Input akzeptiert — deshalb das Häkchen bei Vuln-Monitoring, aber nicht bei Erzeugung. Dependency-Track erzeugt ebenfalls keine SBOMs, ist aber die zentrale Open-Source-Plattform für deren Verwaltung. Die kommerziellen Plattformen integrieren Erzeugung und Verwaltung in einer Oberfläche, was den Einstieg vereinfacht, aber die Flexibilität bei der Wahl des Generators einschränkt.

Bei den Formaten fällt auf: CycloneDX wird von allen Tools unterstützt. SPDX-Support ist bei cdxgen und CycloneDX CLI nicht vorhanden, was logisch ist — beide sind CycloneDX-native Werkzeuge. Für Unternehmen, die SPDX benötigen (z. B. wegen Yocto-basierten Embedded-Produkten), schränkt das die Auswahl auf der Open-Source-Seite auf Syft und Trivy ein.

Entscheidungsmatrix nach Unternehmensgröße

Die Toolwahl hängt weniger von Features ab als von der Anzahl der zu verwaltenden Produkte und der vorhandenen Infrastruktur. Die folgende Matrix gibt Orientierung:

Für Startups ist der Einstieg denkbar einfach: Syft erzeugt in einer GitHub Action eine CycloneDX-SBOM, Grype prüft sie auf bekannte Schwachstellen. Das Ergebnis wird als Build-Artefakt abgelegt. Kosten: null Euro, Einrichtungszeit: unter einer Stunde.

Im Mittelstand steigt die Komplexität. Bei fünf bis zehn Produkten mit jeweils eigenen Dependency-Bäumen braucht man eine zentrale Stelle, die alle SBOMs aggregiert und Schwachstellen-Alerts korreliert. Dependency-Track füllt genau diese Lücke. Der Aufwand liegt im Self-Hosting: PostgreSQL-Datenbank, ausreichend RAM (mindestens 8 GB für die API-Server-Instanz), regelmäßige Updates der Vulnerability-Datenbanken.

Im Konzern-Umfeld rechtfertigt die Masse an Repositories den Einsatz einer kommerziellen Plattform. Snyk und Sonatype bieten beide automatische PR-Erstellung bei neuen Schwachstellen, Lizenz-Compliance-Prüfung und Integration in Jira/ServiceNow. Einige Konzerne betreiben zusätzlich Dependency-Track als internen Aggregator, um Vendor-Lock-in zu begrenzen.

CRA-Pflichten-Abdeckung durch SBOM-Tools

Der CRA definiert konkrete Pflichten rund um Software-Transparenz. Die Frage ist: Welche davon kann ein Tool technisch unterstützen, und welche sind organisatorische Aufgaben, die kein Tool abnimmt?

Die letzte Zeile ist die wichtigste: Kein Tool erstellt automatisch die technische Dokumentation nach Anhang II des CRA. Dieser Anhang verlangt unter anderem eine Beschreibung des Designs und der Entwicklung des Produkts, eine Risikobewertung der Cybersicherheit, Testberichte und Informationen über den Umgang mit Schwachstellen während des gesamten Produktlebenszyklus. Das ist ein Dokumentationsaufwand, der im Qualitätsmanagement oder der Produktdokumentation liegt — nicht in der Toolchain.

Auch die 24-Stunden-Meldepflicht bei aktiv ausgenutzten Schwachstellen (Artikel 14 CRA) ist nur halb technisch lösbar. Tools wie Dependency-Track, Snyk und Sonatype können einen Alert auslösen, wenn eine Schwachstelle in einer Komponente bekannt wird. Aber die Bewertung, ob das eigene Produkt betroffen ist, die Erstellung des VEX-Statements und die Meldung an das zuständige CSIRT sind menschliche Aufgaben mit definierten Verantwortlichkeiten.

Was kein Tool abdeckt

Die CRA-Compliance hat drei Ebenen: Technik, Prozess und Organisation. SBOM-Tools bedienen die technische Ebene. Aber sie ersetzen weder den Incident-Response-Prozess, der bei einer kritischen Schwachstelle innerhalb von 24 Stunden eine Erstmeldung an die ENISA-Plattform liefert, noch die juristische Prüfung, ob ein Produkt überhaupt in den Anwendungsbereich des CRA fällt, noch die Risikobewertung, die für jede Produktkategorie (Default, Klasse I, Klasse II) durchzuführen ist.

Wer ein SBOM-Tool evaluiert, sollte daher nicht fragen „welches hat die meisten Features?", sondern: Kann mein Team mit diesem Tool innerhalb von 24 Stunden auf eine Schwachstellenmeldung in einer beliebigen Komponente reagieren — mit einer belastbaren Aussage, ob unser Produkt betroffen ist? Wenn die Antwort ja lautet, ist das Tooling ausreichend. Alles andere ist Optimierung.