Skip to main content

Open-Source-SBOM-Tools sind Softwarelösungen, mit denen Sie Software-Stücklisten (SBOMs) mithilfe von offenem Quellcode erstellen, analysieren und verwalten können, den Sie prüfen und anpassen können. Wenn Sie nach Möglichkeiten suchen, Abhängigkeiten, Lizenzen und Sicherheitslücken in Ihrem gesamten Software-Stack im Blick zu behalten, wissen Sie, wie wichtig zuverlässige SBOM-Tools geworden sind.

In diesem Leitfaden finden Sie die besten Open-Source-SBOM-Optionen, mit denen Sie die Einhaltung von Vorschriften vereinfachen, Risiken überwachen und das SBOM-Management in Ihren bestehenden Arbeitsablauf integrieren können – unabhängig davon, wie komplex Ihre Umgebung wird.

Warum Sie unseren Software-Bewertungen vertrauen können

Zusammenfassung der besten Open-Source-SBOM-Tools

Diese Vergleichstabelle fasst die Preisdetails meiner Auswahl der besten Open-Source-SBOM-Tools zusammen, damit Sie das beste Tool für Ihr Budget und Ihre geschäftlichen Anforderungen finden können.

 

Tests der besten Open-Source-SBOM-Tools

Nachfolgend finden Sie meine ausführlichen Zusammenfassungen der besten Open-Source-SBOM-Tools, die es in meine engere Auswahl geschafft haben. Meine Tests bieten einen detaillierten Überblick über die Funktionen, Möglichkeiten und besten Anwendungsfälle jedes Tools, damit Sie das beste für Ihre Anforderungen finden.

Am besten für kontinuierliche Lizenz-Compliance

  • Kostenloser Tarif
  • Ab $20/Projekt/Monat (jährliche Abrechnung)

FOSSA ist eine Plattform für die Analyse von Softwarezusammensetzung (SCA), die SBOM-Generierung, Open-Source-Lizenzprüfung, Schwachstellenerkennung und Abhängigkeitsverfolgung über Codebasen, Container und Binärdateien hinweg vereint.

Für wen ist FOSSA am besten geeignet?

FOSSA ist besonders für Unternehmensentwicklungs- und Rechtsteams geeignet, die Open-Source-Lizenzverpflichtungen über große, mehrere Repositorien umfassende Codebasen hinweg verwalten.

Warum habe ich FOSSA ausgewählt?

Ich habe FOSSA in meine Top-Auswahl aufgenommen, weil es die Durchsetzung von Lizenzrichtlinien auf Pull-Request-Ebene ermöglicht. Im Gegensatz zu einem einmaligen Compliance-Audit führt FOSSA automatisierte Scans bei jedem Code-Commit durch und wendet konfigurierbare Lizenzrichtlinien an, mit denen nicht konforme Abhängigkeiten vor dem Merge blockiert werden können. Ebenfalls gefällt mir die automatische Generierung von Lizenzhinweisen, die gesetzlich erforderliche Open-Source-Anerkennungen direkt aus den Scan-Ergebnissen zusammenstellt.

FOSSA Hauptfunktionen

  • Multi-Ökosystem-Scanning: Erkennt Abhängigkeiten über mehr als 27 Programmiersprachen, Container, Binärdateien und Paketmanager hinweg.
  • SBOM-Format-Auswahl: Exportiert Stücklisten von Software sowohl im SPDX- als auch im CycloneDX-Format.
  • Drittanbieter-SBOM-Aufnahme: Akzeptiert und analysiert externe SBOMs für eine kombinierte Risikoanalyse auf Portfolioebene.
  • Automatisierte Schwachstellenerkennung: Identifiziert Open-Source-Schwachstellen und verknüpft diese mit SBOM-Komponenten.

FOSSA-Integrationen

FOSSA bietet native Integrationen mit GitHub, GitLab, Jenkins, Jira und Slack, stellt eine API für individuelle Integrationen bereit und unterstützt CI/CD-Workflows über sein CLI.

Pros and Cons

Pros:

  • Umfassende Lizenz- und Schwachstellen-Scanabdeckung
  • Automatisierte Erstellung von Compliance- und Lizenzhinweisberichten
  • Ausführliche Unterstützung bei der Aufnahme von Drittanbieter-SBOMs

Cons:

  • Kernplattform ist nicht vollständig Open Source
  • Manuelle Nachbearbeitung oft bei komplexen Ergebnissen erforderlich

Am besten geeignet zur Analyse von Abhängigkeiten in Container-Images

  • Nicht verfügbar
  • Für immer kostenlos

Tern ist ein Open-Source-Tool auf Python-Basis zur Erzeugung von Software Bill of Materials (SBOM), das Container-Images und Dockerfiles Schicht für Schicht analysiert. Dabei inventarisiert es Betriebssystempakete und Abhängigkeiten und verfolgt deren Herkunft über die Ausgabeformate SPDX und CycloneDX hinweg.

Für wen ist Tern am besten geeignet?

Tern ist besonders geeignet für DevSecOps-Ingenieur:innen und Sicherheitsteams, die containerisierte Workloads verwalten und eine detaillierte, schichtgenaue Komponentenübersicht benötigen.

Warum ich Tern ausgewählt habe

Tern hat es auf meine Auswahlliste geschafft, weil es Container-Pakete bis zur konkreten Dockerfile-Anweisung zurückverfolgt, durch die sie eingeführt wurden. Die meisten SBOM-Tools verraten, was in einem Container steckt; Tern zeigt, wie es dorthin gelangt ist. Besonders gefällt mir zudem das Feature für gesperrte Dockerfiles, das das Basissystem und die Pakete festschreibt und Builds damit aus einem dokumentierten, bekannten Komponentenstand reproduzierbar macht.

Wichtigste Funktionen von Tern

  • Analyse von mehrstufigen Dockerfiles: Analysiert und erzeugt SBOMs für jede Stufe in mehrstufigen Dockerfiles.
  • Mehrere SBOM-Ausgabeformate: Gibt SBOMs im SPDX-, CycloneDX-, menschenlesbaren, JSON-, HTML- und YAML-Format aus.
  • Offizielle GitHub Action: Führen Sie die Tern-Containeranalyse direkt in CI-Pipelines per gepflegter GitHub Action aus.
  • Erweiterungen für Scancode und cve-bin-tool: Lizenzprüfung und Schwachstellenscans können über optionale Erweiterungen integriert werden.

Tern Integrationen

Tern bietet native Integrationen mit GitHub Actions, Skopeo für den Zugriff auf Container-Registries und unterstützt Lizenz- und Schwachstellenscans über native Scancode- und cve-bin-tool-Erweiterungen. Es kann auch als Kubernetes-Job eingesetzt werden, eine API für eigene Integrationen steht nicht zur Verfügung.

Pros and Cons

Pros:

  • Herkunftsverfolgung für jede Containersicht
  • Ordnet Pakete den Dockerfile-Anweisungen zu
  • Optionale Erweiterungen für Lizenz- und CVE-Scanning

Cons:

  • Beschränkte Analyse des Ökosystems sprachspezifischer Pakete
  • Projekt-Updates seit 2023 ausgesetzt

Am besten zur Standardisierung von Daten zu Softwarepaketen

  • Nicht verfügbar
  • Für immer kostenlos

SPDX ist ein von der ISO ratifizierter offener Standard und ein Tooling-Ökosystem, das von der Linux Foundation gepflegt wird, um SBOM-Dokumente für Softwarepakete, Container und Lieferkettenartefakte zu generieren, zu validieren und zu konvertieren.

Für wen ist SPDX am besten geeignet?

OSPO-Leiter und Architekten der Software-Lieferkette, die ein compliance-taugliches, anbieterneutrales SBOM-Format für rechtliche Prüfungen, Beschaffung und regulatorische Einreichungen benötigen, profitieren am meisten von SPDX.

Warum ich SPDX gewählt habe

SPDX verdient seinen Platz auf meiner Shortlist, weil kein anderes Open-Source-SBOM-Format die gleiche Standardisierungstiefe bei Metadaten erreicht. Ich verlasse mich auf die Unterscheidung zwischen erklärten und abgeleiteten Lizenzen, was entscheidend ist, wenn Rechtsteams überprüfbare Compliance-Aufzeichnungen benötigen. Die kuratierte SPDX-Lizenzliste weist allen Komponenten konsistente Kurzkennungen zu, sodass SBOM-Dokumente unabhängig vom Ersteller vergleichbar bleiben – über Tools, Teams und Organisationen hinweg.

SPDX Hauptfunktionen

  • Mehrere Dokumentformate: Exportieren Sie SBOMs in JSON-, YAML-, Tag-Value- oder RDF/XML-Formaten für eine flexible Integration in verschiedene Tools.
  • SPDX Online-Tools: Nutzen Sie browserbasierte Anwendungen zum Validieren, Vergleichen und Konvertieren von SBOM-Dateien, ohne lokale Software zu installieren.
  • Offizielle Sprachbibliotheken: Greifen Sie programmatisch auf SPDX-Dokumente zu und erzeugen Sie diese mit gepflegten Java-, Python-, Go- und JavaScript-Bibliotheken.
  • Maven-Plugin-Integration: Erzeugen Sie automatisch SPDX-SBOMs während des Java-Projekt-Builds über ein offizielles Maven-Plugin.

SPDX-Integrationen

SPDX bietet native Integrationen mit GitHub, Maven, Yocto Project, OpenEmbedded und Kubernetes und stellt offizielle SDKs für Java, Python, Go und JavaScript bereit. Eine API ist für benutzerdefinierte Integrationen verfügbar.

Pros and Cons

Pros:

  • Standardisierte Lizenz- und Sicherheitsmetadaten-Unterstützung
  • Weit verbreitet in Open-Source-Ökosystemen
  • Kompatibel mit mehreren SBOM-Formaten nativ

Cons:

  • Benutzeroberfläche setzt stark auf Kommandozeilen-Tools
  • Begrenzte native Unterstützung für Binäranalyse

Beste Lösung zur Entdeckung von Komponenten in Codebasen

  • 7 Tage kostenloser Test
  • Ab 35.000 €/Jahr (jährliche Abrechnung)

SCANOSS ist eine Open-Source-SCA-Plattform, die Quellcode auf Schnipsel-Ebene scannt, um SBOMs in den Formaten SPDX und CycloneDX zu erzeugen, Lizenzrisiken zu erkennen, Schwachstellen zu identifizieren und kryptographische Nutzung über Codebestände und Container hinweg zu dokumentieren.

Für wen ist SCANOSS am besten geeignet?

SCANOSS eignet sich besonders für DevSecOps-Teams und OSPOs in mittelständischen bis großen Unternehmen, die Open-Source-Compliance über umfangreiche, mehrsprachige Codebasen hinweg verwalten.

Warum ich SCANOSS ausgewählt habe

SCANOSS hat es auf meine Auswahlliste geschafft, weil es auf Schnipsel-Ebene scannt und damit deutlich über die reine Manifest-Erkennung hinausgeht. Ich habe Tools verwendet, die eingebetteten Code oder komplett kopierte Funktionen übersehen, aber SCANOSS gleicht Quellcode-Fragmente mit über 100 Millionen Open-Source-Dateien in der OSSKB ab. Mir gefällt auch das Geo Provenance Dataset, das geografische und urheberbezogene Ursprünge von Komponenten anzeigt – etwas, das ich bei anderen Open-Source-SBOM-Tools bisher nicht gesehen habe.

SCANOSS Hauptfunktionen

  • SBOM Workbench: Visuelle Oberfläche zum Scannen und Prüfen von Quellcode mit der SCANOSS API.
  • Encryption Dataset: Erkennt kryptografische Algorithmen und deren Nutzung zur Unterstützung von ECCN- und Compliance-Prüfungen.
  • License Dataset: Verknüpft OSS-Komponenten mit Lizenzbedingungen und hebt Kompatibilitäts- oder Richtlinienrisiken hervor.
  • Mehrsprachige SDKs: Stellt SDKs für Python, Java und JavaScript zur Unterstützung verschiedener Entwicklungsumgebungen bereit.

SCANOSS Integrationen

SCANOSS bietet native Integrationen mit GitHub Actions, Jenkins, GitLab CI, VS Code und IntelliJ sowie SDKs für Python, Java und JavaScript. Eine API steht für individuelle Integrationen zur Verfügung.

Pros and Cons

Pros:

  • Erkennung von Komponenten auf Schnipsel-Ebene in Codebasen
  • Erfasst geografische und urheberbezogene Herkunft von Software
  • Identifizierung kryptographischer Algorithmen für Compliance

Cons:

  • Eingeschränktes Scannen für OS-Pakete und IaC
  • Erweiterte Funktionen erfordern ggf. technischen Aufbau

Am besten zur Verknüpfung von Lieferketten-Metadaten geeignet

  • Nicht verfügbar
  • Für immer kostenlos

GUAC ist ein Open-Source-Tool für die Sicherheit von Lieferketten, das SBOMs, Schwachstellendaten und Herkunftsatteste aufnimmt und deren Beziehungen in eine abfragbare Graphdatenbank abbildet.

Für wen ist GUAC am besten geeignet?

GUAC eignet sich besonders für Sicherheits- und DevSecOps-Teams, die große Software-Portfolios verwalten und eine vollständige Übersicht über die Lieferkette benötigen, die über das hinausgeht, was einzelne SBOM-Tools bieten.

Warum ich GUAC ausgewählt habe

GUAC verdient seinen Platz auf meiner Auswahlliste, weil kein anderes Open-Source-Tool Lieferketten-Metadaten auf diese Weise verknüpft. Mir gefällt, dass es SBOMs aus verschiedenen Quellen aufnimmt, sie in eine Graphdatenbank parst und es mir ermöglicht, transitive Abhängigkeiten in meinem gesamten Portfolio auf einmal abzufragen. Die Einbindung von Informationen aus OSV und deps.dev bedeutet, dass der Graph Schwachstellen aufdeckt, die ein reines SBOM übersehen würde.

GUAC Hauptfunktionen

  • GraphQL- und REST-APIs: Stellen den vollständigen Metadaten-Graphen für Abfragen und Integrationen bereit.
  • Unterstützung für SPDX und CycloneDX: Importiert und normalisiert standardisierte SBOM-Formate für eine konsistente Verarbeitung.
  • Visualizer-Oberfläche: Zeigt Lieferkettenbeziehungen und Datenflüsse in einer navigierbaren Web-GUI an.
  • Pluggable Backend-Architektur: Betrieb mit In-Memory- oder persistenten Backends wie PostgreSQL für flexible Bereitstellungsmöglichkeiten.

GUAC Integrationen

GUAC bietet native Integrationen mit Open Source Insights’ deps.dev, Open Source Vulnerabilities (OSV), SPDX, CycloneDX und ClearlyDefined, und stellt sowohl GraphQL- als auch REST-APIs für individuelle Integrationen bereit.

Pros and Cons

Pros:

  • Visualisiert lieferkettenübergreifende Verbindungen
  • Importiert sowohl SPDX- als auch CycloneDX-SBOMs
  • Erfasst Herkunft aus SLSA-Attesten

Cons:

  • Erzeugt keine eigenen SBOMs
  • Keine offiziellen Plugins für CI/CD-Pipelines

Am besten für Schwachstellen-Scanning in Containern geeignet

  • Nicht verfügbar
  • Kostenlos für immer

Trivy ist ein Open-Source All-in-One-Sicherheitsscanner, der SBOMs in den Formaten SPDX und CycloneDX erstellt und gleichzeitig nach Schwachstellen, Fehlkonfigurationen, Geheimnissen und Lizenzrisiken in Container-Images, Dateisystemen, Git-Repositories und Kubernetes-Clustern sucht.

Für wen ist Trivy am besten geeignet?

Trivy ist besonders geeignet für DevSecOps-Ingenieure und Teams für Anwendungssicherheit, die SBOM-Generierung und Sicherheits­schwachstellen­scans direkt in Container- und Kubernetes-Workflows integrieren möchten.

Warum ich Trivy gewählt habe

Trivy hat es auf meine Auswahlliste geschafft, weil es die SBOM-Erstellung für Container-Images und das Schwachstellen-Scanning in einer einzigen Binärdatei vereint – kein separates Tooling erforderlich. Besonders gefällt mir das schichtbasierte Scannen: Beim Scannen eines Container-Images weist Trivy CVEs der jeweiligen Bildschicht zu, die das anfällige Paket eingeführt hat. Das beschleunigt die Priorisierung enorm. Es unterstützt außerdem VEX, sodass ich nicht ausnutzbare CVEs, die an bestimmte Container-Komponenten gebunden sind, ohne manuelles Filtern unterdrücken kann.

Trivy Hauptfunktionen

  • SPDX- und CycloneDX-SBOM-Unterstützung: Generierung von SBOMs in beiden wichtigsten Industrieformaten direkt über die CLI.
  • Multiekosystem-Abhängigkeitsprüfung: Analyse von Komponenten in mehr als 13 Programmiersprachen, Betriebssystem-Paketen und Infrastructure-as-Code-Dateien.
  • Lizenz-Erkennung: Identifizieren und Klassifizieren von Open-Source-Lizenzinformationen für alle gefundenen Pakete und Abhängigkeiten.
  • Kubernetes-Operator-Integration: Automatisiertes Schwachstellenmanagement und Risiko-Scanning in laufenden Kubernetes-Clustern mit nativer Operator-Unterstützung.

Trivy-Integrationen

Trivy bietet native Integrationen mit GitHub Actions, GitLab CI, CircleCI, Azure DevOps, Bitbucket Pipelines, Kubernetes (über den Trivy Operator) sowie AWS Security Hub und unterstützt cosign, Rekor und VEX. Eine API für eigene Integrationen ist verfügbar.

Pros and Cons

Pros:

  • Scannt Infrastruktur-Code zusammen mit Containern
  • Schichtbasierter Schwachstellenscanner für Container
  • Umfassende Abdeckung von Programmiersprachen und Betriebssystem-Paketen

Cons:

  • Keine Unterstützung für das SWID-Format
  • Detaillierte Berichte können ressourcenintensiv sein

Am besten geeignet für Echtzeit-Risikomonitoring

  • Nicht verfügbar
  • Für immer kostenlos

OWASP Dependency-Track ist eine Open-Source-Komponenten-Analyseplattform, die CycloneDX-SBOMs verarbeitet, um Softwarekomponenten projektübergreifend zu inventarisieren, Schwachstellen zu erkennen, Lizenzrichtlinien durchzusetzen und die Sicherheit der Software-Lieferkette auf Portfolioebene zu überwachen.

Für wen ist OWASP Dependency-Track am besten geeignet?

Es eignet sich besonders für DevSecOps- und Applikationssicherheitsingenieure, die eine portfolioübergreifende Schwachstellenüberwachung in komplexen, mehrprojektigen Softwarelieferketten benötigen.

Warum ich OWASP Dependency-Track ausgewählt habe

Ich habe OWASP Dependency-Track in meine Top-Auswahl aufgenommen, weil kein anderes Open-Source-Tool die kontinuierliche, Echtzeit-Überwachung von Schwachstellen in einem vollständigen Software-Portfolio bietet. Statt auf Abruf zu scannen, spiegelt es Feeds von NVD, OSV und GitHub Advisories, sodass jede Komponente automatisch neu bewertet wird, wenn neue CVEs veröffentlicht werden. Die EPSS-basierte Priorisierung bewerte ich zudem sehr hoch, da so ersichtlich wird, welche Schwachstellen mit hoher Wahrscheinlichkeit tatsächlich ausgenutzt werden – und nicht nur solche mit dem höchsten CVSS-Score.

OWASP Dependency-Track Hauptfunktionen

  • Vollständige Bestandsaufnahme: Verfolgen Sie Bibliotheken, Container, Betriebssysteme, Firmware, Hardware und Dienste über alle Projektversionen hinweg.
  • CycloneDX SBOM-Unterstützung: Importiert, analysiert und erzeugt CycloneDX-SBOM-, HBOM-, VEX- und VDR-Dokumente.
  • Ausdrucksbasierte Richtliniendurchsetzung: Konfigurieren Sie erweiterten Zugriffsschutz und Richtlinienregeln mit CEL, um Aktionen zu automatisieren.
  • API-First-Integration: Nutzen Sie die gut dokumentierte REST-API, um sich mit CI/CD zu verbinden und SBOMs sowie Berichte zu automatisieren.

OWASP Dependency-Track Integrationen

OWASP Dependency-Track bietet native Integrationen mit Slack, Microsoft Teams, Mattermost, GitHub, GitLab, Jenkins, Snyk, Trivy, Sonatype OSS Index, und unterstützt benutzerdefinierte Integrationen über die REST API.

Pros and Cons

Pros:

  • Echtzeit-Analyse bei neuen Schwachstellenmeldungen
  • Unterstützt CycloneDX SBOM, VEX und VDR
  • Vollständige Bestandsaufnahme inklusive Hardware und Firmware

Cons:

  • SBOMs können nicht aus Quellcode generiert werden
  • Keine integrierte Unterstützung für das SPDX-Format

Am besten für die automatisierte CycloneDX-SBOM-Erstellung

  • Nicht verfügbar
  • Für immer kostenlos

cdxgen ist ein von OWASP entwickelter Open-Source-SBOM-Generator, der CycloneDX Bill of Materials-Dokumente für mehr als 20 Programmiersprachen, Paketmanager, Container-Images und Artefakttypen erstellt – einschließlich Kryptographie, Betriebs-, SaaS- und KI/ML-Komponenten.

Für wen ist cdxgen am besten geeignet?

cdxgen eignet sich besonders gut für DevSecOps-Ingenieure und Application-Security-Teams, die polyglotte Codebasen verwalten und eine SBOM-Generierung direkt in ihre CI/CD-Pipelines integrieren möchten.

Warum ich mich für cdxgen entschieden habe

cdxgen schafft es auf meine Shortlist, weil es die Referenzimplementierung für CycloneDX-SBOM-Generierung ist und die Spezifikationsversionen 1.4 bis 1.7 unterstützt – mit tiefgehender transitiver Abhängigkeitsauflösung in über 20 Ökosystemen. Besonders beeindruckt mich die Reachability-Analyse via atom, die Callstack-Beweise liefert, ob eine verwundbare Funktion tatsächlich vom eigenen Code erreicht wird. Außerdem nutze ich cdxgen zur Erstellung von CBOM- und OBOM-Dokumenten neben den Standard-SBOMs und erfasse so kryptografische Inventarisierung und Betriebssystem-Komponenten mit einem Tool.

cdxgen Hauptfunktionen

  • Native Dependency-Track-Integration: Übermittelt erstellte SBOMs automatisch an einen Dependency-Track-Server zur weiteren Analyse.
  • Universeller SBOM-Modus: Sammelt Komponenten aus allen erkannten Manifests in polyglotten Codebasen mit nur einem Befehl.
  • RSA BOM-Signierung: Unterstützt kryptografische Signierung und Verifikation von SBOMs über JSON Web Signatures.
  • Erfassung von Lizenz- und Herkunftsmetadaten: Extrahiert Lizenzen, PURLs, CPEs und Quellenachweise für jede Komponente.

cdxgen Integrationen

cdxgen bietet native Integrationen mit OWASP Dependency-Track und OWASP dep-scan, unterstützt GitHub Actions und stellt eine API für individuelle Integrationen in CI/CD-Pipelines bereit.

Pros and Cons

Pros:

  • Native CycloneDX-Unterstützung bis zur Spezifikation 1.7
  • SBOM-Erstellung für mehr als 20 Ökosysteme
  • Integrierte Reachability- und Provenance-Analyse

Cons:

  • Keine native SPDX-Ausgabe verfügbar
  • Begrenzte Optionen für grafische Benutzeroberfläche

Am besten zur Erstellung von SPDX-SBOMs geeignet

  • Nicht verfügbar
  • Für immer kostenlos

Das Microsoft SBOM Tool ist ein Open-Source-CLI-Tool, das automatisch SPDX-kompatible SBOMs generiert, indem es Abhängigkeiten aus verschiedenen Ökosystemen scannt, Komponenten-Metadaten erfasst sowie SBOM-Ausgaben über verschiedene Builds und Artefakte hinweg validiert oder schwärzt.

Für wen ist das Microsoft SBOM Tool am besten geeignet?

Es eignet sich besonders für DevSecOps-Ingenieure und AppSec-Teams, die in GitHub- oder Azure DevOps-Umgebungen arbeiten und eine skalierbare, unternehmensweite Erstellung von SPDX-SBOMs direkt in ihre Pipelines integrieren möchten.

Warum ich das Microsoft SBOM Tool ausgewählt habe

Das Microsoft SBOM Tool verdient seinen Platz auf meiner Auswahlliste aufgrund seiner nativen Unterstützung sowohl für SPDX 2.2 als auch für SPDX 3.0, was es den meisten Open-Source-Alternativen, die nur eine Version unterstützen, voraus hat. Besonders gut gefallen mir die integrierten Befehle validate und redact: Validate überprüft ein vorhandenes SBOM anhand eines bekannten Ablagepfads, während Redact vor externem Teilen Dateireferenzen entfernt. Außerdem verwendet Microsoft das Tool intern für das eigene Software-Portfolio – das spricht für Zuverlässigkeit im großen Maßstab.

Microsoft SBOM Tool – Hauptfunktionen

  • Komponentenerkennung: Scannt eine Vielzahl von Paketmanagern und Ökosystemen mit Microsofts eigener Engine zur Komponentenerkennung.
  • ClearlyDefined API-Integration: Bereichert SBOM-Dateien automatisch mit Lizenzdaten aus der ClearlyDefined API.
  • Multi-OS-Unterstützung: Läuft auf Windows, macOS und Linux und unterstützt so verschiedene Entwicklungs- und Build-Umgebungen.
  • Mehrere Vertriebsmöglichkeiten: Verfügbar als WinGet-Paket, Homebrew-Formel, Docker-Image und als globales .NET-Tool.

Microsoft SBOM Tool – Integrationen

Microsoft SBOM Tool bietet native Integrationen mit GitHub Actions und Azure DevOps Pipelines für die automatisierte SBOM-Erstellung in CI/CD-Workflows. Eine API steht für eigene Integrationen zur Verfügung.

Pros and Cons

Pros:

  • Erzeugt sowohl SPDX 2.2 als auch 3.0 SBOMs
  • Scannt nativ Abhängigkeiten aus mehreren Ökosystemen
  • Enthält Lizenzdaten durch die ClearlyDefined API

Cons:

  • Keine Unterstützung für CycloneDX-Format
  • Quellbeitrag auf das Microsoft-Team beschränkt

Am besten für schnelle Erstellung von Softwarestücklisten

  • Nicht verfügbar
  • Für immer kostenlos

Syft ist ein Open-Source-CLI-Tool und eine Go-Bibliothek, entwickelt von Anchore, die SBOMs (Software-Stücklisten) aus Container-Images, Dateisystemen, Quellcode und Archiven für über 30 Paket-Ökosysteme generiert und Ausgaben in den Formaten SPDX, CycloneDX und Syft JSON bietet.

Für wen ist Syft am besten geeignet?

Syft ist ideal für DevSecOps-Ingenieure und Application-Security-Teams, die die SBOM-Generierung direkt in CI/CD-Pipelines einbinden möchten.

Warum ich Syft ausgewählt habe

Syft verdient seinen Platz auf meiner Shortlist, weil kein anderes Open-Source-SBOM-Tool eine derartig tiefe Katalogisierung bei dieser Geschwindigkeit bietet. Es läuft als einzelne kompilierte Binärdatei ohne externe Abhängigkeiten, sodass ich es in jede Pipeline einbinden und sofort SBOMs für Container-Images oder Dateisysteme generieren kann. Mit dem Ansatz 'Wenn es da ist, sagen wir es Ihnen' erfasst es transitive Abhängigkeiten in über 30 Ökosystemen, darunter Go-Binärdateien und Java-Archive, die andere Tools häufig übersehen.

Syft Hauptfunktionen

  • SBOM-Formatkonvertierung: Konvertieren Sie erzeugte SBOMs zwischen den Formaten SPDX, CycloneDX und Syft JSON.
  • Paketentdeckung auf Dateiebene: Identifizieren und inventarisieren Sie Softwarekomponenten auf Dateiebene innerhalb von Images und Archiven.
  • Signierte SBOM-Bestätigung: Erstellen Sie kryptografisch signierte SBOM-Attestierungen unter Verwendung der in-toto-Spezifikation.
  • Offizielle GitHub Action Unterstützung: Integrieren Sie die SBOM-Generierung direkt in GitHub-Workflows mit einer gepflegten Action.

Syft Integrationen

Syft bietet eine offizielle GitHub Action für die native Integration in GitHub-Workflows, unterstützt Docker-basierte Bereitstellung zur Nutzung mit Docker- und OCI-Images und stellt eine CLI für den Einsatz mit Jenkins, GitLab und anderen CI-Pipelines bereit. Eine API und eine Go-Bibliothek stehen für individuelle Integrationen zur Verfügung.

Pros and Cons

Pros:

  • Unterstützt über 30 Ökosysteme und Formate
  • Gibt SPDX, CycloneDX und Syft JSON aus
  • CLI läuft in Docker, CI/CD und lokal

Cons:

  • Kein integriertes Schwachstellen-Scanning
  • Eingeschränkte Windows-Unterstützung für Paket-Ökosysteme
  1. Protobom

    Am besten geeignet für die Übersetzung zwischen SBOM-Formaten

  2. SW360

    Am besten geeignet für das Management des Lebenszyklus von Softwarekomponenten

  3. Snyk Open Source

    Am besten geeignet zur Verfolgung von Open-Source-Schwachstellen

  4. bomctl

    Am besten für die SBOM-Verwaltung über die Befehlszeile

Wie ich Open-Source-SBOM-Tools bewerte

Ich teile die Bewertung in zwei Ebenen auf: grundlegende SBOM-Funktionalitäten, die ein Tool auf die Liste bringen, und Unterscheidungsmerkmale wie VEX-Unterstützung und Ökosystemvielfalt, die die besten Tools abheben.

Kernfunktionalität (Grundvoraussetzungen für diese Liste)

Wenn ich Tools für meine Liste auswähle, bewerte ich jedes einzelne auf einer Skala von 0 (bietet die Funktion nicht) bis 5 (überzeugt in diesem Bereich) für jede unten aufgelistete Kernfunktion. Dann berechne ich die Gesamtpunktzahl als Prozentsatz. Jedes Tool muss insgesamt mindestens 65 % erreichen, um berücksichtigt zu werden.

  • Open-Source-Lizenz: Ich prüfe, dass jedes Tool eine von der OSI genehmigte Lizenz verwendet und ein öffentlich zugängliches Repository hat – source-available, aber closed-core ist nicht zulässig.
  • SBOM-Erstellung: Ich achte auf eine automatisierte Ausgabe, die auch transitive Abhängigkeiten abbildet, nicht nur Manifest-Einträge eines einzelnen Build-Ziels.
  • Unterstützung von Standardformaten: Tools sollten mindestens SPDX oder CycloneDX ausgeben, da die meisten Compliance-Workflows und nachgelagerte Nutzer eines oder beide Formate erwarten.
  • Multi-Ökosystem-Scanning: Ich werte aus, wie viele Paket-Ökosysteme ein Tool abdeckt – npm, Maven, PyPI, Go-Module und Container-Images sind dabei ein gutes Fundament.
  • Erfassung von Komponenten-Metadaten: Jeder Komponenteneintrag sollte Version, Lizenz und Bezeichner wie PURLs oder CPEs enthalten, um eine Zuordnung zu Schwachstellendatenbanken zu ermöglichen.
  • CI/CD-Integration: Ich achte auf CLI- oder Plugin-Unterstützung, die sich ohne großen Aufwand in Pipelines wie Jenkins, GitHub Actions oder GitLab CI integrieren lässt.

Wenn ich eine Liste von Tools habe, die die Kriterien erfüllen, prüfe ich, wodurch sich jede Plattform auszeichnet.

Unterscheidungsmerkmale (Was Anbieter voneinander abhebt)

So vergleiche und kontrastiere ich verschiedene Anbieter:

Herausragende Funktionen

Die Korrelation von Schwachstellen ist besonders wichtig. Ich suche nach Tools, die eine Anbindung an Datenbanken wie NVD und OSV bieten und CVEs direkt auf SBOM-Komponenten abbilden. Die VEX-Dokumentenerstellung geht noch einen Schritt weiter, indem sie kennzeichnet, welche Schwachstellen tatsächlich Ihr ausgeliefertes Produkt betreffen. Das reduziert Benachrichtigungen für nachgelagerte Konsumenten. Ich bewerte auch die Tiefe bei Container- und IaC-Scans, da transitive Abhängigkeiten in Images und Kubernetes-Manifests in einer reinen Manifest-Analyse nicht auftauchen.

Über die Funktionen hinaus

Für mich ist Community-Governance ein wichtiges Signal. Tools, die von Stiftungen wie OWASP oder der Linux Foundation unterstützt werden, zeigen oft gesündere Commit-Aktivität und eine größere Vielfalt bei den Beitragenden – wichtig, wenn Sie langfristig auf ein Projekt in Sachen Compliance setzen. Auch die regulatorische Ausrichtung fließt in meine Bewertung ein – ob die Ausgaben die NTIA-Mindestanforderungen für SBOM-Elemente erfüllen und als auditierbare Artefakte für die Beschaffung dienen können. Zudem achte ich auf Erweiterbarkeit, besonders auf API-Zugänge und die Kompatibilität mit Plattformen wie Dependency-Track oder GUAC.

So wählen Sie Open-Source-SBOM-Tools aus

Es ist leicht, sich in langen Funktionslisten und komplexen Preisstrukturen zu verlieren. Damit Sie sich bei der individuellen Auswahl Ihrer Software auf das Wesentliche konzentrieren können, finden Sie hier eine Checkliste mit Faktoren, die Sie berücksichtigen sollten:

FaktorWas Sie berücksichtigen sollten
SkalierbarkeitKann dieses Tool mit dem Wachstum von Codebasen, Programmiersprachen und Teams Schritt halten, wenn Ihre Organisation wächst?
IntegrationenKönnen Sie das Tool mit Ihren CI/CD-Pipelines, Ticketsystemen und bestehenden Datenfeeds für Sicherheitslücken verbinden?
AnpassbarkeitWie einfach lassen sich Arbeitsabläufe, Richtlinien oder SBOM-Ausgabeformate an die Anforderungen Ihrer Organisation anpassen?
BenutzerfreundlichkeitWerden die Ingenieure das Tool tatsächlich täglich verwenden, oder ist die Lernkurve für schnelllebige Teams zu steil?
Implementierung und EinarbeitungWie lange dauert es, das Tool bereitzustellen und aussagekräftige SBOM-Ausgaben für Ihre Kernprojekte zu erzeugen?
KostenGibt es Infrastruktur- oder Supportkosten, die zusätzlich zur Open-Source-Lizenz entstehen können?
SicherheitsvorkehrungenFührt das Tool neue Angriffsflächen ein, benötigt es vertrauliche Zugangsdaten oder verfügt es über einen zuverlässigen Aktualisierungsprozess?
Compliance-AnforderungenKann das Tool den Nachweis- und Berichtsanforderungen von Rahmenwerken wie EO 14028 oder dem EU CRA direkt ab Werk entsprechen?

Was sind Open-Source-SBOM-Tools?

Open-Source-SBOM-Tools sind öffentlich verfügbare Software, die Ihnen helfen, Software-Stücklisten (SBOMs) in Ihren Entwicklungsabläufen zu erstellen, zu verwalten und zu analysieren. Mit diesen Tools können Sie Projektabhängigkeiten inventarisieren, standardisierte SBOM-Dokumente erzeugen und in Pipelines integrieren, um Compliance, die Nachverfolgung von Schwachstellen und das Management von Lizenzrisiken für Ihre Software-Lieferkette zu unterstützen.

Funktionen

Achten Sie bei der Auswahl von Open-Source-SBOM-Tools auf die folgenden wichtigen Funktionen:

  • SBOM-Erstellung: Erstellt eine umfassende Software-Stückliste und inventarisiert automatisch Softwarekomponenten, Abhängigkeiten und Versionen für jeden Build.
  • Unterstützung von Standardformaten: Gibt SBOMs in weithin akzeptierten Formaten wie SPDX oder CycloneDX aus, wodurch sie mit Regulierungsbehörden, Kunden und nachgelagerten Tools kompatibel sind.
  • Scannen mehrerer Ökosysteme: Analysiert Quellcode, Binärdateien und Container-Images über mehrere Sprachen und Ökosysteme hinweg, um ein vollständiges Bild der Abhängigkeiten zu erhalten.
  • Erfassung von Komponentenmetadaten: Zeichnet wichtige Details wie Version, Anbieter, Lizenzierung, PURLs und Hashes auf und unterstützt damit Nachverfolgungs- und Compliance-Anwendungsfälle.
  • Abgleich mit Schwachstellen: Verknüpft Komponentendetails in der SBOM mit öffentlichen Schwachstellendatenbanken und hilft Ihnen dabei, mit Ihren Abhängigkeiten verbundene CVEs zu finden und zu überwachen.
  • Analyse der Lizenz-Compliance: Kennzeichnet inkompatible oder risikoreiche Open-Source-Lizenzen und unterstützt die sorgfältige Prüfung sowie rechtliche Bewertungen bei der Softwarebereitstellung.
  • CI/CD-Integration: Verbindet sich über CLI-Tools, Plugins oder APIs direkt mit Ihren Build-Systemen und Pipelines und ermöglicht dadurch Automatisierung sowie die Durchsetzung von Richtlinien.
  • Scannen von Containern und IaC: Untersucht Container-Images und Infrastructure-as-Code-Dateien, um Abhängigkeiten aufzudecken, die in Standardmanifesten möglicherweise nicht sichtbar sind.
  • Unterstützung von VEX-Dokumenten: Erstellt Dokumente zum Austausch über die Ausnutzbarkeit von Schwachstellen (VEX), um zu klären, welche Schwachstellen in Ihrer SBOM Ihr Produkt tatsächlich betreffen.
  • API-Zugriff: Ermöglicht Ihnen, die SBOM-Verwaltung zu automatisieren und Komponentendaten programmgesteuert abzufragen, sodass sich die Tools problemlos in interne Sicherheits- oder Compliance-Abläufe integrieren lassen.

Vorteile

Die Implementierung von Open-Source-SBOM-Tools bietet Ihrem Team und Ihrem Unternehmen mehrere Vorteile. Hier sind einige, auf die Sie sich freuen können:

  • Verbesserte Transparenz der Lieferkette: Erhalten Sie mithilfe der SBOM-Erstellung und des Scannens mehrerer Ökosysteme eine klare, automatisierte Übersicht über alle Softwareabhängigkeiten in Ihren Projekten.
  • Stärkere Compliance-Position: Erfüllen Sie regulatorische Anforderungen wie EO 14028 oder den EU CRA, indem Sie standardisierte, prüfbare SBOMs und für Compliance geeignete Metadaten erzeugen.
  • Schnellere Reaktion auf Schwachstellen: Gleichen Sie Komponentendaten mit Schwachstellendatenbanken ab und erstellen Sie VEX-Dokumente, um tatsächliche Sicherheitsrisiken schnell zu identifizieren, zu bewerten und zu beheben.
  • Geringeres Lizenzrisiko: Erkennen und prüfen Sie Open-Source-Lizenzen in Ihren Abhängigkeiten automatisch und vermeiden Sie dadurch Copyleft- oder inkompatible Komponenten.
  • DevSecOps-Abläufe: Integrieren Sie die SBOM-Erstellung und Sicherheitsprüfungen direkt in CI/CD-Pipelines und sorgen Sie so für automatisierte, richtlinienbasierte Kontrollen.
  • Geringere Betriebskosten: Nutzen Sie Open-Source- und über APIs zugängliche Tools, um eine Abhängigkeit von proprietären Anbietern zu vermeiden und langfristige Verwaltungskosten planbar zu halten.
  • Bessere Audit-Bereitschaft: Erfassen Sie die Metadaten, Herkunftsinformationen und Berichtsdaten, die wichtig sind, wenn Kunden oder Partner Nachweise zur Sicherheit der Lieferkette anfordern.

Kosten & Preise

Die Auswahl von Open-Source-SBOM-Tools erfordert ein Verständnis der verschiedenen verfügbaren Preismodelle und Tarife. Die Kosten variieren je nach Funktionen, Teamgröße, Zusatzoptionen und weiteren Faktoren. Die folgende Tabelle fasst gängige Tarife, deren Durchschnittspreise und typische in Open-Source-SBOM-Lösungen enthaltene Funktionen zusammen:

Vergleichstabelle der Tarife für Open-Source-SBOM-Tools

PlantypDurchschnittlicher PreisÜbliche Funktionen
Kostenloser Plan$0Grundlegende SBOM-Erstellung, Unterstützung von Standardformaten, CLI-Zugriff und Dokumentation der Community.
Persönlicher Plan$5-$20/Benutzer/MonatErweiterte SBOM-Funktionen, Unterstützung zusätzlicher Programmiersprachen, eingeschränkte CI/CD-Integrationen und bevorzugter E-Mail-Support.
Geschäftsplan$20-$50/Benutzer/MonatTeamverwaltung, Richtliniendurchsetzung, Scannen von Containern und IaC, erweiterter API-Zugriff und grundlegende Berichterstattung.
Unternehmensplan$50-$100/Benutzer/MonatSSO/SAML-Integration, erweiterte Compliance-Funktionen, Prüfprotokollierung, Premium-Support und individuelles Onboarding.

FAQs zu Open-Source-SBOM-Tools

Hier finden Sie Antworten auf häufige Fragen zu Open-Source-SBOM-Tools:

Wie gehen Open-Source-SBOM-Tools mit neuen oder benutzerdefinierten Paketökosystemen um?

Die meisten Tools konzentrieren sich auf weit verbreitete Ökosysteme, einige ermöglichen jedoch die Definition benutzerdefinierter Parser oder Plug-ins. Wenn Ihr Technologie-Stack Nischen- oder interne Pakete umfasst, prüfen Sie die Dokumentation auf Erweiterungspunkte und aktive Beiträge der Community.

Kann ich Open-Source-SBOM-Tools in abgeschotteten oder stark regulierten Umgebungen einsetzen?

Ja, viele Open-Source-SBOM-Tools laufen vollständig offline und benötigen keine externen Aufrufe. Stellen Sie sicher, dass alle erforderlichen Datenbanken oder Ressourcen für die Prüfung auf Schwachstellen und Lizenzen lokal gespiegelt werden können.

Sind SBOM-Ausgaben verschiedener Tools immer kompatibel?

Nicht immer. Obwohl SPDX und CycloneDX Standards sind, kann jedes Tool sie geringfügig anders implementieren. Es ist wichtig, die Ausgabe mit nachgelagerten Verbrauchern zu validieren und bei Bedarf Konvertierungen oder eine Nachbearbeitung durchzuführen, um die Anforderungen von Partnern zu erfüllen.

Wie hoch ist der Wartungsaufwand für Open-Source-SBOM-Tools?

Die Wartung umfasst häufig die Aktualisierung von Schwachstellen-Feeds, die Synchronisierung des Tools mit Aktualisierungen des Sprachökosystems sowie regelmäßige Konfigurationsprüfungen. Bewerten Sie die Projektaktivität und den Zustand der Community, bevor Sie Tools zu einer zentralen Abhängigkeit machen.

Kann ich Open-Source-SBOM-Tools für die Einhaltung rechtlicher Vorgaben und externe Audits verwenden?

Open-Source-SBOMs können bei der Erfüllung von Compliance-Anforderungen helfen, sofern sie den regulatorischen SBOM-Richtlinien entsprechen. Bestätigen Sie stets, dass die Ausgaben alle erforderlichen Elemente abdecken, und lassen Sie die Dokumentation vor der Übermittlung an Partner oder Prüfer von Compliance-Experten überprüfen.

Paulo Gardini Miguel
By Paulo Gardini Miguel

Paulo ist Director of Technology beim schnell wachsenden Medientechnologieunternehmen BWZ. Zuvor war er als Software Engineering Manager und später als Head Of Technology bei Navegg tätig, dem größten Datenmarktplatz Lateinamerikas, ebenso wie als Full Stack Engineer bei MapLink, einem Anbieter von Geolokalisierungs-APIs als Service. Paulo verfügt über langjährige Erfahrung als Infrastrukturarchitekt, Teamleiter und Produktentwickler in schnell skalierenden Webumgebungen. Es motiviert ihn, sein Fachwissen mit anderen Technologieverantwortlichen zu teilen, um sie beim Aufbau großartiger Teams, der Steigerung der Leistungsfähigkeit, der Optimierung von Ressourcen und beim Schaffen einer soliden Grundlage für Skalierbarkeit zu unterstützen.