Die besten SBOM-Tools 2026

Die kurze Antwort

• Kostenlose SBOMs für Container-Images und Dateisysteme: Syft, oder Trivy, wenn Sie auch einen Scanner für Schwachstellen, Secrets und IaC möchten.
• CycloneDX aus Quellcode: cdxgen, aus der CycloneDX-Community.
• SPDX für ein Build-Ergebnis, das Sie bereits paketieren: das Microsoft SBOM Tool.
• Workloads auf AWS: der Amazon Inspector SBOM Generator, der Amazon Inspector speist.
• Eine schnelle SBOM eines GitHub-Repositorys: der Export des Abhängigkeitsgraphen von GitHub.
• Ein kostenloser, selbst gehosteter Ort zur Überwachung von SBOMs: OWASP Dependency-Track.
• Lizenz-Compliance zuerst: FOSSA. SBOMs von Lieferanten und Portfolios: Manifest oder Cybeats. Container-Flotten und Policy Packs für Behörden: Anchore Enterprise.
• Eine SBOM dessen, was Ihre eigenen Builds tatsächlich geladen haben, mit Schwachstellenüberwachung und Provenienzdaten: CRACI, für GitHub Actions.

Was ein SBOM-Tool leistet

Eine Software Bill of Materials listet die Komponenten, Bibliotheken und Abhängigkeiten in einer Software auf, in einem maschinenlesbaren Format wie CycloneDX oder SPDX. SBOM-Tools gibt es in zwei Arten. Generatoren schreiben die SBOM. Manager speichern SBOMs vieler Produkte und Lieferanten, gleichen sie mit Schwachstellendaten ab, wenden Policies an und teilen sie. Manager hängen davon ab, was Generatoren ihnen liefern.

Wann die SBOM erstellt wird, ist so wichtig wie das Tool, das sie erstellt. Der CISA-Leitfaden zu SBOM-Typen unterscheidet eine Source-SBOM, erstellt aus der Entwicklungsumgebung und den Quelldateien, eine Build-SBOM, erzeugt beim Bauen des veröffentlichungsfähigen Artefakts, und eine Analyzed-SBOM, erzeugt durch die Analyse von Artefakten wie ausführbaren Dateien und Container-Images nach dem Build. Die meisten Generatoren unten erzeugen Source- oder Analyzed-SBOMs. CRACI erzeugt eine Build-SBOM. Build-Time-SBOMs erklärt den Unterschied im Detail.

Für wen das gedacht ist

Diese Seite richtet sich an Teams, die SBOMs brauchen, für den Cyber Resilience Act, einen Kundenfragebogen oder ihre eigene Schwachstellenarbeit, und sich einen Überblick über die Optionen verschaffen. Wir bauen CRACI, berücksichtigen Sie das also. Jede Aussage über ein anderes Tool stammt aus dessen eigener Dokumentation, und zu jedem Tool gibt es eine längere Seite CRACI vs. X.

So wählen Sie ein SBOM-Tool

• Müssen Sie SBOMs erzeugen, verwalten oder beides? Ein Generator gibt Ihnen eine Datei. Ein Manager gibt Ihnen einen Ort, um Dateien vieler Produkte und Lieferanten aufzubewahren, anzureichern und darauf zu reagieren.
• Ist die Software Ihre eigene oder zugekauft? Bei eigenen Builds kontrollieren Sie den Input und können ihn aufzeichnen. Bei Lieferanten-Software brauchen Sie Aufnahme, Validierung und manchmal Binäranalyse.
• Wie sicher müssen Sie sein, dass die Liste vollständig ist? Generatoren lesen Dateien im Nachhinein, und sie widersprechen sich stärker, als die meisten erwarten (siehe unten). Eine Build-SBOM beschreibt, was der Build verwendet hat.
• Nach welchem Format fragen Ihre Kunden? CycloneDX und SPDX sind beide breit akzeptiert; die meisten Tools schreiben mindestens eines davon.
• Welches CI nutzen Sie, und muss es selbst gehostet sein? Open-Source-Generatoren laufen überall. CRACI unterstützt heute GitHub Actions unter Linux, als Managed Service; GitLab CI, Jenkins und vom Kunden gehostete Runner sind auf der Roadmap.

SBOM-Generatoren

Verglichen wird, was jeder Generator leistet, nicht wie viele Komponenten er liefert.

CRACI

CRACI ist ein Rekorder, kein Scanner. Ihre GitHub-Actions-Jobs laufen auf CRACI-Runnern, und ein paketbewusster Proxy zeichnet auf, was jeder Job lädt, einschließlich der aus einem CI-Cache wiederhergestellten Pakete. Die SBOM, in CycloneDX oder SPDX, enthält die transitiven Abhängigkeiten, die der Build verwendet hat, und gibt ihre Vollständigkeit pro Job und pro Cache an. CRACI bewertet überwachte SBOMs anschließend laufend neu und übernimmt so die Aufgabe von Generator und Manager zugleich. Ideal für Software, die Sie in GitHub Actions bauen. Zu beachten: Es kann kein Image und kein Verzeichnis scannen und führt heute Linux-Jobs auf GitHub Actions aus (weitere CI-Systeme, Windows und macOS sind auf der Roadmap). SBOM-Generierung in CRACI

Syft

Syft ist der kostenlose Generator von Anchore unter Apache-2.0 für Container-Images und Dateisysteme. Er erkennt Dutzende von Pakettypen, schreibt CycloneDX, SPDX und Syft JSON und kann signierte in-toto-SBOM-Attestierungen erstellen. Sein Begleiter Grype gleicht die SBOM mit Schwachstellen ab. Ideal für Images und für jede Pipeline, die einen kostenlosen Generator braucht. Zu beachten: Die Cataloger werden nach Scan-Typ gewählt, sodass bei einem installierten express-Checkout ein einziges Flag entscheidet, ob npm-Pakete überhaupt im Ergebnis erscheinen. CRACI vs. Syft und Grype

Trivy

Trivy von Aqua Security ist ein vielseitiger Scanner unter Apache-2.0 für Images, Dateisysteme, Repositories, VM-Images und Kubernetes. Er findet Schwachstellen, IaC-Fehlkonfigurationen, Secrets und Lizenzen und schreibt nebenbei CycloneDX oder SPDX. Ideal für Teams, die ein einziges kostenloses Binary für viele Sicherheitsprüfungen möchten. Zu beachten: Bei einem Repository liest er Lockfiles, sodass express 5.2.1 (kein Lockfile) und claude-code (kein Manifest) ihm nichts zu lesen geben, genau wie dokumentiert. CRACI vs. Trivy

cdxgen

cdxgen ist ein OWASP-CycloneDX-Projekt, das CycloneDX-BOMs aus Quellcode und Container-Images erstellt, unter Apache-2.0. Ideal für Teams, die auf CycloneDX standardisiert haben und einen Generator aus der Community des Formats möchten. Zu beachten: Wie die anderen Scanner kann es nur melden, was die vorliegenden Dateien deklarieren. CRACI vs. ein DIY-SBOM-Stack

Microsoft SBOM Tool

Das Microsoft SBOM Tool ist ein Generator unter MIT-Lizenz, der SPDX 2.2 oder auf Wunsch SPDX 3.0 schreibt und eine SBOM gegen die SPDX-Spezifikation validieren kann. Es erwartet auf der Kommandozeile einen Build-Drop-Ordner, einen Paketnamen, eine Version und einen Lieferanten, ist also ein Post-Build-Schritt, und es läuft in GitHub Actions und Azure Pipelines. Ideal für Teams, die SPDX für ein bereits paketiertes Build-Ergebnis möchten. Zu beachten: Auf Repositories im committeten Zustand gerichtet statt auf einen Build-Drop, hat es fast nichts zu beschreiben. Weil es auf der Kommandozeile einen Lieferanten entgegennimmt, kann es das Lieferantenfeld ausfüllen. CRACI vs. ein DIY-SBOM-Stack

GitHub dependency graph export

Der Abhängigkeitsgraph von GitHub fasst die Manifeste und Lockfiles eines Repositorys zusammen, dazu alles, was über die Dependency Submission API eingereicht wurde, und lässt sich über die UI oder REST API als SPDX exportieren. Er speist Dependabot-Warnungen und ist in jedem GitHub-Plan enthalten. Ideal für Teams, die bereits auf GitHub sind und schnell eine SBOM brauchen. Zu beachten: Er spiegelt den Default-Branch wider, nicht einen gepinnten Commit, und entsteht aus dem, was GitHub über das Repository weiß, nicht aus Dateien, die ein Scanner liest. CRACI vs. GitHub Advanced Security

Amazon Inspector SBOM Generator

Sbomgen ist der Generator hinter den eigenen Scans von Amazon Inspector für Images, Lambda und EC2, angeboten als eigenständiges Linux-Binary. Er liest Paketmetadaten aus Container-Images, Verzeichnissen, Archiven, eingehängten Volumes und kompilierten Go- und Rust-Binaries, deckt OS-Pakete (APK, DPKG, RPM) und Sprachen wie C#, Go, Java, Node.js, PHP, Python, Ruby und Rust ab und schreibt CycloneDX. Er kann die SBOM für Schwachstellenbefunde an die Amazon Inspector Scan API senden, wofür ein AWS-Konto nötig ist. Ideal für Teams, deren Workloads bereits auf AWS laufen. Zu beachten: Er läuft nur unter Linux, und wie die anderen Scanner findet er, was die gelesenen Dateien deklarieren.

Safeguard

Die CLI von Safeguard führt Syft und Grype aus, um CycloneDX- und SPDX-SBOMs aus Repositories, Container-Images und hochgeladenen Manifesten zu erzeugen, und die Plattform ergänzt von KI geschriebene Fix-Pull-Requests und Policy-Gates. Ideal für Teams, die Scanning und automatisierte Fixes in einem Abonnement möchten. Zu beachten: Wie die anderen Scanner listet es auf, was die gelesenen Dateien deklarieren. CRACI vs. Safeguard

Wovon eine gescannte SBOM abhängt

Richten Sie die Generatoren oben auf dasselbe Repository, und sie liefern unterschiedliche Listen. Das sind die Muster, die die eigene Dokumentation der Tools vorhersagt:

• Tools sind sich uneins, was als Komponente zählt. Jeder Generator entscheidet selbst, welchen Dateien er vertraut und wie er das Gefundene benennt, sodass ein Repository jedem von ihnen eine andere Liste liefert.
• Kein Lockfile, keine Abhängigkeiten. Express 5.2.1 committet keines, also meldet ein Generator, der Abhängigkeiten aus Lockfiles auflöst, keine seiner npm-Abhängigkeiten und liefert, was er sonst erkennt.
• Gar kein Manifest. Das Repository claude-code hat weder Manifest noch Lockfile, also ist das, was jedes Tool liefert, aus anderen Dateitypen zusammengesetzt und sagt mehr über das Tool als über das Projekt.
• Dünne Metadaten. Das Lieferantenfeld bleibt oft leer, weil die meisten Generatoren keine Quelle dafür haben.

Keines dieser Tools ist kaputt. Jedes liest die Dateien, die vor ihm liegen, wie vorgesehen. Die Lehre daraus: Eine gescannte SBOM hängt vom Tool, seinen Einstellungen und davon ab, ob jemand vorher die Abhängigkeiten installiert hat. Was Syft, Trivy und cdxgen jeweils lesen, zeigt was Open-Source-SBOM-Generatoren übersehen.

SBOM-Manager

Anchore Enterprise

Anchore Enterprise baut auf Syft und Grype auf und ergänzt, was große Organisationen brauchen: SBOMs für Container, Quellcode und Dateisysteme, importierte SBOMs mit Schema-Validierung, kontinuierliches erneutes Scannen ohne das ursprüngliche Artefakt und Policy Packs für FedRAMP, NIST, CIS, PCI DSS und CMMC. Es wird auf Kubernetes, mit Docker Compose oder air-gapped betrieben. Ideal für Container-Flotten über mehrere CI-Systeme hinweg und für die Arbeit mit Behörden. Zu beachten: Seine SBOMs beschreiben weiterhin, was ein Scanner gefunden hat, und Preise gibt es nur auf Anfrage. CRACI vs. Anchore

FOSSA

FOSSA begann mit Lizenz-Compliance: Volltext-Lizenzerkennung, Policies und Attribution Notices. Es erzeugt und importiert SPDX- und CycloneDX-SBOMs, kann VDR- oder VEX-Statements ergänzen, prüft Importe gegen die Mindestelemente von NTIA und FDA und teilt SBOMs im Enterprise-Plan über ein Portal. Der Free-Plan umfasst 5 Projekte. Ideal für Teams, deren erste Sorge das Lizenzrisiko ist. Zu beachten: Seine CLI fragt Ihre Build-Tools ab, wenn ein funktionierender Build vorliegt, und leitet andernfalls aus dem Quellcode ab, und Binär- und Snippet-Scanning sind Add-ons. CRACI vs. FOSSA

Cybeats SBOM Studio

SBOM Studio bezeichnet sich als „the SBOM system of record“. Es importiert und exportiert SPDX 2.2 bis 3.0.1 und CycloneDX 1.2 bis 1.7, bewertet die SBOM-Qualität vor dem Import, gleicht jede Komponente laufend ab und teilt SBOM- und VEX-Daten mit Kunden, auch über die Transparency Exchange API. Ideal für Produktsicherheitsteams in ICS, Medizintechnik, Telekommunikation und Automobilindustrie, die ein SBOM-Programm betreiben. Zu beachten: Es verwaltet SBOMs, statt sie zu erzeugen, und ein Quality Score bestätigt das Format, nicht das, was der Generator übersehen hat. CRACI vs. Cybeats und Cybeats-Alternativen

Manifest

Manifest sammelt SBOMs über Ihre Produkte, Ihre Hersteller und Ihre KI-Modelle hinweg, reichert sie an und teilt sie. Hersteller laden über ein sicheres Portal hoch, und wenn sie keine SBOM liefern, kann Manifest das Binary analysieren und eine erzeugen. Es unterstützt SPDX, CycloneDX und VEX und bildet FDA-Leitlinien, NIST 800-218 und UNECE R155 ab. Ideal für Organisationen, deren Hauptrisiko zugekaufte Software ist. Zu beachten: Seine GitHub Action erzeugt First-Party-SBOMs standardmäßig mit Syft. CRACI vs. Manifest

OWASP Dependency-Track

Dependency-Track ist eine Plattform unter Apache 2.0, die Komponenten über jede Version jeder Anwendung hinweg verfolgt, Schwachstellendaten aus Quellen wie NVD und GitHub Advisories bezieht, Sicherheits-, Lizenz- und Betriebs-Policies anwendet und CycloneDX VEX verarbeitet und erzeugt. Pipelines laden SBOMs über die API hoch. Ideal für Teams, die eine transparente, selbst gehostete Analyseplattform möchten. Zu beachten: Die Plattform erzeugt keine SBOMs, und Sie betreiben sie selbst (der API-Server braucht mindestens 2 GB RAM und 2 CPU-Kerne). CRACI für Nutzer von Dependency-Track

CycloneDX oder SPDX

Beide Formate sind offene Standards, und die meisten Tools auf dieser Seite schreiben mindestens eines davon. CycloneDX ist ein OWASP-Projekt, von Ecma International als ECMA-424 standardisiert, und enthält neben der Komponentenliste auch Schwachstellen- und VEX-Daten. SPDX ist ein Projekt der Linux Foundation und ein internationaler Standard, ISO/IEC 5962:2021. Der Cyber Resilience Act verlangt „ein gängiges und maschinenlesbares Format“, ohne eines zu nennen, wählen Sie also das Format, das Ihre Kunden und nachgelagerten Tools lesen. SBOM-Beispiele zeigt beide im direkten Vergleich, und SBOM Best Practices zeigt, wie Sie damit arbeiten. Zum Speichern und Überwachen von SBOMs im großen Maßstab siehe SBOM-Management.

Wo CRACI ansetzt

CRACI ist weder Scanner noch Manager. Es ist ein Rekorder. Ihre GitHub-Actions-Jobs laufen auf CRACI-Runnern (ändern Sie runs-on auf craci), und ein paketbewusster Proxy zeichnet auf, was jeder Job von npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen lädt, dazu Download-Presets. Aus einem CI-Cache wiederhergestellte Pakete tragen ihre Nachweise weiter. Die SBOM, in CycloneDX oder SPDX, enthält die transitiven Abhängigkeiten, die der Build verwendet hat, und gibt ihre Vollständigkeit pro Job und pro Cache an: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit.

Nach dem Build bewertet CRACI überwachte SBOMs laufend neu, führt Schwachstellen über Builds und Repositories hinweg zusammen, unterstützt VEX, liefert über seine API SBOMs, Netzwerk-Traces und Provenienz und exportiert SBOMs als CycloneDX- oder SPDX-Dateien. SBOMs von Herstellern können hinzugefügt werden, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds überwacht werden. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen. Den vollen Funktionsumfang beschreibt SBOM-Generierung in CRACI.

CRACI übernimmt also die Aufgabe von Generator und Manager zugleich, für die Software, die Sie bauen. Es ist nicht die richtige Wahl, wenn:

• Sie SBOMs für Images oder Software brauchen, die Sie nicht gebaut haben (nutzen Sie einen Generator wie Syft oder Trivy),
• Sie eine ausgereifte Policy-Engine mit vielen Regeltypen über ein Portfolio von Produkten und Lieferanten brauchen (nutzen Sie einen Manager),
• Ihre Pipelines außerhalb von GitHub Actions oder unter Windows oder macOS laufen oder selbst gehostet sein müssen (alles auf der Roadmap von CRACI).

Am schnellsten urteilen Sie im direkten Vergleich: Buchen Sie eine Demo, lassen Sie einen Ihrer Workflows auf CRACI laufen und legen Sie seine SBOM neben die, die Ihr aktuelles Tool erzeugt.

Siehe auch SCA-Tools im Vergleich, KI-generierte SBOMs vs. Build-Time-SBOMs und warum sich Build-Time-SBOMs von gescannten unterscheiden.

SBOM-Tools: häufig gestellte Fragen

Was ist ein SBOM-Tool?

Ein SBOM-Tool erzeugt oder verwaltet eine Software Bill of Materials: eine maschinenlesbare Liste der Komponenten, Bibliotheken und Abhängigkeiten in einer Software. Generatoren wie Syft, Trivy und cdxgen schreiben die SBOM, indem sie Dateien lesen. Manager wie Dependency-Track, FOSSA und Anchore Enterprise speichern SBOMs, gleichen sie mit Schwachstellendaten ab und teilen sie. CRACI zeichnet die SBOM während des Builds selbst auf und überwacht sie anschließend.

Was ist das beste kostenlose SBOM-Tool?

Das hängt davon ab, worauf Sie es richten. Syft und Trivy sind kostenlose Generatoren unter Apache-2.0 für Container-Images und Dateisysteme. cdxgen schreibt CycloneDX aus Quellcode und Images. Das Microsoft SBOM Tool schreibt SPDX für einen Build-Ausgabeordner. OWASP Dependency-Track ist ein kostenloser, selbst gehosteter Manager für die SBOMs, die diese Tools erzeugen.

Sollte ich Syft oder Trivy nutzen?

Syft konzentriert sich auf die SBOM-Generierung und arbeitet für den Schwachstellenabgleich mit Grype zusammen. Trivy ist ein breiterer Scanner, der auch IaC-Fehlkonfigurationen, Secrets und Lizenzen findet und nebenbei CycloneDX oder SPDX schreibt. Beide lesen die Dateien, die vor ihnen liegen, also hängen beide davon ab, dass Lockfiles oder installierte Pakete vorhanden sind.

CycloneDX oder SPDX: Welches SBOM-Format sollte ich nutzen?

Beide sind offene, breit unterstützte Standards. CycloneDX ist ein OWASP-Projekt, von Ecma International als ECMA-424 standardisiert, und enthält auch Schwachstellen- und VEX-Daten. SPDX ist ein Projekt der Linux Foundation und ein internationaler Standard, ISO/IEC 5962:2021. Nutzen Sie das Format, nach dem Ihre Kunden und nachgelagerten Tools fragen; die meisten Generatoren schreiben beide.

Warum liefern SBOM-Tools für dasselbe Projekt unterschiedliche Ergebnisse?

Jeder Generator entscheidet selbst, welchen Dateien er vertraut und was als Komponente zählt. Manche lesen Lockfiles, manche installierte Pakete, manche Binärdateien, und ein Repository ohne Lockfile gibt einem Lockfile-Leser nichts zu tun. Eine gescannte SBOM hängt vom Tool, seinen Einstellungen und davon ab, ob die Abhängigkeiten vor dem Scan installiert wurden. Eine Build-Time-SBOM vermeidet das, weil sie aufzeichnet, was der Build tatsächlich geladen hat.

Schreibt der Cyber Resilience Act ein bestimmtes SBOM-Tool oder -Format vor?

Nein. Anhang I Teil II des CRA verlangt von Herstellern eine Software-Stückliste in einem gängigen und maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten der Produkte erfasst. CycloneDX und SPDX erfüllen das beide. Die Verordnung nennt kein Tool.

Kann CRACI eine SBOM für Software erzeugen, die ich nicht selbst gebaut habe?

Nein. CRACI zeichnet die Builds auf, die auf seinen Runnern laufen, seine SBOMs beschreiben also Software, die Sie bauen. Bei zugekaufter Software können Sie die SBOM des Herstellers zu CRACI hinzufügen und sie zusammen mit Ihren eigenen Builds überwachen. Für ein Container-Image eines Drittanbieters, das Sie nicht gebaut haben, ist ein Scanner wie Syft oder Trivy die praktische Wahl.

Welche CI-Systeme unterstützt CRACI?

Heute GitHub Actions, auf Linux-Runnern mit x86-64 und ARM64. Sie ändern runs-on auf craci, und die Läufe erscheinen weiterhin in GitHub. Weitere CI-Systeme, zunächst GitLab CI und Jenkins, sind auf der Roadmap.