Seit dem 11. September 2026 sind die ersten Meldepflichten des EU Cyber Resilience Act (CRA) rechtsverbindlich. Wer Software mit digitalen Elementen in der EU verkauft, muss aktiv ausgenutzte Schwachstellen jetzt melden und dafür genau wissen, welche Komponenten in seinen Produkten stecken. Genau hier setzen SBOM- und SCA-Plattformen an. Wir vergleichen die drei meistgenutzten Werkzeuge für Software-Stücklisten und Schwachstellenmanagement: das quelloffene OWASP Dependency-Track, die kommerzielle Plattform FOSSA und das Enterprise-Schwergewicht Mend (früher WhiteSource). Der Vergleich zeigt, wo die Kosten zwischen 0 € und mehreren hundert Dollar pro Entwickler und Monat liegen, welches Tool welche Sprachen abdeckt und was deutsche Unternehmen jetzt konkret tun müssen.
Für IT-Verantwortliche in Deutschland kommen damit zwei Entwicklungen gleichzeitig zusammen. Zum einen wächst der Druck durch Angriffe auf die Software-Lieferkette, bei denen kompromittierte Open-Source-Pakete tief in fremde Produkte gelangen, ohne dass die Hersteller es merken. Zum anderen verlangt der Gesetzgeber jetzt eine belastbare Antwort auf die einfache Frage, welche Komponenten überhaupt im eigenen Produkt stecken. Ein SCA-Tool allein löst dieses Problem nicht, es liefert aber die technische Grundlage, auf der sich Meldepflichten, Lizenzprüfung und Schwachstellenmanagement erst automatisieren lassen.
Warum SBOM-Tools 2026 in Deutschland plötzlich Pflicht werden
Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten, doch lange galt er als Zukunftsthema mit viel Vorlaufzeit. Das hat sich geändert. Artikel 14 der Verordnung, der Hersteller zur Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle verpflichtet, bindet seit dem 11. September 2026 auch Produkte, die bereits am Markt sind. Die vollständige Anwendung inklusive der grundlegenden Anforderungen aus Anhang I, zu denen die SBOM-Pflicht zählt, wird zwar erst zum 11. Dezember 2027 vollständig durchsetzbar. Praktisch zwingt der frühere Meldetermin Unternehmen aber schon jetzt dazu, ihre Softwarebestände zu inventarisieren, denn ohne eine aktuelle Liste aller Komponenten lässt sich eine ausgenutzte Schwachstelle gar nicht zuverlässig identifizieren.
Anhang I Teil II Absatz 1 der CRA verlangt von Herstellern, Schwachstellen und Komponenten zu dokumentieren, unter anderem durch die Erstellung einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten der obersten Ebene abdeckt. Branchenleitfäden empfehlen dafür CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, jeweils in JSON oder XML. Damit wird die Wahl des richtigen SCA-Tools zur Compliance-Frage und nicht mehr nur zur Frage der Entwicklerproduktivität. Wer als Automobilzulieferer, Medizintechnik-Hersteller oder Software-Anbieter Kunden in der EU beliefert, kommt an einer Antwort auf diese Frage in den kommenden Monaten kaum vorbei.
Dependency-Track, FOSSA und Mend im Kurzporträt
OWASP Dependency-Track ist ein quelloffenes Projekt der OWASP Foundation und wird von den Machern selbst als kontinuierliche SBOM-Analyseplattform beschrieben. Es läuft ausschließlich selbst gehostet in einer Docker-Umgebung, kostet nichts und nimmt CycloneDX-Stücklisten entgegen, die vorgelagerte Tools wie Syft oder cdxgen erzeugen. Auf GitHub zählte das Projekt Anfang September 2026 rund 4.200 Sterne und 807 Forks, in den vorangegangenen 30 Tagen kamen laut dem GitHub-Analysedienst Gittrend 176 neue Sterne hinzu, etwa sechs pro Tag. Die offizielle OWASP-Projektseite selbst listet mit 3.900 Sternen einen leicht veralteten Stand, was zeigt, wie schnell das Projekt aktuell wächst.
FOSSA positioniert sich als kommerzielle SaaS-Plattform mit Fokus auf Lizenz-Compliance und Sicherheitsscans für Entwicklerteams. Das Unternehmen deckt laut eigener Dokumentation 21 explizit gelistete Sprachen und Build-Systeme ab, von Python über Go bis Rust und Swift, und lässt sich sowohl über CI/CD-Daten als auch über den direkten Import fertiger CycloneDX- oder SPDX-Stücklisten befüllen. FOSSA fährt ein gestaffeltes Preismodell von einer dauerhaft kostenlosen Stufe bis zu individuellen Enterprise-Verträgen.
Mend, bis zur Umbenennung als WhiteSource bekannt, positioniert sich als gebündelte Enterprise-AppSec-Plattform, die SCA mit SAST, Container-Scanning und Infrastructure-as-Code-Prüfungen kombiniert. Das Unternehmen wirbt mit Abdeckung von mehr als 200 Sprachen und verspricht auf der eigenen Produktseite, die Behebungszeit für Schwachstellen um 80 Prozent zu senken. Diese Zahl stammt direkt von Mend selbst und ist keine unabhängig geprüfte Kennzahl. Seit der Rebrand-Welle im April 2026 gibt es keine kostenlose Entwicklerstufe mehr, die frühere WhiteSource Community Edition wurde eingestellt.
Technische Spezifikationen im direkten Vergleich
Die folgende Tabelle fasst die wichtigsten technischen Eckdaten zusammen, so wie sie aus Produktdokumentation und unabhängigen Reviews im September 2026 hervorgehen.
| Merkmal | OWASP Dependency-Track | FOSSA | Mend |
|---|---|---|---|
| Lizenzmodell | Open Source (Apache 2.0) | Proprietär, SaaS | Proprietär, SaaS |
| Deployment | Selbst gehostet (Docker) | Cloud-SaaS | Cloud-SaaS |
| Einstiegspreis | 0 € | 0 $ (Free-Tier) | Kein Free-Tier, nur Vertrieb |
| GitHub-Sterne (Sept. 2026) | ca. 4.200 | nicht öffentlich (SaaS) | nicht öffentlich (SaaS) |
| Explizit gelistete Sprachen | abhängig vom SBOM-Generator | 21 (Python, Go, Rust u.a.) | vom Hersteller mit „200+” beziffert |
| SBOM-Import | CycloneDX (nativ) | CycloneDX und SPDX | laut Herstellerangaben unterstützt |
| SBOM-Erzeugung | nein, konsumiert nur | ja, aus CI/CD-Daten | ja, im Rahmen der Suite |
| SAST enthalten | nein | nein | ja, gebündelt |
| Container-Scanning | nein (separates Tool nötig) | Enterprise-Zusatz | ja, gebündelt |
| IaC-Scanning | nein | nein | ja, gebündelt |
| Lizenz-Compliance-Prüfung | Basisfunktion | Kernfunktion | Kernfunktion |
| Letztes dokumentiertes Update | Commit vom 11.09.2026 | Docs aktualisiert 08/2026 | Review-Stand 05–08/2026 |
Der Vergleich macht sofort einen strukturellen Unterschied sichtbar. Dependency-Track ist ein spezialisiertes Werkzeug, das SBOMs analysiert, aber nicht selbst erzeugt. Es braucht also einen vorgeschalteten Generator und ergänzende Werkzeuge für Container- oder Infrastruktur-Scans. FOSSA und Mend liefern dagegen mehr Funktionsumfang aus einer Hand, dafür zu einem Preis, der mit steigender Teamgröße spürbar wächst. Wer die Tabelle als Einkaufskriterium nutzt, sollte nicht nur auf die Häkchen schauen, sondern auch auf die Tiefe der jeweiligen Funktion: Ein „Ja” bei der Lizenzprüfung kann bei einem Anbieter eine einfache Whitelist bedeuten und beim anderen eine vollautomatisierte Richtlinien-Engine mit Eskalationsstufen.
Preise 2026: Was Dependency-Track, FOSSA und Mend wirklich kosten
Preistransparenz ist der klarste Unterschied zwischen den drei Anbietern. Dependency-Track ist und bleibt kostenlos, wer zahlt, zahlt nur für den eigenen Server. FOSSA veröffentlicht konkrete Zahlen auf der eigenen Pricing-Seite. Mend dagegen führt laut einer Analyse von AppSecSanta aus dem Mai 2026 jede Preisanfrage über einen Vertriebsprozess, eine öffentliche Preisliste existiert nicht.
| Tool | Einstiegsstufe | Mittlere Stufe | Enterprise |
|---|---|---|---|
| Dependency-Track | 0 € (self-hosted) | 0 € + eigene Serverkosten | 0 € + Supportvertrag über Drittanbieter |
| FOSSA | 0 $, 5 Projekte, 10 Entwickler | 20 $ pro Projekt/Monat (jährlich abgerechnet) | ca. 46 $ pro Entwickler/Monat laut Vendr/PeerSpot-Daten |
| Mend | kein Free-Tier mehr seit 04/2026 | nur auf Anfrage | ca. 80–140 $ pro Entwickler/Monat, mit Rabatt bis 50–80 $ |
Bei zehn Entwicklern und fünf aktiven Projekten liegt FOSSA im Business-Tarif bei rund 100 Dollar im Monat, wenn jedes Projekt einzeln abgerechnet wird. Ein Enterprise-Team mit 50 Entwicklern zahlt bei FOSSA nach der genannten Schätzung um die 2.300 Dollar monatlich, bei Mend je nach Verhandlungsposition zwischen 2.500 und 7.000 Dollar. Dependency-Track kostet in diesem Szenario weiterhin nur die Infrastruktur, meist eine einzelne virtuelle Maschine mit Datenbank. Der Preisunterschied erklärt, warum gerade kleinere deutsche Mittelständler und Behörden verstärkt zu selbst gehosteten Open-Source-Lösungen greifen, sobald die CRA-Uhr zu ticken beginnt.
Unterstützte Sprachen und Ökosysteme
FOSSA nennt in seiner Dokumentation eine konkrete, überprüfbare Liste: Python, JavaScript, Go, Maven, Gradle, Scala, Ruby, PHP, .NET mit C#, F# und VB, Rust, Dart, iOS mit Objective-C und Swift, C/C++, Haskell, Elixir, Erlang, Clojure, Perl, Fortran, Nim und R. Das sind 21 konkret benannte Sprachen und Build-Systeme, ergänzt um generische Systemunterstützung für Fälle, die keiner der Kategorien entsprechen.
Mend wirbt dagegen pauschal mit „200+ Sprachen”, ohne diese Zahl auf der Produktseite konkret aufzuschlüsseln. Diese Diskrepanz zwischen einer nachvollziehbaren Liste bei FOSSA und einer runden, aber nicht aufgeschlüsselten Zahl bei Mend ist selbst ein Datenpunkt: Käufer, die eine bestimmte Nischensprache absichern müssen, sollten vor Vertragsabschluss eine konkrete Bestätigung verlangen statt sich auf Marketingzahlen zu verlassen.
Dependency-Track selbst ist sprachagnostisch, weil es keine Quellcode-Analyse durchführt, sondern fertige SBOMs auswertet. Die tatsächliche Sprachabdeckung hängt also vom vorgeschalteten SBOM-Generator ab. In Kombination mit CycloneDX-fähigen Generatoren wie Syft oder cdxgen, die praktisch jedes verbreitete Paketformat unterstützen, lässt sich damit ebenfalls eine breite Ökosystem-Abdeckung erreichen, allerdings mit einem zusätzlichen Werkzeug in der Kette.
SBOM-Formate: CycloneDX, SPDX und die CRA-Anforderungen
Alle drei Tools unterstützen die beiden relevanten SBOM-Standards, allerdings mit unterschiedlicher Tiefe. Dependency-Track ist von Grund auf um CycloneDX herum gebaut, dem von OWASP mitentwickelten Format. FOSSA kann laut eigener Dokumentation sowohl CycloneDX- als auch SPDX-Dokumente importieren und automatisch gegen Lizenz- und Sicherheitsregeln prüfen, ein Feature, das im Enterprise-Tarif verfügbar ist. Für Mend liegen in den ausgewerteten Quellen keine ebenso konkreten Formatangaben vor, das Unternehmen positioniert die Unterstützung eher funktional über SCA- und Compliance-Features als über Formatversionen.
Für die CRA-Konformität ist das relevant, weil ein Compliance-Leitfaden zum Cyber Resilience Act konkret CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 in JSON oder XML empfiehlt, jeweils als maschinenlesbares, gängiges Format im Sinne von Anhang I. Wichtig ist außerdem eine saubere Trennung: Schwachstelleninformationen gehören laut denselben Leitfäden nicht in das SBOM selbst, sondern in separate Formate wie CSAF oder VEX, die neben der Stückliste, der Politik für koordinierte Schwachstellenoffenlegung und einer Kontaktadresse Teil der technischen Dokumentation werden. Wer sein SCA-Tool also nur nach SBOM-Formaten auswählt, übersieht leicht, dass für eine vollständige CRA-Akte noch weitere Dokumente nötig sind.
Ein weiterer Punkt, der in der Praxis oft unterschätzt wird, ist die digitale Signatur der SBOM-Datei selbst. Compliance-Leitfäden zum CRA empfehlen, jede Stückliste kryptografisch zu signieren, damit sich im Streitfall nachweisen lässt, dass die vorgelegte SBOM tatsächlich zum ausgelieferten Produktstand gehört und nicht nachträglich verändert wurde. Dependency-Track übernimmt diesen Schritt nicht automatisch, hier bleibt die Signatur Aufgabe der vorgelagerten Build-Pipeline. FOSSA und Mend bewerben ihre SaaS-Plattformen als durchgängige Kette von der Erzeugung bis zur Ablage, konkrete Angaben zur automatischen Signatur lassen sich aus den öffentlich verfügbaren Dokumenten allerdings nicht eindeutig ableiten, sodass auch hier eine Rückfrage beim jeweiligen Anbieter vor Vertragsabschluss sinnvoll ist.
Integration in CI/CD: GitHub Actions, GitLab und Jenkins
Alle drei Anbieter setzen auf Integration in bestehende Build-Pipelines statt auf isolierte Scans. FOSSA verlangt in der eigenen Dokumentation ausdrücklich, Abhängigkeitsdaten aus der vorhandenen CI/CD-Umgebung einzuspeisen, um schnellere und genauere Scans zu erhalten, was auf dedizierte CLI-Integrationen für GitHub Actions, GitLab CI und Jenkins hindeutet. Dependency-Track selbst läuft als eigenständiger Docker-Dienst, an den CI-Jobs generierte SBOMs per API übermitteln, üblicherweise direkt nach dem Build-Schritt einer Pipeline. Mend wird in unabhängigen Reviews als Enterprise-Plattform für DevOps-Workflows beschrieben, die Erkennung, Priorisierung und Behebung automatisiert in bestehende Entwicklungsprozesse einbetten soll.
Ein praktischer Beispiel-Baustein für Dependency-Track sieht in einer GitHub-Actions-Pipeline so aus: Der Build-Schritt erzeugt zunächst mit einem CycloneDX-Plugin oder mit Syft eine SBOM-Datei, die anschließend per curl-Aufruf an die Dependency-Track-API übertragen wird.
# Beispiel: SBOM an Dependency-Track übermitteln
curl -X POST "https://dtrack.internal/api/v1/bom" \
-H "X-Api-Key: $DTRACK_API_KEY" \
-F "project=$PROJECT_UUID" \
-F "[email protected]"Dieser eine Schritt lässt sich in nahezu jede bestehende Pipeline einhängen, unabhängig davon, ob GitHub Actions, GitLab CI oder Jenkins das Build-System steuert. FOSSA und Mend bringen dafür eigene CLI-Tools und vorgefertigte Pipeline-Schritte mit, die den manuellen API-Aufruf ersetzen, aber im Gegenzug an das jeweilige SaaS-Abonnement gebunden sind.
In der Praxis unterscheidet sich der Integrationsaufwand vor allem in der Betriebsverantwortung. Bei GitHub Actions lässt sich der Dependency-Track-Aufruf als einfacher Workflow-Step direkt nach dem Build einfügen, ohne dass GitHub selbst etwas über die Zielinstanz wissen muss, solange die API über das Internet oder ein VPN erreichbar ist. In GitLab-CI-Umgebungen mit selbst gehosteten Runnern lässt sich Dependency-Track sogar im selben internen Netzwerksegment betreiben, ganz ohne Internetzugang für sensible Projekte. Jenkins-Pipelines mit Plugin-Ökosystem bieten für FOSSA und Mend häufig fertige Community- oder Hersteller-Plugins, die Konfigurationsaufwand sparen, aber auch eine zusätzliche Abhängigkeit von der Plugin-Pflege durch Dritte einbringen. Wer bereits stark auf Infrastructure as Code setzt, sollte vor der Werkzeugwahl prüfen, wie gut sich die jeweilige API oder CLI in bestehende Terraform- oder Ansible-Automatisierung einbetten lässt, denn nachträgliche Anpassungen an eingespielten Pipelines kosten in der Praxis oft mehr Zeit als die ursprüngliche Einrichtung.
Reachability-Analyse: Weniger Rauschen, mehr Fokus
Ein zentrales Problem klassischer SCA-Tools ist die schiere Menge an Meldungen. Ein durchschnittliches Softwareprojekt hängt oft von hunderten transitiven Abhängigkeiten ab, von denen viele Funktionen enthalten, die im eigenen Code nie aufgerufen werden. Ein Scanner, der jede bekannte Schwachstelle in jeder Abhängigkeit meldet, egal ob der betroffene Code-Pfad überhaupt erreichbar ist, produziert schnell hunderte Tickets, von denen die meisten für das eigene Produkt irrelevant sind. Genau hier setzt die sogenannte Reachability-Analyse an, die prüft, ob eine verwundbare Funktion im tatsächlichen Aufrufgraphen der eigenen Anwendung überhaupt erreicht werden kann.
Mend wirbt auf der eigenen Produktseite ausdrücklich damit, reachable Schwachstellen zu identifizieren, und verspricht dadurch eine Reduktion der Behebungszeit um 80 Prozent, eine Zahl, die wie bereits erwähnt vom Hersteller selbst stammt und nicht unabhängig verifiziert wurde. FOSSA und Dependency-Track kommunizieren in den ausgewerteten Quellen keine vergleichbar konkrete Reachability-Funktion, was nicht bedeutet, dass Priorisierung dort unmöglich ist, sondern dass sie eher über manuell konfigurierte Schweregrad-Schwellen und Policies erfolgt statt über automatisierte Code-Pfad-Analyse. Für Teams mit wenig Personal für die tägliche Triage kann eine eingebaute Reachability-Funktion den Unterschied machen, ob Schwachstellenmeldungen tatsächlich bearbeitet werden oder in einer ungelesenen Warteschlange versinken. Wer sich für ein Tool ohne diese Funktion entscheidet, sollte von Anfang an eigene Regeln definieren, welche Schweregrade automatisch eskaliert werden und welche erst nach manueller Prüfung.
Datenhoheit, DSGVO und Support-Modelle
Für deutsche Unternehmen kommt bei SaaS-Werkzeugen wie FOSSA und Mend regelmäßig eine zusätzliche Frage auf den Tisch: Wo landen die Metadaten über die eigene Codebasis, und wer hat theoretisch Zugriff darauf? Beide Anbieter sind US-Unternehmen, deren Cloud-Infrastruktur SBOM-Daten, Abhängigkeitslisten und teilweise auch Repository-Metadaten verarbeitet. Für viele Compliance-Abteilungen bedeutet das zusätzliche Prüfschritte bei Auftragsverarbeitungsverträgen, insbesondere wenn Quellcode-Fingerprints oder interne Projektnamen mit übertragen werden. Dependency-Track umgeht diese Diskussion komplett, weil die gesamte Analyse auf einem selbst kontrollierten Server läuft, wahlweise in einem deutschen Rechenzentrum oder sogar komplett ohne Internetanbindung im internen Netz.
Der Preis für diese Kontrolle ist der Support. Dependency-Track stützt sich als Open-Source-Projekt auf eine aktive, aber ehrenamtlich getragene Community sowie auf GitHub Issues als primären Kommunikationskanal. Es gibt keinen vertraglich zugesicherten Reaktionszeit-SLA, wer garantierten Support braucht, muss sich an einen der spezialisierten Drittanbieter wenden, die kommerziellen Support um das OWASP-Projekt herum anbieten. FOSSA und Mend liefern dagegen vertraglich geregelten Support direkt mit dem Abonnement, was besonders für Teams ohne eigene Plattform-Ingenieure den Ausschlag geben kann. Für ein Sicherheitsteam, das ohnehin rund um die Uhr auf Meldepflichten nach Artikel 14 der CRA reagieren muss, kann ein garantierter Reaktionszeit-SLA beim Werkzeug selbst den Unterschied machen, ob eine Störung um Mitternacht bis zum nächsten Werktag oder erst nach dem Wochenende bearbeitet wird.
Benchmarks und Marktdaten: Was sich wirklich messen lässt
Ein unabhängiger, reproduzierbarer Benchmark, der Falsch-Positiv-Raten oder Erkennungsraten von Dependency-Track, FOSSA und Mend direkt gegenüberstellt, existiert nach aktueller Recherche nicht. Verfügbare Reviews wie die von AppSecSanta und Safeguard.sh konzentrieren sich auf Funktionsumfang, Preismodelle und Integrationsfähigkeit, nicht auf standardisierte Messwerte pro Werkzeug. Das ist selbst eine wichtige Erkenntnis für Einkäufer: Die Auswahl erfolgt aktuell überwiegend nach Funktionsumfang und Compliance-Passung, nicht nach einer geprüften Erkennungsquote.
Drei Datenpunkte lassen sich dennoch aus verschiedenen Quellen zusammentragen. Erstens das GitHub-Wachstum von Dependency-Track: 176 neue Sterne in 30 Tagen bei insgesamt 4.200 Sternen und 807 Forks, gemessen vom Analysedienst Gittrend im September 2026, ein Indiz für beschleunigte Adoption im Open-Source-Lager. Zweitens der Sprachabdeckungs-Vergleich zwischen der konkret nachprüfbaren FOSSA-Liste mit 21 Einträgen und der pauschalen 200-plus-Angabe von Mend, die zeigt, wie unterschiedlich Anbieter Transparenz handhaben. Drittens ein Blick auf benachbarte Scanner-Tests: In einem separaten Vergleich von Container-Schwachstellenscannern fand Trivy in einem Testlauf 78 CVEs gegenüber 65 bei Snyk, ein Hinweis darauf, dass selbst innerhalb einer Werkzeugkategorie erhebliche Unterschiede in der reinen Fundquote bestehen können. Diese drei Werte sind nicht direkt vergleichbar, weil sie unterschiedliche Tool-Kategorien und Testaufbauten betreffen, sie zeigen aber gemeinsam, wie fragmentiert die Benchmark-Landschaft für Supply-Chain-Sicherheit im Herbst 2026 noch ist.
Für Teams, die vor einer Kaufentscheidung stehen, folgt daraus eine klare Handlungsempfehlung: einen eigenen kleinen Test mit realen, im Unternehmen bereits bekannten Schwachstellen durchführen, statt sich allein auf Herstellerangaben zu verlassen. Ein einfacher Testaufbau lässt sich mit wenig Aufwand realisieren, etwa indem ein bestehendes Projekt mit bekannten veralteten Abhängigkeiten parallel durch zwei der drei Kandidaten laufen gelassen wird und die jeweilige Trefferliste manuell verglichen wird. Dieser Aufwand von wenigen Stunden zahlt sich aus, sobald ein Tool über mehrere Jahre und Dutzende Projekte hinweg im Einsatz ist, weil sich systematische Lücken in der Erkennung sonst erst durch einen tatsächlichen Sicherheitsvorfall zeigen.
Der Cyber Resilience Act: Fristen, die ab sofort gelten
Die europäische Kommission fasst den Zweck der Verordnung so zusammen: “The Cyber Resilience Act (CRA) aims to make sure all digital products are safe from cyber threats.” Für Unternehmen zählen ab September 2026 vor allem zwei Termine. Der 11. September 2026 markiert den Start der Meldepflichten nach Artikel 14 für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle, auch für Produkte, die schon länger im Markt sind. Der 11. Dezember 2027 markiert die volle Anwendung aller grundlegenden Anforderungen, einschließlich der SBOM-Pflicht aus Anhang I.
Das US-amerikanische NIST beschreibt eine Software-Stückliste allgemein als “formal record containing the details and supply chain relationships of various components used in building software”, eine Definition, die inhaltlich der EU-Anforderung entspricht und zeigt, dass sich transatlantisch ein gemeinsames Verständnis von SBOMs als Grundbaustein der Software-Lieferkettensicherheit durchgesetzt hat. Für deutsche Unternehmen bedeutet das konkret: Wer heute noch keine vollständige Inventarliste seiner Softwarekomponenten hat, kann eine ausgenutzte Schwachstelle nicht rechtzeitig identifizieren und läuft Gefahr, die neue Meldefrist zu verpassen.
Kostenbeispiel über drei Jahre
Um die Preisunterschiede greifbarer zu machen, lohnt sich eine einfache Modellrechnung für ein mittelgroßes Team mit 50 Entwicklern und 15 aktiven Projekten über einen Zeitraum von drei Jahren. Die Zahlen basieren auf den oben genannten öffentlichen Preisangaben von FOSSA sowie auf den Marktschätzungen für Mend, die eigenen Betriebskosten für Dependency-Track sind großzügig mit einer mittelgroßen virtuellen Maschine plus verwalteter Datenbank angesetzt.
| Kostenposition | Dependency-Track | FOSSA Business | Mend Enterprise |
|---|---|---|---|
| Lizenzkosten pro Jahr | 0 € | ca. 3.600 $ (15 Projekte à 20 $/Monat) | ca. 48.000–84.000 $ (50 Entw. à 80–140 $/Monat) |
| Infrastruktur/Betrieb pro Jahr | ca. 1.200–2.000 € | 0 $ (SaaS) | 0 $ (SaaS) |
| Geschätzte Gesamtkosten über 3 Jahre | ca. 3.600–6.000 € | ca. 10.800 $ | ca. 144.000–252.000 $ |
Der Abstand zwischen den Modellen ist damit größer als der reine Preisunterschied pro Entwickler und Monat vermuten lässt, weil sich Personenzahl und Projektzahl bei Mend und Dependency-Track unterschiedlich auf die Rechnung auswirken. Bei Mend zahlt das Unternehmen pro Kopf, unabhängig davon, wie viele Projekte tatsächlich aktiv gescannt werden, bei Dependency-Track skaliert nur die Serverlast mit der Projektzahl, was die Kosten bei wachsenden Teams deutlich planbarer macht. Wichtig für die Einordnung: In den Mend-Kosten steckt der gebündelte Funktionsumfang aus SCA, SAST, Container- und IaC-Scanning, während die Dependency-Track- und FOSSA-Zahlen ausschließlich SCA und SBOM-Analyse abdecken. Wer bei den beiden günstigeren Optionen zusätzlich SAST oder Container-Scanning braucht, muss diese Kosten separat einplanen und in die Gesamtrechnung mit aufnehmen.
Praxisbeispiele aus dem DACH-Alltag
Sechs typische Situationen zeigen, wie unterschiedlich die Ausgangslage deutscher Unternehmen und Einzelentwickler bei der Werkzeugwahl aussieht.
- Automobilzulieferer aus Baden-Württemberg: Mit Steuergeräte-Software, die seit Jahren im Feld ist, muss das Unternehmen ab dem 11. September 2026 aktiv ausgenutzte Lücken melden. Ohne bestehende SBOM-Pipeline ist hier zunächst die schnelle Einführung eines Generators plus Dependency-Track als kostengünstiger Einstieg realistisch, zumal die Fertigungslinien historisch gewachsene Firmware aus mehreren Jahrzehnten enthalten, die sich nicht von heute auf morgen ersetzen lässt.
- Berliner SaaS-Startup mit acht Entwicklern: Begrenztes Budget, aber viele unterschiedliche Sprachen im Stack, von TypeScript im Frontend bis Go im Backend. Der FOSSA-Free-Tier mit fünf Projekten und zehn Entwicklern deckt die aktuelle Größe fast exakt ab, ohne dass sofort Kosten entstehen, und wächst mit dem Business-Tarif mit, sobald weitere Repositories dazukommen.
- Regionalbank mit zentralem AppSec-Team von 40 Personen: Strenge interne Richtlinien verlangen SCA, SAST und Container-Scanning aus einer Hand mit lückenlosem Audit-Trail für die Bankenaufsicht. Hier passt das gebündelte Modell von Mend trotz höherer Kosten besser zum Betriebsmodell als drei separate Tools mit drei separaten Vertragspartnern und drei separaten Reporting-Formaten.
- Kommunale IT-Dienstleister: Vergaberichtlinien bevorzugen Open-Source-Software und verlangen Datenhaltung in der EU, oft sogar im eigenen Rechenzentrum der Kommune. Dependency-Track lässt sich vollständig on-premises betreiben und erfüllt beide Vorgaben ohne Sondervertrag, während ein SaaS-Angebot erst durch zusätzliche vertragliche Zusicherungen vergaberechtlich überhaupt zulässig wäre.
- Medizintechnik-Hersteller mit SaMD-Produkten: Die Dokumentationspflichten für Software als Medizinprodukt überschneiden sich stark mit den CRA-Anforderungen, weil beide Regelwerke eine lückenlose Nachverfolgung aller Komponenten über den gesamten Produktlebenszyklus verlangen. Die Kombination aus FOSSA für Lizenzprüfung und Dependency-Track für die laufende Schwachstellenüberwachung deckt beide Regelwerke ab, ohne dass ein einzelnes Tool überladen werden muss.
- Freiberuflicher Entwickler mit einem Kundenprojekt: Wer als Einzelperson eine Web-Anwendung für einen einzigen Auftraggeber pflegt, kommt oft schon mit der kostenlosen Stufe von Dependency-Track oder FOSSA aus. Der administrative Aufwand für eine Docker-Instanz lohnt sich hier meist nur, wenn ohnehin schon eine eigene Serverumgebung für andere Projekte existiert, sonst ist der FOSSA-Free-Tier ohne eigenen Betriebsaufwand die praktischere Wahl.
Migrationsleitfaden: In zehn Schritten zur SBOM-Pipeline
Der Umstieg auf ein SCA-Tool oder der Wechsel zwischen den drei hier verglichenen Plattformen folgt in der Praxis einem ähnlichen Muster, unabhängig davon, welches Werkzeug am Ende zum Einsatz kommt.
- Ist-Analyse: Alle Softwareprodukte mit digitalen Elementen auflisten, die unter die CRA fallen könnten, inklusive interner Tools, die an Kunden ausgeliefert werden.
- Kritikalität priorisieren: Produkte mit Kundenkontakt, Internetzugang oder Netzwerkschnittstelle zuerst absichern, weil sie das höchste Ausnutzungsrisiko tragen.
- Werkzeugwahl treffen: Budget, Deployment-Modell und benötigte Zusatzfunktionen wie SAST oder Container-Scanning gegeneinander abwägen, bevor ein Vertrag unterschrieben wird.
- SBOM-Generator einbauen: Bei Dependency-Track zusätzlich ein Werkzeug wie Syft oder cdxgen in die Build-Pipeline integrieren, da Dependency-Track selbst keine Stücklisten erzeugt.
- Pilotprojekt starten: Eine Testinstanz aufsetzen und mit einem unkritischen, überschaubaren Projekt befüllen, um Fehlalarme und Konfigurationsprobleme früh zu erkennen.
- Policies konfigurieren: Schwellenwerte für Schweregrade, automatische Eskalationen und Lizenzregeln festlegen, damit nicht jede niedrigpriore Meldung manuell geprüft werden muss.
- Rollout durchführen: Bestehende Projekte schrittweise migrieren, beginnend mit den höchsten Risikostufen, und dabei die Ergebnisse gegen die bisherige Vorgehensweise validieren.
- CVD-Politik dokumentieren: Eine Politik für koordinierte Schwachstellenoffenlegung samt Kontaktadresse festhalten, wie es Anhang I der CRA für die technische Dokumentation verlangt.
- Meldewege testen: Interne Eskalationspfade zur zuständigen Stelle für Artikel-14-Fälle festlegen und mit einer simulierten Übung durchspielen, bevor ein echter Vorfall eintritt.
- Audit-Rhythmus etablieren: Vierteljährliche Prüfungen der SBOM-Vollständigkeit einplanen, da neue Abhängigkeiten mit jedem Sprint hinzukommen und alte Stücklisten schnell veralten.
Wer von einer bestehenden WhiteSource- oder frühen Mend-Installation auf ein anderes Tool wechseln will, sollte vor der Kündigung prüfen, ob sich vorhandene Policy-Konfigurationen exportieren lassen. Da Mend keine öffentliche API-Dokumentation für den Export im Self-Service anbietet, empfiehlt sich in diesem Fall ein direkter Kontakt zum Account-Team, bevor Verträge auslaufen.
Was Institutionen zu Software-Stücklisten sagen
Statt einzelner Herstellerzitate lohnt sich bei einem Compliance-Thema wie diesem der Blick auf die Positionen der zuständigen Institutionen selbst. Das NIST definiert eine SBOM als “formal record containing the details and supply chain relationships of various components used in building software”, eine nüchterne, technische Beschreibung, die zeigt, dass es sich nicht um ein optionales Sicherheits-Add-on handelt, sondern um ein Inventardokument mit rechtlicher Bedeutung. Die Europäische Kommission wiederum ordnet den größeren regulatorischen Rahmen ein und erklärt, “The Cyber Resilience Act (CRA) aims to make sure all digital products are safe from cyber threats.” Beide Aussagen zusammen erklären, warum SBOM-Werkzeuge 2026 vom Nischenthema für Sicherheitsteams zur Pflichtaufgabe für jedes Unternehmen mit EU-Kunden geworden sind. Bemerkenswert ist dabei, dass weder NIST noch die Europäische Kommission ein bestimmtes kommerzielles Werkzeug empfehlen oder vorschreiben. Beide Institutionen definieren nur das Ziel, nämlich eine vollständige und maschinenlesbare Komponentenliste, und überlassen die Wahl des Werkzeugs bewusst dem Markt. Genau das erklärt, warum sich in kurzer Zeit ein derart breites Spektrum an Lösungen etabliert hat, vom kostenlosen Open-Source-Projekt bis zur mehrstufigen Enterprise-Suite.
Vor- und Nachteile im Überblick
OWASP Dependency-Track punktet mit Kostenfreiheit, aktiver Weiterentwicklung und voller Kontrolle über den Serverstandort, was für EU-Datenhoheit relevant ist. Das Projekt wächst laut Gittrend-Daten spürbar, mit 176 neuen GitHub-Sternen in nur 30 Tagen, und bleibt durch die Apache-2.0-Lizenz auch für Behörden und regulierte Branchen ohne Lizenzrisiko einsetzbar. Der Nachteil: Das Tool erzeugt selbst keine SBOMs, sondern braucht einen zusätzlichen Generator wie Syft oder cdxgen, und der Betrieb inklusive Updates, Backups und Skalierung liegt vollständig beim eigenen Team. Wer keine Kapazität für Serverbetrieb hat, zahlt die vermeintliche Kostenersparnis am Ende in Arbeitsstunden.
FOSSA bietet eine nachvollziehbare, öffentlich einsehbare Preisliste und eine konkret dokumentierte Sprachunterstützung mit 21 benannten Sprachen und Build-Systemen, dazu einen echten kostenlosen Einstieg für kleine Teams mit bis zu fünf Projekten. Der SaaS-Betrieb entlastet interne Teams von Wartungsaufgaben, und der direkte Import fertiger CycloneDX- oder SPDX-Dateien erleichtert die Zusammenarbeit mit Zulieferern, die bereits eigene SBOMs liefern. Der Nachteil: Bei vielen Projekten steigen die Kosten pro Projekt und Monat schnell an, ein Unternehmen mit 30 aktiven Repositories zahlt im Business-Tarif rechnerisch schon 600 Dollar monatlich. Tiefere Compliance-Features wie der SBOM-Import sind zudem der teureren Enterprise-Stufe vorbehalten.
Mend liefert die größte Funktionsbreite aus einer einzigen Plattform, von SCA über SAST bis Container- und IaC-Scanning, was den Konsolidierungsaufwand für große AppSec-Teams reduziert. Ein Vertrag, eine Rechnung, eine Oberfläche statt drei bis vier separater Werkzeuge mit eigenen Update-Zyklen. Der Nachteil: keine öffentliche Preisliste, kein kostenloser Einstieg mehr seit April 2026, und wichtige Kennzahlen wie die Sprachabdeckung stammen ausschließlich vom Hersteller selbst statt aus einer nachprüfbaren Liste. Kleinere Teams, die nur SCA brauchen, zahlen bei Mend für ungenutzte SAST- und IaC-Module mit, was den effektiven Preis pro genutzter Funktion in die Höhe treibt.
Einsatzempfehlungen: Welches Tool passt zu wem
| Einsatzszenario | Empfehlung | Begründung |
|---|---|---|
| Behörden und öffentliche Verwaltung | Dependency-Track | Open Source, EU-Datenhoheit, keine Lizenzkosten |
| Startups bis 10 Entwickler | FOSSA Free-Tier | Kostenlos bis 5 Projekte / 10 Entwickler |
| Wachsende SaaS-Firmen mit 20-100 Entwicklern | FOSSA Business | Planbare Kosten pro Projekt, breite Sprachabdeckung |
| Konzerne mit zentralem AppSec-Team | Mend | Ein Vertrag für SCA, SAST, Container und IaC |
| Regulierte Branchen mit CRA-Pflicht | Dependency-Track + SBOM-Generator | Volle Kontrolle über Dokumentation und Nachweise |
| Polyglotte Entwicklerteams mit 15+ Sprachen | FOSSA | Konkret dokumentierte Sprachliste statt Pauschalangabe |
Das Urteil: Klare Empfehlung mit Zahlen
Keines der drei Tools gewinnt in jeder Kategorie. Bei den reinen Kosten liegt Dependency-Track uneinholbar vorn, bei 0 € Lizenzkosten gegenüber mindestens 240 Dollar im Jahr bei FOSSA und einem nicht öffentlich bezifferten, aber deutlich höheren Betrag bei Mend. Bei der Funktionsbreite aus einer Hand liegt Mend vorn, mit gebündeltem SCA, SAST, Container- und IaC-Scanning gegen eine einzige Rechnung. Bei der Transparenz der Sprachunterstützung liegt FOSSA vorn, mit 21 konkret benannten Sprachen gegenüber einer nicht aufgeschlüsselten 200-plus-Angabe bei Mend.
Für die meisten deutschen Mittelständler, die jetzt unter Zeitdruck wegen der seit dem 11. September 2026 geltenden CRA-Meldepflicht stehen, ist Dependency-Track der pragmatischste Startpunkt: kostenlos, schnell aufgesetzt, mit voller Kontrolle über den Serverstandort. Wer bereits eine gewachsene, mehrsprachige Codebasis ohne internes Ops-Team für zusätzliche Infrastruktur hat, fährt mit FOSSA besser. Konzerne mit eigenem AppSec-Team, die ohnehin mehrere Sicherheitswerkzeuge konsolidieren wollen, sollten Mend trotz der intransparenten Preisgestaltung in die engere Auswahl nehmen, weil der Aufwand für den Betrieb mehrerer Einzeltools sonst schnell die Lizenzersparnis auffrisst.
Die Zahlen aus der Drei-Jahres-Rechnung stützen dieses Bild: Ein 50-köpfiges Team spart mit Dependency-Track gegenüber Mend Enterprise über drei Jahre gerechnet einen sechsstelligen Dollarbetrag ein, muss dafür aber eigenes Personal für Betrieb und Wartung bereitstellen. Am Ende ist die Wahl weniger eine Frage nach dem objektiv besten Tool als nach der ehrlichen Einschätzung der eigenen Kapazitäten: Wer Zeit, aber kein Budget hat, landet bei Dependency-Track. Wer Budget, aber keine Zeit für Serverbetrieb hat, landet bei FOSSA oder Mend, je nachdem, wie viele Zusatzfunktionen jenseits von SCA wirklich gebraucht werden.
Häufige Fragen
Was ist der Unterschied zwischen SBOM und SCA?
Eine SBOM ist ein Dokument, eine Liste aller Komponenten und Abhängigkeiten einer Software. SCA-Tools wie Dependency-Track, FOSSA oder Mend nutzen diese Liste, um sie automatisiert gegen Schwachstellen- und Lizenzdatenbanken zu prüfen. Die SBOM ist also die Bestandsaufnahme, SCA ist der laufende Prozess, der auf dieser Bestandsaufnahme aufbaut.
Ist Dependency-Track wirklich komplett kostenlos?
Ja, die Software selbst kostet unter der Apache-2.0-Lizenz nichts. Kosten entstehen nur für den eigenen Serverbetrieb, etwa für eine virtuelle Maschine und eine Datenbank, sowie optional für kommerziellen Support durch Drittanbieter.
Welches der drei Tools ist automatisch CRA-konform?
Keines. Kein SCA-Tool stellt allein die Konformität mit dem Cyber Resilience Act her. Alle drei können Teil einer CRA-konformen Dokumentation sein, wenn sie mit den richtigen SBOM-Formaten, einer Politik für koordinierte Schwachstellenoffenlegung und funktionierenden Meldewegen kombiniert werden. Die eigentliche Compliance entsteht erst aus dem Zusammenspiel von Werkzeug, Prozess und Dokumentation, nicht aus der Installation einer einzelnen Software.
Was passiert, wenn mein Unternehmen die SBOM-Pflicht nicht erfüllt?
Die vollständige Durchsetzung der SBOM-Pflicht beginnt am 11. Dezember 2027. Wer bis dahin keine funktionierende Inventarisierung aufgebaut hat, riskiert danach Sanktionen nach dem CRA-Bußgeldrahmen und ist schon vorher im Nachteil, weil sich ohne SBOM aktiv ausgenutzte Schwachstellen kaum fristgerecht nach Artikel 14 melden lassen.
Kann ich Dependency-Track und FOSSA gleichzeitig einsetzen?
Technisch ja, viele Teams kombinieren mehrere Tools für unterschiedliche Zwecke, etwa FOSSA für Lizenz-Compliance im Frontend-Stack und Dependency-Track für die zentrale Schwachstellenüberwachung aller SBOMs. Der Mehraufwand liegt dann in der Pflege zweier separater Policy-Konfigurationen und in der Abstimmung, welches Tool im Zweifel die maßgebliche Quelle für Audits und Meldungen an Behörden ist, damit es bei einem echten Vorfall keine widersprüchlichen Zahlen aus zwei Systemen gibt.
Welches SBOM-Format sollte ich wählen, CycloneDX oder SPDX?
Beide Formate gelten laut Compliance-Leitfäden zur CRA als geeignet, empfohlen werden CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Da Dependency-Track nativ auf CycloneDX aufbaut, ist dieses Format oft die praktischere Wahl, wenn Dependency-Track Teil der Werkzeugkette ist.
Brauchen auch kleine Unternehmen ein SBOM?
Wenn das Unternehmen Software mit digitalen Elementen in der EU in Verkehr bringt, gilt die CRA unabhängig von der Unternehmensgröße. Es gibt keine pauschale Ausnahme für kleine Firmen oder Einzelentwickler, lediglich der Umfang der geforderten Prozesse kann sich je nach Risikoklasse des Produkts unterscheiden. Kleine Teams profitieren hier besonders von kostenlosen Werkzeugen wie Dependency-Track oder dem FOSSA-Free-Tier, weil sich Compliance-Aufwand ohne zusätzliches Lizenzbudget umsetzen lässt.
Wie lange dauert die Einführung eines SCA-Tools in der Praxis?
Eine Dependency-Track-Instanz lässt sich dank Docker-Umgebung innerhalb weniger Stunden aufsetzen, die eigentliche Arbeit steckt in der Anbindung aller Projekte und der Konfiguration sinnvoller Schwellenwerte. Bei FOSSA und Mend übernimmt der Anbieter Teile des Onboardings, wodurch sich die reine Einrichtungszeit verkürzt, die organisatorische Umstellung auf neue Prozesse dauert aber unabhängig vom Tool meist mehrere Wochen. Realistisch sollten Teams für die vollständige Migration aller Projekte, inklusive Schulung der Entwickler und Feinjustierung der Policies, drei bis sechs Monate einplanen, bevor sich das neue Werkzeug im Arbeitsalltag reibungslos anfühlt.
