SCA-Tools Open Source 2026: Trivy, Grype und OSV-Scanner im Test, dazu OpenCVE zur Überwachung neuer CVEs

Was prüft ein SCA-Tool?

Ein SCA-Tool, kurz für Software Composition Analysis, listet die Open-Source-Pakete Ihres Projekts auf, auch die, die Ihre Abhängigkeiten selbst nachziehen, und gleicht jede exakte Version mit Advisory-Datenbanken wie der von GitHub und OSV ab. Es meldet bekannte Schwachstellen, die korrigierte Version, sofern es eine gibt, und bei manchen Tools die Lizenz jedes Pakets.

Die Liste ist länger, als das Manifest vermuten lässt. Am 5. November 2026 deklarierte das Repository unserer eigenen Website 39 Pakete in seiner package.json, 17 Abhängigkeiten und 22 Dev-Abhängigkeiten, und seine pnpm-lock.yaml führte 965 auf. Installiert wird, was im Lockfile steht, also übersieht ein Scanner, der nur das Manifest liest, die übrigen 926.

SCA liest nicht den Code, den Ihr Team schreibt. Das ist die Aufgabe von SAST, und beide beantworten unterschiedliche Fragen: SAST sucht eine Schwachstelle in Ihrem Code, SCA eine veröffentlichte Schwachstelle in einem Paket, das Sie ausliefern. Keines von beiden erkennt ein bösartiges Paket, zu dem es noch kein Advisory gibt, und genau so kommt Slopsquatting, der Angriff auf Paketnamen, die sich KI-Modelle ausdenken, durch.

Welche Open-Source-SCA-Tools werden 2026 noch gepflegt?

Trivy, Grype, OSV-Scanner, Dependency-Check, Dependency-Track und pip-audit haben laut GitHub am 5. November 2026 alle ein Release aus dem Jahr 2026, und keines ist archiviert. Alle sechs stehen unter Apache-2.0. Sie unterscheiden sich darin, was sie lesen, woher ihre Daten stammen und was nach dem Scan passiert, und Dependency-Track ist eine Plattform, die Ergebnisse speichert, kein Scanner für die CI.

OSV-Scanner ist Googles Frontend für OSV.dev, eine Datenbank in einem offenen Format, die die GitHub Advisory Database, die Schwachstellendatenbanken von PyPI und Go, RustSec und weitere Quellen zusammenführt. Trivy scannt Repositories, Container-Images und Infrastrukturcode mit einem einzigen Binary. Grype scannt Container-Images, Dateisysteme und SBOMs und liest die Paketlisten, die Syft erstellt, das zweite Tool von Anchore. Dependency-Check und Dependency-Track sind Flagship-Projekte der OWASP. pip-audit wird unter dem Dach der Python Packaging Authority gepflegt.

Zwei Tools, die oft unter SCA einsortiert werden, aktualisieren Abhängigkeiten, ohne sie im selben Sinn zu scannen. Dependabot, dessen Kernbibliothek unter MIT steht, öffnet Pull Requests mit Updates, und Renovate unter AGPL-3.0 tut dasselbe für eine breite Palette von Sprachen und Plattformen. Beide halten Versionen aktuell, und keines führt Buch darüber, was Sie ausgeliefert haben.

Was hat jedes Tool in demselben Repository gefunden?

In unserem Test vom 5. November 2026 liefen fünf SCA-Tools auf einem Repository mit veralteten Abhängigkeiten in vier Ökosystemen und meldeten zusammen 109 unterschiedliche Schwachstellen in 21 Paketen. OSV-Scanner fand 109, Trivy 105, Grype 104. npm audit fand dieselben 43 npm-Schwachstellen wie die anderen, pip-audit dieselben 21 in den vier gepinnten Python-Paketen.

Wir haben ein kleines Repository gebaut, das wie das Backend eines Onlineshops aussieht, mit einem Dienst pro Ökosystem und absichtlich festgeschriebenen Versionen aus 2020 und 2021:

• eine Node.js-API mit express 4.17.1, lodash 4.17.20 und axios 0.21.1 und einem am selben Tag aufgelösten Lockfile mit 53 Paketen;
• ein Python-Worker, dessen requirements.txt requests 2.25.0, urllib3 1.26.4, PyYAML 5.3.1 und Jinja2 2.11.2 pinnt;
• ein Java-Abrechnungsdienst, dessen pom.xml log4j-core 2.14.1 und commons-text 1.9 deklariert;
• ein Go-Gateway auf einer Version von golang.org/x/net vom November 2021 und auf golang.org/x/text 0.3.7, dessen Code den HTML-Parser des ersten und eine einzige Breitenfunktion des zweiten aufruft.

Jedes Tool lief mit seinen Standardeinstellungen. Wir haben die Befunde über CVE-, GHSA-, Go- und PyPA-Kennungen hinweg zusammengeführt, anhand der Aliase jedes Tools und derer von OSV, damit eine Schwachstelle, die unter zwei Namen gemeldet wird, nur einmal zählt.

Die Zeiten für Trivy und Grype stammen aus einem zweiten Durchlauf. Beim ersten verbrachte jedes Tool den Großteil der Zeit mit dem Download einer Schwachstellendatenbank, 132 MiB bei Trivy, und brauchte 19,2 s beziehungsweise 101,7 s. OSV-Scanner fragt standardmäßig online bei osv.dev an.

Drei Unterschiede erklären die Lücken:

• Eine requirements.txt ohne Lockfile listet vier Pakete und nichts darunter. OSV-Scanner löste auf, wovon requests selbst abhängt, und fand drei weitere Advisories in idna und certifi. Trivy, Grype und pip-audit lasen die vier gepinnten Zeilen und hörten dort auf.
• Auf der Java-Seite braucht log4j-core die Bibliothek log4j-api, und commons-text braucht commons-lang3. Trivy und OSV-Scanner lösten beide auf und fanden jeweils ein Advisory; Grype las nur die zwei deklarierten Pakete.
• In Go führte Trivy CVE-2023-44487, die HTTP/2-Rapid-Reset-Lücke, für golang.org/x/net nicht auf, Grype und OSV-Scanner dagegen schon.

Bei npm stimmten die vier Tools bei allen 43 überein, und 13 davon stecken in sechs nicht deklarierten Paketen, die express mitbringt: qs, body-parser, path-to-regexp, cookie, send und serve-static. Log4Shell, CVE-2021-44228, fanden Trivy, Grype und OSV-Scanner, und das JSON von Grype enthielt zusätzlich den EPSS-Wert von 0,99999 und den Eintrag im CISA-Katalog Known Exploited Vulnerabilities. Die Schweregrade waren nicht immer gleich: Für dieselben Befunde stufte Trivy vier als kritisch ein, Grype fünf.

Trivy, Grype oder OSV-Scanner: Welches Tool sollten Sie einsetzen?

Nehmen Sie OSV-Scanner, wenn Ihr Code Go-Dienste oder Maven- und Python-Projekte ohne Lockfile umfasst, denn es löste auf, was die anderen übersahen, und seine Go-Call-Analyse reduziert das Rauschen. Nehmen Sie Trivy, wenn Sie ein Binary für Abhängigkeiten, Container-Images, IaC und Lizenzen wollen. Nehmen Sie Grype, wenn Sie schon SBOMs mit Syft erzeugen oder EPSS- und KEV-Daten neben jedem Befund sehen wollen.

Die drei sind sich einig, sobald ein Lockfile die Eingabe ist, wie unsere npm-Ergebnisse zeigen. Die Wahl hängt also davon ab, was Sie sonst noch scannen und was Sie mit der Ausgabe machen:

• Trivy passt zu einem Team, das einen einzigen Scanner in der CI für mehrere Schichten will. Derselbe Befehl scannt ein Repository, ein Image oder einen Terraform-Ordner, und --scanners license nimmt die Lizenzen dazu. Seine Datenbank wird einmal heruntergeladen und dann zwischengespeichert, deshalb dauerte unser zweiter Durchlauf eine Sekunde.
• Grype passt zu einem Team, das bereits SBOMs erstellt. Sie scannen die SBOM einmal beim Build und später erneut, ohne neu zu bauen, und sortieren nach den EPSS- und KEV-Daten, die sein JSON mitliefert.
• OSV-Scanner passt zu einem Team, dem Präzision wichtig ist. Es löste transitive Abhängigkeiten für Maven auf und in unserem Test auch für Python, seine Go-Call-Analyse ist standardmäßig aktiv, und sein Befehl fix schlägt Upgrades für npm- und Maven-Projekte vor.

npm audit und pip-audit bleiben als erste Prüfung eines Entwicklers vor dem Commit nützlich, weil sie keine Installation brauchen, aber jedes deckt nur ein Ökosystem ab.

Sagt ein SCA-Tool, ob eine Schwachstelle erreichbar ist?

In unserem Test tat das nur OSV-Scanner, und nur für Go. Seine standardmäßig aktive Call-Analyse markierte 12 der 31 Go-Schwachstellen als von unserem Code aufgerufen und 18 als nicht aufgerufen; eine ließ sich nicht analysieren. Seine Standardtabelle zeigte für das Go-Gateway 13 von 31 Schwachstellen und für golang.org/x/text gar keine.

Die Aufrufe passten zu dem, was unser Code tut. Das Gateway nutzt den HTML-Parser von x/net, also erschienen die Advisories zu Parser und Renderer als aufgerufen, die HTTP/2-Advisories desselben Moduls dagegen nicht, ein Codepfad, den das Gateway nie berührt. Die drei Advisories zu x/text betreffen Funktionen, die das Gateway nicht aufruft. OSV-Scanner nutzt dafür govulncheck, die Bibliothek des Go-Projekts selbst, und --all-vulns holt die ausgeblendeten Befunde zurück. Die Call-Analyse für Rust ist als experimentell markiert und führt die Build-Skripte Ihrer Abhängigkeiten aus.

Für npm, Python und Java ging kein Open-Source-Tool in unserem Test so weit, und jeder Befund zählt gleich, ob Ihr Code die verwundbare Funktion aufruft oder nicht. Diese Lücke schließt Reachability, und es ist dasselbe Sortierproblem, das wir in warum ein Scanner 1.200 Schwachstellen meldet, von denen nur 12 echt sind beschreiben. Die SCA von CybeDefend arbeitet auf dieser Ebene: Sie markiert jedes Paket als genutzt, möglicherweise genutzt oder ungenutzt, damit die Pakete, die Ihr Code wirklich aufruft, zuerst kommen. Wie CybeDefend SCA umsetzt zeigt diese Sortierung.

Lohnt sich OWASP Dependency-Check noch?

Dependency-Check 13.0.0 wird gepflegt und ist ein Flagship-Projekt der OWASP, blieb in unserem Test aber beim ersten Datenbank-Update mit „Invalid API Key“ stehen und lieferte kein Ergebnis. Laut README werden Nutzer „highly“ ermutigt, einen NVD-API-Schlüssel zu beantragen, und ohne ihn seien Updates „extremely slow“. Planen Sie einen Schlüssel und eine zwischengespeicherte Datenbank ein, bevor Sie es einführen.

Für Java- und .NET-Builds bleibt es eine solide Wahl, weil es dort die kompilierten JARs und Assemblies liest, und seine Maven- und Gradle-Plugins laufen direkt im Build. Zwei Punkte belasten es 2026. Es ordnet Pakete über CPE-Kennungen aus der NVD zu, deshalb ist der Schlüssel so wichtig, und Sonatypes OSS Index, eine weitere seiner Datenquellen, verlangt seit September 2025 Zugangsdaten. Ohne sie, so das README, wird Dependency-Check „automatically disable the OSS Index analyzer“.

Was übersehen SCA-Tools?

SCA-Tools übersehen drei Dinge: bösartige Pakete, zu denen es noch kein Advisory gibt, Schwachstellen in Code, der ohne Paketmanager kopiert wurde, und alles in einer Abhängigkeit, das kein Lockfile und kein Manifest beschreibt. Sie melden außerdem nur bekannte Probleme, ein gestern veröffentlichtes Paket mit Hintertür gilt also als sauber, bis jemand ein Advisory einreicht.

Coding-Agenten bringen eine vierte Lücke mit, den Zeitpunkt. Claude Code, Cursor oder Codex können mitten in einer Aufgabe eine Abhängigkeit hinzufügen, und der Scan in der CI läuft erst, wenn der Agent längst weitergemacht hat, manchmal erst nach dem Öffnen des Pull Requests. Ein Agent, der die Befunde des Projekts während der Arbeit lesen kann, wählt von Anfang an die korrigierte Version, wie wir in Live-Zugriff von Coding-Agenten auf alle Befunde beschreiben. VibeDefend gibt dem Agenten die Abhängigkeitsbefunde des Projekts über MCP, während er schreibt, ob Claude Code, Cursor, Codex, Devin Desktop oder GitHub Copilot, damit er in derselben Sitzung auf die korrigierte Version wechselt. So funktioniert VibeDefend zeigt den Ablauf.

Zwischen zwei Scans: neue CVEs mit OpenCVE im Blick behalten

Ein SCA-Scan ist eine Momentaufnahme. Er listet die bekannten Schwachstellen Ihrer Abhängigkeiten an dem Tag, an dem er läuft, und eine CVE, die am nächsten Morgen zu einem ausgelieferten Paket erscheint, bleibt bis zum nächsten Scan unsichtbar, es sei denn, eine Plattform wie Dependency-Track prüft die dort gespeicherten SBOMs erneut. Zudem sieht SCA nur, was Sie selbst bauen, und kein Lockfile führt die VPN-Appliance oder den Datenbankserver auf, die Ihr Team neben dem Code betreibt.

Diese Überwachung ist die Aufgabe von OpenCVE. Sie abonnieren die Hersteller und Produkte, die Sie betreffen, etwa Fortinet oder WordPress, und OpenCVE benachrichtigt Sie per E-Mail, Slack oder Webhook, sobald eine CVE dazu veröffentlicht oder aktualisiert wird. Es gibt keinen Agenten zu installieren und nichts zu scannen. OpenCVE bezieht seine Daten unter anderem von MITRE, NVD, CISA KEV, Red Hat und Vulnrichment und stellt für jede CVE CVSS, EPSS und KEV nebeneinander, sodass Sie eine Lücke, die Angreifer bereits ausnutzen, von einer unterscheiden, die nur einen hohen Score hat. Es läuft als Cloud-Dienst mit kostenlosem Plan oder selbst gehostet als Community-Edition, deren Code unter der Business Source License auf GitHub liegt.

OpenCVE ist kein SCA-Scanner, denn es liest kein Lockfile und scannt kein Repository, und genau deshalb ergänzen sich beide: Ihr SCA-Tool sagt Ihnen, welche Pakete Sie nutzen, und OpenCVE meldet sich an dem Tag, an dem eine neue CVE eines der Produkte trifft, denen Sie folgen.

Wie bringen Sie SCA in die CI und behalten eine einzige Liste?

Lassen Sie den Scanner bei jedem Pull Request auf den Lockfiles laufen, schreiben Sie SARIF für die Code-Plattform und eine SBOM für die Nachweise, und lassen Sie den Build nur bei kritischen oder hohen Befunden mit verfügbarem Fix scheitern. Bewahren Sie die SBOM jedes Releases auf, denn ein neues Advisory betrifft oft eine Version, die Sie vor Monaten ausgeliefert haben.

Ein minimales Setup mit den Tools aus unserem Test:

# Bei jedem Pull Request: Lockfiles, SARIF für Code Scanning
osv-scanner scan source -r --format sarif --output-file osv.sarif .
trivy fs --scanners vuln --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 .

# Bei jedem Release: SBOM aufbewahren und später erneut scannen
trivy fs --format cyclonedx --output sbom.cdx.json .
grype sbom:sbom.cdx.json

Dependency-Track nimmt die CycloneDX-Datei entgegen und überwacht die Komponenten jeder Version jeder Anwendung, die es verwaltet. Das beantwortet die Frage, die ein Auditor stellt: Welches Release enthielt die verwundbare Version, und wann wurde sie behoben? Für Teams, die sich auf SOC 2 oder ISO 27001 vorbereiten, zählt diese Historie mehr als der Scan selbst.

Ein zweiter Scanner bringt gleichzeitig zusätzliche Befunde und Duplikate. Unser Test erzeugte 451 Einträge in fünf JSON-Dateien mit fünf verschiedenen Schemata für 109 unterschiedliche Schwachstellen, dasselbe Zusammenführungsproblem wie bei sechs Open-Source-Secret-Scannern auf einem präparierten Repository. CybeDefend Open Source ist für genau diesen Schritt gebaut. Es führt die Scanner aus, die Sie wählen, jedes Tool, das SARIF schreibt, und legt die Ergebnisse in einer einzigen deduplizierten Queue ab, kostenlos und auf Ihren Servern. Es startet bald, und die Warteliste ist offen.

Häufige Fragen

Welches Open-Source-SCA-Tool ist 2026 das beste?

In unserem Test vom 5. November 2026 fand OSV-Scanner 2.7.0 alle 109 unterschiedlichen Schwachstellen in einem Repository mit veralteten npm-, Python-, Maven- und Go-Abhängigkeiten, Trivy 0.76.1 fand 105 und Grype 0.121.0 fand 104. OSV-Scanner löste mehr transitive Abhängigkeiten auf; Trivy deckt mit einem Binary mehr Schichten ab.

Ist Trivy ein SCA-Tool?

Ja. Trivy durchsucht Lockfiles und Manifeste nach bekannten Schwachstellen in Open-Source-Paketen, also Software Composition Analysis, und scannt außerdem Container-Images, Infrastrukturcode, Secrets und Lizenzen. Es steht unter Apache-2.0 und wird von Aqua Security gepflegt. In unserem Test fand es 105 von 109 Schwachstellen und löste transitive Maven-Abhängigkeiten auf.

Trivy vs. Grype: Wo liegt der Unterschied?

Beide sind Scanner unter Apache-2.0, die Repositories, SBOMs und Container-Images lesen. Trivy scannt zusätzlich IaC, Secrets und Lizenzen und löste in unserem Test transitive Maven-Abhängigkeiten auf, mit 105 gefundenen Schwachstellen. Grype, das auf den Paketlisten von Syft aufbaut, fand 104, übersah die transitiven Maven-Pakete und ergänzt sein JSON um EPSS-Werte und Einträge aus dem CISA-KEV-Katalog.

Braucht OWASP Dependency-Check einen NVD-API-Schlüssel?

Das README nennt einen Schlüssel dringend empfohlen und warnt, dass Updates ohne ihn extrem langsam sind. In unserem Test von Version 13.0.0 am 5. November 2026 brach das erste NVD-Update mit „Invalid API Key“ ab, und kein Scan konnte laufen. Beantragen Sie einen Schlüssel bei der NVD und speichern Sie die Datenbank zwischen den CI-Läufen zwischen.

Was ist der Unterschied zwischen SCA und SAST?

SAST liest den Code, den Ihr Team schreibt, und sucht nach verwundbaren Mustern wie einer Injection. SCA liest Ihre Manifeste und Lockfiles und meldet die veröffentlichten Schwachstellen in den Open-Source-Paketen, die Sie nutzen, auch in denen, die Ihre Abhängigkeiten nachziehen. Ein Projekt braucht beides: Das Lockfile unserer eigenen Website listet 965 Pakete bei 39 deklarierten.

Reichen npm audit und pip-audit aus?

Für eine erste Prüfung ja, denn sie brauchen keine Installation und fanden auf den Paketen, die sie lesen, dieselben npm- und Python-Schwachstellen wie die großen Tools. Jedes deckt aber nur ein Ökosystem ab, keines schreibt SARIF, und pip-audit prüft auf einer Requirements-Datei ohne Lockfile nur die Zeilen, die dort stehen.

Was bedeutet Reachability bei SCA?

Reachability sagt Ihnen, ob Ihr Code die verwundbare Funktion einer Abhängigkeit aufruft oder das Paket nur importiert. In unserem Test markierte die Go-Call-Analyse von OSV-Scanner 18 von 31 Go-Schwachstellen als nicht aufgerufen und blendete sie in ihrer Standardtabelle aus. Für npm, Python und Java traf keines der Open-Source-Tools, die wir eingesetzt haben, diese Unterscheidung.

Warnt ein SCA-Tool, wenn eine neue CVE veröffentlicht wird?

Nicht zwischen zwei Scans. Ein Scanner meldet, was am Tag des Laufs bekannt ist. Lassen Sie ihn deshalb in der CI bei jeder Änderung und zusätzlich zeitgesteuert laufen, etwa täglich, um seitdem veröffentlichte Advisories zu erfassen. Wer noch am selben Tag erfahren will, dass eine CVE ein genutztes Produkt trifft, ergänzt einen CVE-Überwachungsdienst wie OpenCVE, der per E-Mail, Slack oder Webhook benachrichtigt, sobald eine CVE zu einem abonnierten Hersteller oder Produkt veröffentlicht oder aktualisiert wird.