Die besten SBOM-Tools 2026: von der Erstellung bis zur Compliance im Vergleich
| Interlynk
Warum es kein einzelnes bestes SBOM-Tool gibt
Eine Software Bill of Materials ist eine maschinenlesbare Liste dessen, was in einer Software steckt. Die Grundidee ist einfach. Die eigentliche Arbeit beginnt, wenn ein Kunde oder eine Behörde die Liste in einem bestimmten Format verlangt, erwartet, dass sie aktuell bleibt, und Jahre nach der Auslieferung Nachweise dazu einfordert.
Der EU Cyber Resilience Act, die vormarktlichen Cybersecurity-Vorgaben der FDA und die NTIA-Mindestelemente weisen alle auf denselben Grundbedarf hin: ein genaues, maschinenlesbares Inventar. Keines davon schreibt ein bestimmtes Produkt zu dessen Erstellung vor.
Das macht "bestes SBOM-Tool" zu einer Frage, die sich schwer mit einem einzigen Sieger beantworten lässt. Die Produkte in dieser Kategorie erfüllen unterschiedliche Aufgaben. Einige erstellen das Inventar. Einige speichern und überwachen es über die Zeit. Andere prüfen es auf Schwachstellen oder kümmern sich um Lizenzpflichten. Dieser Leitfaden gruppiert die führenden Optionen danach, was sie tatsächlich leisten, einschließlich der Fälle, in denen sie schlecht passen.
So wählen Sie ein SBOM-Tool aus
Beginnen Sie mit der Aufgabe, die das Tool erfüllen soll. Ein Team, das einem Kunden nur eine Komponentenliste schicken muss, braucht einen Generator und wenig mehr. Ein Team, das vierzig Produkte verwaltet, Behörden Rede und Antwort steht und Schwachstellen über mehrere Jahre verfolgt, braucht eine Management-Plattform, die von einem oder mehreren Generatoren gespeist wird. Die meisten Auswahllisten gehen schief, weil sie Produkte vergleichen, die auf unterschiedlichen Ebenen des Ablaufs sitzen.
Innerhalb einer Ebene sind meist diese sechs Fragen entscheidend:
Format. CycloneDX und SPDX sind beide weit verbreitet. Wenn ein Kunde oder eine Behörde eines davon verlangt, wählen Sie ein Tool, das das benötigte Format unterstützt. Unterstützung für beide erspart Ihnen später eine Migration. Die Abwägungen zeigt unser Vergleich CycloneDX vs SPDX.
Abdeckung. Sehen Sie sich an, welche Paket-Ökosysteme, Containerformate, Sprachen und Build-Systeme das Tool wirklich versteht. Eine lange Liste unterstützter Technologien ist weniger wert als verlässliche Abdeckung der Technologien in Ihren eigenen Produkten.
Erstellungsmethode. Binär-Scanner, Container-Scanner, Manifest-Leser und in den Build integrierte Tools sehen jeweils einen anderen Teil der Abhängigkeiten. Hineinkopierter C/C++-Code und Firmware werden am leichtesten übersehen.
Lebenszyklus-Unterstützung. Sobald SBOMs aufbewahrt und wiederverwendet werden, brauchen Sie Versionshistorie, Schwachstellenüberwachung, VEX und Drift-Erkennung. Eine Datei einmal zu erzeugen ist eine andere Aufgabe, als sie über die gesamte Produktlebensdauer zu verwalten.
Compliance. Eine Komponentenliste ist kein Prüfnachweis. Um die Ausrichtung an FDA 524B, dem EU CRA, NTIA oder BSI TR-03183 zu belegen, achten Sie auf regulierungsspezifische Prüfungen und aufbewahrte Nachweise.
Betriebsmodell. Selbst gehostete Open Source, verwaltete kommerzielle Software und vollständig air-gapped Deployments bringen sehr unterschiedliche Abwägungen mit sich. Für viele Teams grenzt diese Randbedingung die Auswahl schneller ein als jedes einzelne Feature.
SBOM-Generatoren (Erstellung)
Generatoren erstellen das erste Inventar. Für gängigen Anwendungscode decken die Open-Source-Optionen unten viel ab und reichen einem Team oft aus. Die Lücken zeigen sich bei Binärdateien ohne brauchbares Manifest, bei eingebetteter Firmware, bei hineinkopiertem Quellcode und bei Builds, die Sie in einem Audit verteidigen müssen. Genau dort spielen kommerzielle Tools ihre Stärke aus.
Tool | Lizenz | Formate | Abdeckung | Am besten für |
|---|---|---|---|---|
Syft | Open Source | CycloneDX, SPDX | Container und Paket-Ökosysteme | Allgemeine Erstellung und Container |
cdxgen | Open Source | CycloneDX (SPDX verfügbar) | Viele Sprachen und Container | Teams, die auf CycloneDX standardisieren, und breite Sprachabdeckung |
Trivy | Open Source | CycloneDX, SPDX | Container, Pakete und IaC | Teams, die Trivy bereits zum Scannen nutzen |
Microsoft SBOM Tool | Open Source | SPDX | Zur Build-Zeit, mehrsprachig | SPDX-orientierte und Microsoft-zentrierte Builds |
lynkctl (Interlynk) | Kommerziell | CycloneDX 1.6+, SPDX 3+ | 12 Manifest-Ökosysteme plus Embedded C/C++ | Firmware, regulierte Builds und air-gapped Umgebungen |
Syft, von Anchore, ist ein häufiger Ausgangspunkt. Es untersucht Container-Images und viele Paket-Ökosysteme, erzeugt CycloneDX oder SPDX und übergibt Ergebnisse an Grype zum Scannen. Es liefert gute Ergebnisse, wenn Paket-Metadaten vorhanden sind. Es gibt Ihnen weniger an die Hand, wenn Abhängigkeiten in einen Quellbaum kopiert oder in Firmware verborgen sind.
cdxgen ist der eigene Generator des CycloneDX-Projekts, was es zur naheliegenden Wahl für Teams macht, die auf CycloneDX standardisiert haben. Seine Sprachabdeckung ist breit. Bei C/C++ arbeitet es am besten, wenn es einen echten Build inspizieren kann, und die Ergebnisse können unvollständig sein, wenn Abhängigkeiten in das Projekt kopiert statt in einem Manifest deklariert werden. Diesen Fall zerlegen wir in cdxgen vs lynkctl.
Trivy, von Aqua Security, ist vor allem als Scanner bekannt und erzeugt außerdem SBOMs für Container und paketbasierte Projekte. Der Reiz ist praktisch: Wenn Trivy bereits in Ihrer CI läuft, erhalten Sie SBOMs, ohne ein weiteres großes Tool hinzuzufügen.
Microsoft SBOM Tool erzeugt SPDX-Ausgaben zur Build-Zeit über mehrere Sprachen hinweg. Nichts Spektakuläres. Es ist eine solide Option für Organisationen, die auf SPDX standardisiert haben oder ohnehin stark auf das Microsoft-Entwicklungs- und Build-Ökosystem setzen.
lynkctl ist der kommerzielle Generator von Interlynk für Embedded C/C++ und andere Softwareprojekte. Es zielt auf den Fall, den ein Allzweck-Generator am schlechtesten bewältigt: Firmware-Abhängigkeiten, die in den Quellbaum kopiert sind, Hersteller-SDKs oder statische Archive, die zum Build gehören, aber in keinem Paket-Manifest genannt werden.
Statt aus Dateien zu raten, liest lynkctl Build-Informationen aus Make-, CMake-, IAR- und TI-Code-Composer-Projekten, unterstützt neben Embedded-Workflows ein Dutzend Manifest-Ökosysteme, erzeugt CycloneDX 1.6+ und SPDX 3+ und läuft ohne Netzwerkzugriff für air-gapped Umgebungen. Sie liefern keine Firmware aus? Dann sind die Open-Source-Generatoren oben genau richtig für Sie.
SBOM-Management- und Monitoring-Plattformen
Das SBOM zu erzeugen ist der leichtere Teil. Die längerfristige Arbeit besteht darin, es aufzubewahren, es bei jeder neuen CVE erneut zu prüfen, zu wissen, welche Version in welchem Release ausgeliefert wurde, und diese Historie bereitzustellen, wenn eine Prüfstelle fragt. Das ist die Aufgabe einer Management-Plattform.
Tool | Lizenz | Nimmt auf | Monitoring | VEX | Compliance | Hosting |
|---|---|---|---|---|---|---|
OWASP Dependency-Track | Open Source | CycloneDX | Kontinuierlich | Basis | Allgemein | Selbst gehostet |
Interlynk | Kommerziell | CycloneDX, SPDX | Kontinuierlich | Vollständiger Lebenszyklus | FDA 524B, CRA, NTIA | Verwaltet, mit kostenloser Version |
Anchore Enterprise | Kommerziell | CycloneDX, SPDX | Kontinuierlich | Ja | Richtlinienbasiert | Verwaltet oder selbst gehostet |
FOSSA | Kommerziell | CycloneDX, SPDX | Kontinuierlich | Ja | Lizenzfokussiert | Verwaltet |
SBOM Observer | Kommerziell | CycloneDX, SPDX | Kontinuierlich | Ja | Allgemein | Verwaltet |
OWASP Dependency-Track ist die bekannteste Open-Source-Plattform in dieser Gruppe. Speisen Sie es mit CycloneDX, und es überwacht Komponenten anhand von Schwachstellendaten, während Sie ein Portfolio von Anwendungen verwalten. Es erzeugt keine SBOMs, Sie bringen also einen separaten Generator mit, und Ihr Team hostet und pflegt die Plattform. Die wichtigsten Optionen zeigt unser Vergleich Dependency-Track-Alternativen.
Interlynk ist die verwaltete Plattform in dieser Liste, lesen Sie dies also so, wie Sie jeden Anbieter lesen würden, der sein eigenes Produkt beschreibt. Es deckt die Erstellung ab, einschließlich Embedded-Workflows über lynkctl, dazu Speicherung, kontinuierliches Monitoring, VEX und Compliance-Prüfungen für FDA 524B, den EU CRA und NTIA. Es unterstützt sowohl CycloneDX als auch SPDX und enthält eine kostenlose Version. Es passt zu Teams, die regulierte Produkte verwalten, die eine Audit-Historie benötigen, darunter Medizingerätehersteller wie BIOTRONIK. Wenn Sie lediglich CVE-Monitoring für eine interne Anwendung brauchen, leistet Dependency-Track das kostenlos.
Anchore Enterprise bündelt die Open-Source-Tools Syft und Grype mit Policy-Gates und Reporting für die CI/CD. Es ist der naheliegende Schritt für Teams, die überwiegend Container ausliefern und wollen, dass die Pipeline selbst Sicherheits- oder Compliance-Regeln durchsetzt.
FOSSA begann bei der Open-Source-Lizenz-Compliance und erweiterte sich später um SBOM- und Schwachstellen-Management. Der Schwerpunkt liegt weiterhin auf Lizenzierung, es passt also am besten, wenn rechtliche und Beschaffungsanforderungen das Projekt treiben.
SBOM Observer ist eine leichtere verwaltete Option für Teams, die einen gehosteten Ort zum Aufbewahren und Überwachen von SBOMs wollen, ohne Dependency-Track selbst zu betreiben oder eine umfassendere Compliance-Plattform einzuführen.
Schwachstellen-Scanner, die zu SBOMs passen
Einige Tools konzentrieren sich darauf, ein SBOM zu lesen und verwundbare oder ausnutzbare Komponenten zu erkennen, statt das Inventar zu erzeugen oder zu verwalten. Grype, ebenfalls von Anchore, ist der vertraute Begleiter von Syft: mit dem einen erzeugen, mit dem anderen scannen. OSV-Scanner, von Google, prüft Abhängigkeiten gegen die OSV-Datenbank. Snyk ist die kommerzielle, entwicklerorientierte Option mit breiterer Application-Security-Abdeckung, die auch SBOMs importiert und überwacht.
Die meisten der oben genannten Management-Plattformen enthalten bereits Schwachstellenüberwachung. Ein separater Scanner verdient seinen Platz vor allem, wenn Sie einen Open-Source-Ablauf zusammenstellen oder bereits einen bevorzugten Scanner in Ihrem Entwicklungsprozess haben.
SBOM-Tools für Firmware und vernetzte Geräte
Firmware bricht mit den Annahmen vieler anwendungsorientierter Tools. Abhängigkeiten tauchen möglicherweise gar nicht in einem Paket-Manifest auf, und Geräteregulierungen wie der CRA und die vormarktliche FDA-Leitlinie legen mehr Gewicht auf die Qualität der Nachweise hinter dem SBOM.
ONEKEY analysiert kompilierte Firmware-Binärdateien, was Teams passt, die vernetzte Produkte bewerten und sich auf CRA-Anforderungen vorbereiten. Finite State deckt Produkt- und Lieferkettensicherheit für vernetzte und eingebettete Geräte ab, einschließlich Firmware- und SBOM-Analyse. Für Teams, die ein Embedded-C/C++-SBOM aus dem Build statt nur aus dem ausgelieferten Image erzeugen wollen, adressiert lynkctl einen anderen Teil des Problems. Ein build-bewusster Generator und ein Binäranalyse-Tool ergänzen sich, weil sie von unterschiedlichen Nachweisen ausgehen und unterschiedliche Probleme zutage fördern.
So ordnen Sie ein Tool Ihrem Anwendungsfall zu
Die richtige Wahl hängt vom Produkt und vom Ablauf ab. Dies sind sinnvolle Ausgangspunkte:
Open-Source-Stack mit knappem Budget: Syft oder cdxgen zur Erstellung, Dependency-Track zur Verwaltung und Grype oder OSV-Scanner zum Scannen. Ihr Team stellt den Stack zusammen und hostet ihn.
Ein reguliertes Produkt, das geprüft wird: eine verwaltete Plattform mit Compliance-Prüfungen und aufbewahrter Historie, etwa Interlynk, plus der Generator, der am besten zu Ihren Quell- und Build-Systemen passt.
Container in weiten Teilen der Umgebung: Syft oder Trivy zur Erstellung, dann Anchore Enterprise oder Dependency-Track für Policy und Monitoring.
Firmware und vernetzte Geräte: ein build-bewusster Generator wie lynkctl, gepaart mit einer Binäranalyse-Plattform wie ONEKEY oder Finite State.
Lizenzprüfung ist die Hauptanforderung: FOSSA ist in dieser Liste die stärkste Wahl.
Sie wollen weg vom selbst gehosteten Dependency-Track: SBOM Observer oder eine andere verwaltete Plattform.
Die meisten Teams landen bei zwei Ebenen: einem Generator und einer Management-Plattform. Zwei Fragen klären in der Regel den Rest: Kann Ihr Team Open-Source-Infrastruktur betreiben, und müssen Sie Compliance nachweisen oder nur auf neue Schwachstellen achten?
Häufig gestellte Fragen
Was ist ein SBOM-Tool?
Ein SBOM-Tool erstellt oder verwaltet eine Software Bill of Materials, das maschinenlesbare Inventar der Komponenten in einer Software. Einige Tools erzeugen das Inventar, einige speichern und überwachen es über die Zeit, und einige decken beides ab.
Was ist das beste Open-Source-SBOM-Tool?
Zur Erstellung sind Syft und cdxgen am weitesten verbreitet, Trivy ist eine praktische Wahl, wenn Ihr Team es ohnehin zum Scannen nutzt. Zur Verwaltung ist OWASP Dependency-Track die Open-Source-Referenz. Ein üblicher kostenloser Stack ist Syft oder cdxgen zur Erstellung, Dependency-Track zur Verwaltung und Grype zum Scannen.
Sollte ich CycloneDX oder SPDX verwenden?
Beide Formate sind weit anerkannt. Manche Kunden, Behörden und internen Systeme verlangen ausdrücklich eines davon, Unterstützung für beide gibt Ihnen also mehr Flexibilität. Siehe CycloneDX vs SPDX für einen ausführlichen Vergleich.
Brauche ich einen separaten Generator und eine Management-Plattform?
Meist ja. Generatoren erstellen das SBOM; Management-Plattformen speichern es, überwachen neu gemeldete Schwachstellen, verfolgen Releases und bewahren die für Audits nötige Historie auf. Einige kommerzielle Plattformen decken beide Ebenen ab, sodass Sie ein Produkt betreiben, statt zwei zusammenzustellen.
Welches SBOM-Tool eignet sich am besten für Compliance?
Wenn Sie Compliance nachweisen müssen und nicht nur CVEs verfolgen, achten Sie auf regulierungsspezifische Prüfungen und eine aufbewahrte, audit-fähige Historie. Interlynk deckt FDA 524B, den EU CRA und NTIA ab; Anchore ergänzt Policy-Durchsetzung in der Pipeline; FOSSA ist am stärksten, wenn Lizenzierung im Vordergrund steht. Ordnen Sie das Tool der Regulierung und den Nachweisen zu, die Ihre Organisation erbringen muss.
Welches SBOM-Tool eignet sich am besten für Embedded-Firmware?
Firmware-Abhängigkeiten fehlen oft in Paket-Manifesten, daher passt ein build-bewusster Generator wie lynkctl oder ein Firmware-Binäranalyzer wie ONEKEY oder Finite State besser als ein Allzweck-Generator. Siehe cdxgen vs lynkctl.