SBOM undVEX.
Eine Software Bill of Materials beschreibt Komponenten eines konkreten Releases. VEX dokumentiert, ob eine bekannte Schwachstelle dieses Produkt tatsächlich betrifft. Die Plattform muss deshalb nicht nur Dateien erzeugen, sondern Versionen, Produkte, Lieferanten, Schwachstellenentscheidungen und Freigaben über den Lebenszyklus zusammenhalten.
Marktbild: sehr hohe Priorität für Softwarehersteller und digitale Produkte. Zwölf Plattformen decken unterschiedliche Kombinationen aus Erzeugung, Import, Analyse, VEX, Austausch und Produktportfolio ab.
Artefakt, Aussage, System of Record.
Ein Generator erzeugt SPDX- oder CycloneDX-Dateien. Ein Repository verwaltet SBOMs pro Produkt und Release. Analyseplattformen korrelieren Komponenten mit Schwachstellen und Lizenzen. VEX hält die begründete Betroffenheitsentscheidung maschinenlesbar fest.
Prüfe Formatversionen, PURL- und CPE-Auflösung, Hierarchien, mehrere SBOMs pro Release, VEX-Profile, Schwachstellenquellen, Lieferantenaustausch, Zugriffsschutz, unveränderbare Historie und API-Integration.
Git ist die Quelle. Die SBOM ist das Ergebnis.
Ein gepflegtes Repository dokumentiert Quelltext, Änderungen und Versionen. Manifest- und Lockdateien liefern zusätzlich direkte und transitive Abhängigkeiten. Daraus können GitHub, GitLab, Build-Plugins oder freie Generatoren bereits im Entwicklungsprozess eine SBOM erzeugen. Ein separates SBOM-Produkt ist dafür nicht zwingend erforderlich.
Das Repository allein beantwortet jedoch nicht sicher, welche Komponenten tatsächlich im ausgelieferten Paket, Container oder Firmware-Image enthalten sind. Abweichende Build-Schritte, eingebettete Binärdateien und nicht ausgelieferte Entwicklungsabhängigkeiten können das Bild verändern. Für einen belastbaren Release-Nachweis sollte die Erzeugung deshalb an den Build gekoppelt und das fertige Artefakt zusätzlich geprüft werden.
| Weg | Vorhandene Grundlage | Geeignet für | Grenze |
|---|---|---|---|
| GitHub SBOM Export | Dependency Graph und Repository-Metadaten | SPDX-Inventar eines GitHub-Repositories, manuell, per API oder Action | Der Dependency Graph ist nicht automatisch identisch mit dem ausgelieferten Artefakt |
| GitLab Dependency Scanning | Lockfiles, Dependency Graphs und CI/CD | CycloneDX-SBOMs als Pipeline-Artefakte und anschliessende Schwachstellenanalyse | Funktionsumfang und unterstützte Workflows hängen von GitLab-Version und Lizenz ab |
| Syft und Anchore SBOM Action | Repository, Verzeichnis, Archiv oder Container-Image | Freie SBOM-Erzeugung in SPDX oder CycloneDX innerhalb bestehender Pipelines | Lebenszyklus, Lieferantenaustausch und VEX-Freigaben müssen separat organisiert werden |
| Build-Plugins und Generatoren | Paketmanager und Buildsystem | Releasebezogene SBOM direkt während des Builds | Eine reine Lockfile-Auswertung kann vom Inhalt des fertigen Produkts abweichen |
| SBOM-Management-Plattform | SBOMs aus eigenen Builds und von Lieferanten | Viele Produkte, Releases, Lieferanten, VEX-Entscheide und langfristige Nachweise | Zusätzliche Kosten und Integration lohnen sich erst bei entsprechendem Steuerungsbedarf |
Vom Build bis zur Produktaussage.
| Plattform | Schwerpunkt | Stärke | Geeignet für | Vor Auswahl prüfen |
|---|---|---|---|---|
| Anchore Enterprise | SBOM-basierte Supply-Chain-Security | Syft-Erzeugung, Policy und VEX | Cloud-native und regulierte Entwicklung | Portfoliohierarchie und Formataustausch |
| OWASP Dependency-Track | Open Source SBOM-Analyse | CycloneDX-natives Komponentenportfolio | Eigenbetrieb mit Integrationskompetenz | VEX-Workflow, Skalierung und Betrieb |
| Cybeats SBOM Studio | SBOM System of Record | Produkt-, Lieferanten- und VEX-Lebenszyklus | Hersteller mit vielen Produktlinien | Generatoren, Quellen und Lizenzmodell |
| FOSSA | SBOM und Open-Source-Compliance | Erzeugen, importieren, teilen und Lizenzen | Softwareorganisationen mit OSS-Fokus | VEX-Tiefe und Binäranalyse |
| Black Duck | SCA und SBOM | Reife Komponenten- und Lizenzdatenbasis | Enterprise AppSec und Due Diligence | System-of-Record-Funktionen und Austausch |
| Finite State | Produkt- und Firmware-SBOM | Quellcode-, Binär- und Firmwareanalyse | IoT, OT und eingebettete Produkte | Buildintegration und VEX-Freigaben |
| Mend SCA | SCA, SBOM und Remediation | Entwicklungsworkflow und OSS-Risiken | Breite Anwendungsportfolios | Produktstruktur und Lieferanten-SBOMs |
| Snyk Open Source | Developer-first SCA und SBOM | Dependency-Fixes im Entwicklungsfluss | Cloud-native Entwicklungsteams | VEX, Langzeitarchiv und Fremd-SBOMs |
| JFrog Xray | Artifact- und SBOM-Security | Kontext im JFrog-Artefaktfluss | Artifactory-zentrierte Softwarefabriken | Externer Austausch und VEX-Unterstützung |
| Revenera SBOM Insights | SBOM-Ingestion und Portfolioanalyse | Third-Party-SBOMs und OSS-Governance | Hersteller und Zulieferer | Erzeugungstiefe und Formate |
| TrustSource | SBOM, VEX und Produkt-Compliance | CRA-nahe Produkt- und Lebenszyklusdaten | DACH-Software- und Produkthersteller | Integrationen und Marktabdeckung |
| Sonatype Lifecycle | Component Governance | Policy und Remediation entlang des SDLC | Enterprise-Entwicklungsorganisationen | SBOM-Repository und VEX-Austausch |
- Eine SBOM ohne Produkt- und Releasebezug veraltet unmittelbar.
- Namensauflösung ordnet Komponenten dem falschen CPE oder Paket zu.
- Ein VEX-Status wird ohne Begründung, Evidenz oder erneute Prüfung übernommen.
Verfolge ein Release vom Build-Artefakt bis zur verteilten SBOM. Importiere eine Lieferanten-SBOM, bewerte einen realen CVE-Fall, erzeuge VEX und prüfe, ob jede Aussage später reproduziert werden kann.
Security Tool Navigator · Gebiet 07
Im Gebiet Application und Product Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Application und Product Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.