Snyk VulnBench JS 1.0: Finden LLMs zweimal dieselben Fehler?

Wir haben 300 Scans zur Schwachstellenerkennung durchgeführt, um zu messen, wie reproduzierbar eine agentische LLM-Sicherheitsprüfung bei identischem Code, Prompt und Harness ist. Das wichtigste Ergebnis ist nicht, dass ein Scanner eine selbstreferenzielle Rangliste „gewinnt“. Vielmehr sind LLM-Sicherheitsergebnisse unterschiedlich reproduzierbar: Mit der Referenz übereinstimmende Ergebnisse waren stabil, zusätzliche Modellmeldungen variierten jedoch stark von Durchlauf zu Durchlauf.

Einfach ausgedrückt: Wenn Claude Fehler außerhalb der Snyk-Code-Referenzliste meldete, waren diese zusätzlichen Meldungen oft inkonsistent. In 250 Modelldurchläufen traten 80 der 161 eindeutigen, nicht übereinstimmenden Ergebnisse nur in einer von fünf identischen Wiederholungen auf, während nur 22 in allen fünf vorkamen. Wenn Claude jedoch einen Referenzbefund erkannte, war das Verhalten deutlich stabiler: 134 der 158 eindeutigen, mit der Referenz übereinstimmenden Ergebnisse traten in allen fünf Wiederholungen auf. Diese Aufteilung ist das zentrale Ergebnis von Snyk VulnBench JS 1.0.

Der Benchmark zeigt außerdem, dass sich die Ansätze ergänzen. Die Modelle erkannten zuverlässig bekannte, aussagekräftige Exploit-Muster und machten in einem Fall wahrscheinlich eine Lücke bei den Snyk-Code-Ergebnissen sichtbar. Snyk Code SAST war deterministisch und besser darin, wiederkehrende Datenfluss-Senken systematisch zu erfassen. Zudem erzielte es bei Schwachstellenscans deutlich kurze Laufzeiten. Keines der Ergebnisse spricht dafür, eine Technik durch die andere zu ersetzen. Die Daten sprechen dafür, sie zu kombinieren.

Die wichtigsten Ergebnisse:

• Die LLM-Konfiguration mit dem höchsten Recall fand nur 81 % der Snyk-Code-Referenzschwachstellen.

• Die am besten bewertete LLM-Konfiguration erreichte einen Snyk-Referenz-F1-Wert von 75,4 % und lag damit 24,6 Prozentpunkte hinter der deterministischen Reproduktion der SAST-Referenz.

• Fast 50 % der ausschließlich von LLMs gemeldeten Schwachstellen traten nur in 1 von 5 identischen Scans auf.

• Das LLM mit dem höchsten Recall erzeugte auch die unübersichtlichste Warteschlange: 41 % seiner Meldungen lagen außerhalb der Snyk-Code-Referenzmenge.

• Im größten, einer App nachempfundenen Testprojekt erreichte das beste Modell nur einen Snyk-Referenz-F1-Wert von 40,0 % und übersah wiederholt Path-Traversal- und Ressourcenlimit-Schwachstellen.

Warum LLM-Sicherheitsprüfungen reproduzierbar sein müssen

Coding-Agenten sind inzwischen Teil des Entwicklungsprozesses. Sie schreiben Code, ändern Pull Requests, erklären Änderungen und werden zunehmend für Code- und Anwendungssicherheitsprüfungen eingesetzt, bevor ein Mensch den Diff liest. Damit wird Zuverlässigkeit zu einer Produktfrage: Meldet derselbe Agent dieselben Sicherheitsprobleme, wenn er denselben anfälligen Code zweimal prüft?

Traditionelle SAST-Tools sind auf deterministische Ergebnisse ausgelegt. Wenn Code und Regeln unverändert bleiben, sollte auch die Ausgabe gleich bleiben. Bei LLMs ist das anders. Sie können unbekannten Code analysieren, Risiken verständlich beschreiben und manchmal Probleme erkennen, die ein statischer Analyzer übersieht. Sie können aber auch von Durchlauf zu Durchlauf variieren, benachbarte Probleme übermäßig melden oder nach einem repräsentativen Beispiel eines wiederkehrenden Musters aufhören.

Snyk VulnBench JS 1.0 wurde entwickelt, um dieses Verhalten messbar zu machen. Der Benchmark verwendet kleine JavaScript- und Express-Anwendungen, sodass sich jeder Durchlauf überprüfen lässt. Es geht nicht darum, ein ganzes Monorepo zu simulieren. Ziel ist es, das Modellverhalten unter wiederholten, kontrollierten Bedingungen messbar zu machen.

Benchmark-Design: 300 wiederholte Sicherheitsprüfungen

Der Benchmark umfasst 10 JavaScript-Testprojekte mit 44 Snyk-Code-Referenzbefunden. Jedes Testprojekt ist eine kleine Express-basierte Anwendung, von kompakten Snippets in einer einzelnen Datei bis hin zu einer größeren To-do-App mit Server-Routen, Datenbankstatus, Uploads und Frontend-JavaScript.

Wir haben sechs Konfigurationen bewertet:

Jede Konfiguration führte jede Aufgabe fünfmal aus: 10 Aufgaben x 6 Konfigurationen x 5 Wiederholungen = 300 Durchläufe. Die Modellkonfigurationen verwendeten denselben direkten Prüf-Prompt und gaben die Befunde als strukturiertes JSON zurück. Das Modell konnte die Projektdateien lesen, nicht jedoch die Referenzdatei findings.json.

Snyk Code definiert die Referenzmenge für diesen Benchmark. Sein Ergebnis von 100 % ist also keine Aussage zur Genauigkeit bei allen möglichen Schwachstellen in den Projekten. Es bedeutet, dass Snyk Code seine eigenen Referenzbefunde bei wiederholten Durchläufen deterministisch reproduzierte. Anhand dieser Referenzmenge messen wir die Übereinstimmung der Modelle, ihre Varianz und die Abweichungen im Modellverhalten.

Die Bewertungsmethode ist bewusst großzügig: Ein Modellbefund zählt, wenn er denselben Schwachstellentyp wie ein Referenzbefund meldet. Datei, Zeile, Schweregrad oder Source-to-Sink-Pfad müssen nicht übereinstimmen. Wir geben den Snyk-Referenz-F1-Wert an: das harmonische Mittel aus Präzision und Recall, wenn Snyk-Code-Befunde als Referenzmenge gelten. Als Maß für die Übereinstimmung ist er hilfreich, aber nicht die Hauptaussage.

Da dieser Benchmark keine unabhängige, umfassend geprüfte Ground-Truth-Menge verwendet, sollte der Snyk-Referenz-F1-Wert nicht als tatsächliche Genauigkeit bei der Erkennung von Schwachstellen verstanden werden. Ein Modell mit geringerer Übereinstimmung mit der Snyk-Code-Referenzmenge könnte bei einer unabhängigen Ground Truth besser abschneiden, wenn einige seiner nicht übereinstimmenden Befunde zutreffen oder es Probleme vermeidet, die in der Referenzmenge überbewertet werden. In diesem Bericht beantwortet der Snyk-Referenz-F1-Wert eine engere Frage: Wie genau und wie reproduzierbar stimmen Modellbefunde mit den Snyk-Code-Referenzbefunden überein?

Ergebnis 1: Die Reproduzierbarkeit von LLMs variierte je nach Modellkonfiguration

Auf Konfigurationsebene zeigt sich die Reproduzierbarkeit im Verhältnis von Ergebnis und Varianz. Das bessere Ergebnis liegt links oben: hohe Übereinstimmung mit der Referenzmenge und geringe Varianz bei wiederholten Durchläufen. Snyk Code SAST befindet sich mit einem Snyk-Referenz-F1-Wert von 100,0 % und einer Standardabweichung von 0,0 Prozentpunkten in dieser Ecke, da es seine Referenzmenge deterministisch reproduziert hat. Die Claude-Modellkonfigurationen verteilen sich weiter unten und rechts. Claude Sonnet 4.6 High weist mit 3,5 Prozentpunkten die größte Varianz im Gesamtergebnis auf.

Abbildung 1: Snyk-Referenz-F1 im Verhältnis zur Standardabweichung des Snyk-Referenz-F1-Gesamtergebnisses. Bessere Werte liegen weiter links oben: höhere Übereinstimmung bei geringerer Varianz über wiederholte Durchläufe. Snyk Code SAST ist violett hervorgehoben und weist keine Varianz auf.

Das Streudiagramm macht zwei Dinge gleichzeitig sichtbar. Erstens dient Snyk Code in diesem Benchmark der deterministischen Reproduktion der Referenz, nicht der probabilistischen Prüfung. Zweitens ordnen sich die Modellkonfigurationen nicht nach Kosten oder Aktualität: Claude Opus 4.6 Medium und High liegen mit geringer Varianz und dem besten Modell-F1-Wert nahe beieinander, während Claude Opus 4.7 Max und Claude Sonnet 4.6 High weiter rechts liegen. Ihre Ergebnisse variierten also stärker zwischen den Durchläufen.

Über alle Modellkonfigurationen hinweg traten 80 von 161 eindeutigen, nicht übereinstimmenden Befundsignaturen nur in einem von fünf wiederholten Durchläufen auf. Diese Gesamtbetrachtung erklärt einen Teil der Varianz, doch noch aufschlussreicher ist die Aufschlüsselung nach Modell:

Abbildung 2: Anteil der eindeutigen, nicht übereinstimmenden Befundsignaturen je Modellkonfiguration, die nur in einem von fünf wiederholten Durchläufen auftraten. Signatur = Aufgabe + Schwachstellentyp + Datei + Zeile, gruppiert nach Modellkonfiguration.

Die folgende Tabelle enthält die genauen Werte der vorherigen Grafik sowie die beiden wichtigsten Stabilitätskennzahlen.

Die Instabilität verteilt sich nicht gleichmäßig auf die Modelle. Claude Sonnet 4.6 Medium erzeugte die größte Menge nicht übereinstimmender Befunde: 60 eindeutige Signaturen, von denen 37 nur in einem von fünf Durchläufen auftraten. Claude Sonnet 4.6 High und Claude Opus 4.7 Max zeigten ein ähnliches Muster: Viele zusätzliche Meldungen erschienen nur einmal und traten nicht erneut auf. Im Gegensatz dazu weist Claude Opus 4.6 Medium mit 0,0 % in der Grafik eine hohe Stabilität und wenige einmalige Befunde auf. Alle zusätzlichen Meldungen traten in mindestens zwei Durchläufen auf; keine erschien nur in einem der fünf wiederholten Durchläufe.

Die Opus-4.6-Konfigurationen verhielten sich anders. Sie erzeugten deutlich weniger nicht übereinstimmende Befunde, und ihre zusätzlichen Meldungen waren stabiler. Das macht nicht jede zusätzliche Meldung korrekt, verändert aber die operative Einschätzung: weniger überraschende Befunde, weniger einmalige Meldungen und weniger Aufwand bei der Triage.

Die folgende Grafik verdeutlicht, wie die meisten Konfigurationen außerhalb von Opus 4.6 Schwierigkeiten hatten, ihre zusätzlichen (nicht übereinstimmenden) Befunde über wiederholte Durchläufe hinweg stabil zu halten. Sowohl Claude Sonnet 4.6 Medium als auch High zeigten eine geringe Reproduzierbarkeit: Nur 8,3 % beziehungsweise 9,3 % der nicht übereinstimmenden Befunde traten in allen fünf Durchläufen auf. Auch Claude Opus 4.7 Max schnitt mit einer Stabilität von nur 16,7 % schlecht ab. Claude Opus 4.6 Medium und High wiesen bei ihren nicht übereinstimmenden Befunden dagegen eine deutlich höhere Stabilität auf (60,0 % beziehungsweise 50,0 %). Das unterstreicht, dass nicht übereinstimmende Befunde der Sonnet-Modelle und der neueren Konfiguration Claude Opus 4.7 Max weniger vorhersehbar und stärker verrauscht waren.

Abbildung 3: Anteil der eindeutigen, nicht übereinstimmenden Befundsignaturen, die bei jeder Modellkonfiguration in allen fünf wiederholten Durchläufen auftraten.

Bei den übereinstimmenden Befunden zeigt sich ein anderes Bild. Wenn ein Modell einen Snyk-Code-Referenzbefund fand, fand es ihn in der Regel wiederholt. Claude Opus 4.6 Medium erkannte 25 eindeutige Referenzbefunde und reproduzierte alle 25 in fünf Durchläufen. Claude Opus 4.6 High reproduzierte 25 von 26. Selbst die verrauschteren Sonnet-Konfigurationen reproduzierten 29 von 36 mit der Referenz übereinstimmenden Befunden.

Abbildung 4: Anteil der eindeutigen Snyk-Code-Referenzbefunde, die bei jeder Modellkonfiguration in allen fünf wiederholten Durchläufen erkannt wurden.

Abbildung 4 zeigt die übereinstimmende Seite der Reproduzierbarkeit. Über alle Modellkonfigurationen hinweg traten 134 von 158 eindeutigen, mit der Referenz übereinstimmenden Befunden in allen fünf Wiederholungen auf (84,8 %). Wenn ein Modell also einen bekannten Snyk-Code-Referenzbefund erkannte, tat es dies meist zuverlässig. Der Kontrast zu Abbildung 5 ist das wichtigste Ergebnis: Richtig positive Befunde waren in der Regel stabil, zusätzliche Meldungen außerhalb der Referenz dagegen deutlich stärker verrauscht.

Abbildung 5: Verteilung eindeutiger, nicht übereinstimmender Modellbefunde danach, wie oft dieselbe Befundsignatur in fünf Wiederholungen derselben Aufgabe und Modellkonfiguration auftrat. Signatur = Aufgabe + Konfiguration + Schwachstellentyp + Datei + Zeile.

Fast die Hälfte der eindeutigen, nicht übereinstimmenden Modellbefunde trat nur in einer von fünf identischen Wiederholungen auf. Das ist ein praktisches Zuverlässigkeitsproblem: Je nach ausgeführtem Durchlauf könnte ein Entwickler eine wesentlich andere Warteschlange für die Prüfung erhalten.

Die genauen Werte hinter der Grafik sind:

Ergebnis 2: LLM-Agenten und SAST deckten unterschiedliche Sicherheitslücken auf

Die sinnvollste Interpretation lautet nicht „LLM oder SAST“, sondern: „LLM plus SAST erkennt unterschiedliche Fehlerarten“.

Am deutlichsten wird das beim Vergleich nach Schwachstellenklassen. Die folgende Heatmap zeigt den durchschnittlichen Recall im Vergleich zur Snyk-Code-Referenzmenge, aufgeschlüsselt nach Schwachstellentyp und Konfiguration. Snyk Code wird mit 100 % angezeigt, da es die Referenzmenge definiert und reproduziert. Die Modellzeilen zeigen, wo die agentische Prüfung mit der Referenzmenge übereinstimmt und wo sie zurückbleibt.

Abbildung 6: Durchschnittlicher Recall im Vergleich zur Snyk-Code-Referenzmenge nach Schwachstellentyp und Konfiguration. Snyk Code wird als deterministische Reproduktion der Referenz dargestellt; die Modellzeilen zeigen, wo die agentische Prüfung je nach Klasse übereinstimmt oder zurückbleibt.

Die Modellkonfigurationen waren bei vertrauten Exploit-Mustern mit klaren Signalen am stärksten: Command Injection, Code Injection, fest codierte Zugangsdaten, SQL Injection, SSRF, Open Redirect, Prototype Pollution und ReDoS wurden häufig zuverlässig erkannt. Schwächer waren sie bei Findings zu Ressourcenlimits, unsachgemäßer Bereinigung, Typvalidierung, unsicherer Datenübertragung, offengelegten Framework-Informationen und wiederholten Path-Traversal-Abläufen.

Dieses Muster zeigt sich in js-project-tigerteam: Jede Modellkonfiguration fand in allen 25 Modellwiederholungen zuverlässig das fest codierte Datenbankpasswort, reflektiertes XSS, Path Traversal und Command Injection.

1app.get("/greet", (req, res) => {
2  const name = req.query.name;
3  res.send(`<html><body><h1>Hello, ${name}!</h1></body></html>`);
4});
5
6app.get("/file", (req, res) => {
7  const filename = req.query.filename;
8  const basePath = "/var/app/public/";
9  fs.readFile(basePath + filename, "utf8", (err, data) => {
10    if (err) return res.status(404).send("Not found");
11    res.send(data);
12  });
13});
14
15app.get("/ping", (req, res) => {
16  const host = req.query.host;
17  exec("ping -c 1 " + host, (err, stdout, stderr) => {
18    if (err) return res.status(500).send("Error");
19    res.send(`<pre>${stdout}</pre>`);
20  });
21});

Das Fixture enthielt jedoch auch einen SQL-artigen Mock-Helper:

1function dbQuery(sql) {
2  console.log("Query:", sql);
3  return [];
4}
5
6app.get("/users", (req, res) => {
7  const username = req.query.username;
8  const sql = "SELECT * FROM users WHERE username = '" + username + "'";
9  const results = dbQuery(sql);
10  res.json(results);
11});

Die Modelle meldeten in 25 von 25 Modellläufen mit js-project-tigerteam SQL Injection. In diesem Fixture lag Snyk Code richtigerweise kein Finding vor: dbQuery() protokolliert den String und gibt ein leeres Array zurück. Es gibt kein ausführbares SQL-Sink. Hier kann ein LLM Code, der wie eine Schwachstelle aussieht, mit einer ausnutzbaren Schwachstelle verwechseln.

js-project-nightowl zeigte die umgekehrte Lektion. Alle 25 Modellläufe meldeten SQL Injection außerhalb des Snyk-Code-Referenzdatensatzes – und diesmal ist das Modellsignal wahrscheinlich wertvoll:

1deleteTodo: (id) => db.prepare("DELETE FROM todos WHERE id = " + id).all(),

Dieses Finding wurde als nicht zugeordnet gezählt, da es nicht im Snyk-Code-Referenzdatensatz enthalten war. Es sollte nicht als Halluzination abgetan werden. Wahrscheinlich handelt es sich um eine echte Produktlücke, die untersucht werden sollte. Der Benchmark ist stärker, nicht schwächer, weil er diesen Fall aufgedeckt hat. Wir nutzen diese Erkenntnisse intern, um die Erkennungsfunktionen von Snyk zu verbessern.

Abbildung 7: Durchschnittliche Zahl nicht zugeordneter Meldungen pro Modelllauf, nach Schwachstellentyp und Modellkonfiguration. Dazu zählen False Positives der Modelle, ergänzende Hinweise für Sicherheitsprüfungen und wahrscheinliche Kandidaten für Produktlücken außerhalb des Snyk-Code-Referenzdatensatzes.

Diese zweite Heatmap zeigt die andere Seite der Komplementarität: Zusätzliche Modellmeldungen bilden keine einheitliche Kategorie. Einige sind wahrscheinlich False Positives, etwa der nicht ausführbare SQL-artige Mock-Helper in js-project-tigerteam. Andere sind ergänzende Hinweise für Sicherheitsprüfungen, die außerhalb des Umfangs des Referenzdatensatzes liegen. Und einige – wie die SQL-Injection-Meldung in js-project-nightowl – sind wahrscheinlich valide Findings, die in die Abdeckung von Snyk Code einfließen sollten.

Die Komplementarität wirkt auch in die andere Richtung. js-project-nightowl ist das app-ähnlichste Fixture in JS 1.0: server.js umfasst 198 Zeilen, und db.js sowie public/app.js fügen weitere 183 Zeilen JavaScript hinzu. Das Fixture enthält Routing, Uploads, das Löschen von Anhängen, Downloads und Datenbankzustand. Claude Opus 4.6 High lieferte bei diesem Fixture vollkommen stabile Ergebnisse, erreichte aber nur 40,0 % Snyk-Referenz-F1. In fünf Wiederholungen übersah es jedes Path-Traversal-Referenz-Finding sowie zwei von drei möglichen Findings zu Ressourcenlimits.

Abbildung 8: Durchschnittlicher Benchmark-Score für das größere Fixture mit mehreren Dateien. Die Fehlerbalken zeigen die Standardabweichung über wiederholte Läufe hinweg.

Das übersehene Muster erstreckte sich über wiederholte Abläufe mit Anhängen:

1if (req.file) {
2  if (existing.attachment_stored_name) {
3    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
4  }
5  updates.push("attachment_original_name = ?", "attachment_stored_name = ?");
6  values.push(req.file.originalname, req.file.filename);
7} else if (req.body.removeAttachment === true || req.body.removeAttachment === "true") {
8  if (existing.attachment_stored_name) {
9    fs.unlink(path.join(UPLOADS_DIR, existing.attachment_stored_name), () => {});
10  }
11}

Das Modell fand einige repräsentative Probleme, versäumte es dann aber, wiederholte anfällige Sinks vollständig aufzuzählen. Genau hier ist eine deterministische Datenflussanalyse wertvoll. Die Abdeckung durch SAST und die Modellprüfung sind keine Duplikate; es sind unterschiedliche Instrumente mit unterschiedlichen blinden Flecken.

Ergebnis 3: Teurere LLM-Läufe bedeuteten keine bessere Abdeckung

Claude Opus 4.7 Max war in diesem Lauf die teuerste Modellkonfiguration, aber nicht die leistungsstärkste. Sie verbrauchte durchschnittlich 95.969 Tokens und kostete pro Modellsitzung 0,3559 $. Claude Opus 4.6 Medium verbrauchte durchschnittlich 51.574 Tokens und kostete pro Modellsitzung 0,0628 $. Opus 4.7 Max kostet damit 5,67-mal so viel und verbraucht 1,86-mal so viele Tokens, erzielt aber einen niedrigeren Score: 68,8 % Snyk-Referenz-F1 gegenüber 75,4 % bei Opus 4.6 Medium.

Abbildung 9: Kosten-Nutzen-Abwägung ausschließlich für Modelle. Bessere Werte liegen weiter oben links: höheres Snyk-Referenz-F1 bei niedrigeren geschätzten Kosten pro Modellsitzung.

Die absoluten Beträge sind gering, weil die Fixtures klein sind. Die Frage der Skalierung ist es nicht. Echte Sicherheitsprüfungen laufen während Coding-Agent-Sitzungen, bei Commits, Pull Requests und CI-Jobs in Repositories, die um Größenordnungen umfangreicher sind als diese Snippets. Eine teurere Inferenz sorgt nicht automatisch für eine bessere Sicherheitsabdeckung.

Übereinstimmung mit dem Snyk-Code-Referenzdatensatz

Snyk-Referenz-F1 ist weiterhin nützlich, sofern es genau beschrieben wird: Es misst die Übereinstimmung mit dem Snyk-Code-Referenzdatensatz. Bei dieser Metrik reproduzierte Snyk Code SAST seinen Referenzdatensatz mit 100,0 % Snyk-Referenz-F1 und einer Score-Standardabweichung von 0,0 Prozentpunkten. Die beste Modellkonfiguration war Claude Opus 4.6 Medium mit 75,4 % Snyk-Referenz-F1, 68,0 % Recall und 91,5 % Precision.

Diese Tabelle sollte nicht so verstanden werden, als hätte „Snyk bewiesen, dass Snyk zu 100 % genau ist“. Sie bedeutet: Snyk Code hat einen deterministischen Referenzdatensatz erstellt; die Modelle stimmten teilweise damit überein; und die Unterschiede zeigen Abwägungen bei Wiederholbarkeit, Kosten und Abdeckung auf, die es zu messen lohnt.

Was dieser Benchmark für LLM-Sicherheitsprüfungen bedeutet

Der Referenzdatensatz stammt von Snyk Code. Das ist transparent und reproduzierbar, wäre aber zirkulär, wenn man ihn als universelle Wahrheit behandelte. Dieser Bericht erhebt keinen solchen Anspruch. Der Benchmark misst die Übereinstimmung der Modelle mit den Findings von Snyk Code und untersucht anhand von Abweichungen Wiederholbarkeit und Komplementarität.

Der Bewertungsalgorithmus ist großzügig. Er gleicht nach Schwachstellentyp ab, nicht nach exakter Datei, Zeile, Schweregrad oder Source-to-Sink-Identität. Ein strengerer Bewertungsalgorithmus würde die Übereinstimmungswerte der Modelle wahrscheinlich senken und mehr Fehler bei doppelten Datenflussabläufen aufdecken.

Bei den Fixtures handelt es sich um kleine JavaScript- und Express-Anwendungen. Sie eignen sich für kontrollierte Messungen, decken aber keine großen Monorepos, TypeScript-Anwendungen mit zahlreichen Frameworks, Multi-Service-Architekturen oder Schwachstellen in der Geschäftslogik ab. js-project-nightowl zeigt bereits, dass eine app-ähnliche Struktur das Modellverhalten verändert.

Die Analyse der Wiederholungen verwendet normalisierte Finding-Signaturen. Für die modellbezogenen Diagramme nicht zugeordneter Findings lautet die Signatur: Aufgabe + Schwachstellentyp + Datei + Zeile. Die Gruppierung erfolgt separat für jede Modellkonfiguration. Unterschiedliche Normalisierungsentscheidungen verändern die genauen Prozentwerte. Deshalb ist die Signatur Bestandteil der Diagrammübergabe und der Hinweise zur Reproduzierbarkeit.

Als Nächstes: Umfangreichere Fixtures und kombinierte LLM+SAST-Workflows

Die nächste Version von Snyk VulnBench sollte über kleine, in sich geschlossene Snippets hinausgehen. Wir planen, weitere vollständige Anwendungsstrukturen, von LLMs stammende Schwachstellen, Geschäftslogik und BOLA-Klassen sowie eine unabhängige Ground-Truth-Quelle wie Referenzdaten im Stil von BaxBench hinzuzufügen.

Außerdem sollten wir die Benchmark-Tracks trennen. Ein Track kann weiterhin die Übereinstimmung mit Snyk Code messen, damit wir das Modellverhalten mit einer deterministischen SAST-Referenz vergleichen können. Ein anderer sollte eine unabhängige, extern überprüfbare Ground Truth verwenden, damit die Kernergebnisse nicht an die eigenen Findings von Snyk gebunden sind.

Schließlich sollten künftige Berichte kombinierte Workflows bewerten: reine Modellprüfung, reine SAST-Analyse und LLM-Prüfung mit zusätzlichem SAST-Kontext. Die Daten aus JS 1.0 weisen bereits in diese Richtung. Modelle und SAST versagen nicht auf dieselbe Weise. Deshalb sollten sie kombiniert werden.