TL;DR
- GPT-5.6 erzielt mit 23 von 26 den höchsten Recall-Wert und liegt damit vor grok-4.5 (20), den Claude-Opus-Modellen (15 bis 18) und allen anderen von uns getesteten Modellen. Das bedeutet, dass es 88,5 % der CVEs wiederentdecken kann.
- Die teuerste Option ist nicht erforderlich. Die günstigeren Varianten von GPT-5 .6 liegen bei nur einem oder zwei Ergebnissen hinter dem Flaggschiff-Modell zurück, kosten aber nur einen Bruchteil davon, und die Zusammenfassung mehrerer Durchläufe eines Modells der mittleren Preisklasse kommt einem einzelnen Durchlauf des Flaggschiff-Modells gleich.
- Die Modellläufe sind uneinheitlich, aber durch die Zusammenführung der Ergebnisse erzielen sie ein besseres Ergebnis. Jeder einzelne Lauf übersieht Fehler, die bei einem anderen Lauf entdeckt würden; wenn man ein Modell mehrmals ausführt und die Ergebnisse zusammenfasst (pass@3), ist das Ergebnis zuverlässig besser als ein einziger Durchlauf eines leistungsstärkeren, teureren Modells.
- „Open Weight“ holt schnell auf. GLM-5 .2 erkennt bereits 59 % des Datensatzes (16/26) wieder und liegt damit im Mittelfeld der proprietären Modelle.
Jede Einführung eines neuen Frontier-Modells geht mittlerweile mit dem gleichen Versprechen in Sachen Cybersicherheit einher: Es findet Schwachstellen. Aber funktioniert es auch bei einem echten Fehler in einem echten Repository oder nur bei einem sorgfältig ausgewählten Beispiel? Welches der Dutzenden Modelle, aus denen man wählen könnte, ist es wert, ihm die Code-Prüfung anzuvertrauen? Und da die leistungsstärksten Modelle pro Durchlauf zehnmal so viel oder mehr kosten als die günstigsten – was bringt einem dieser Mehraufwand tatsächlich an gefundenen Fehlern?
Es ist einfach, Modelle nach ihrer reinen Leistungsfähigkeit zu bewerten und das teuerste Modell zum Sieger zu erklären, doch die wichtigere Frage ist, ob der Preis gerechtfertigt ist. Deshalb haben wir 13 der Modelle, zwischen denen Teams heute wählen, anhand von 26 bekannten Schwachstellen aus der GitHub-Advisory-Datenbank getestet. Diese decken eine Vielzahl von Sprachen und Projekttypen ab. Wir haben zwei Dinge gemessen: wie viele Fehler jedes Modell gefunden hat und wie viel es gekostet hat, diese zu finden.

So funktioniert der Benchmark
Wir haben 26 Schwachstellen aus der GitHub-Advisory-Datenbank ausgewählt – eine zufällige Auswahl aus verschiedenen Sprachen und Projekttypen, von SQL-Injection in einem Web-Framework bis hin zu einer Deserialisierungs-RCE in einem ML-Toolkit – und jedes Modell gebeten, diese nacheinander, Repository für Repository, innerhalb derselben KI-Codeanalyse -Harness, den wir in der Produktion einsetzen. Anstelle eines Chatfensters handelt es sich um ein Modell mit echten Werkzeugen, das das Repository durchsucht und den Code auf die gleiche Weise analysiert wie ein Prüfer.
Der „Harness“ ist das, was ein Sprachmodell zu einem Prüfer macht. Ein universeller Programmierassistent ist für eine andere Aufgabe konzipiert, nämlich eine Aufgabe zu übernehmen und funktionierenden Code zu erzeugen. Wenn man ihn auf ein Repository verweist und fragt, ob es sicher ist, verhält er sich wie ein Entwickler, der nach offensichtlichen Fehlern sucht und aufhört, sobald er etwas Plausibles gefunden hat. KI-Codeanalyse ist anders aufgebaut. Es durchforstet die Codebasis nach möglichen Einstiegspunkten, untersucht jeden verdächtigen Ablauf eingehend und sortiert die Ergebnisse anschließend so, dass nur echte Schwachstellen übrig bleiben.
Da wir wussten, wo sich die einzelnen Schwachstellen befanden, haben wir jeden Ermittlungsagenten direkt auf den anfälligen Codeausschnitt gelenkt. Auf diese Weise spiegelt ein Fehlschlag eher die Argumentation wider als verschwendete Mittel, die durch das Durchsuchen falscher Bereiche der Codebasis verloren gehen. Das Modell muss dennoch den Ablauf verstehen, die Ausnutzbarkeit beurteilen und dies korrekt melden. Die Eingabeaufforderungen wurden kurz und modellunabhängig gehalten, sodass kein Anbieter durch die Formulierung begünstigt wird.
Wir haben jedes Modell dreimal ausgeführt und die Ergebnisse zusammengefasst. Ein CVE gilt als „gefunden“, wenn das Modell es bei einem der Durchläufe identifiziert (pass@3).
Wir haben eine Auswahl der neuesten Modelle verschiedener Anbieter getroffen:
- OpenAI: gpt-5.4-nano, gpt-5.4-mini, gpt-5.5 und die gpt-5.6-Reihe (luna / terra / sol)
- Anthropic: claude-haiku-4-5, claude-opus-4-7, claude-opus-4-8
- xAI: grok-4.5
- Google: gemini-3.1-pro, gemini-3.5-flash
- Leergewicht: glm-5.2
Ergebnisse nach Schweregrad und Anfälligkeit
Bei jedem Modell wurden beide kritischen CVEs (ein RCE durch Deserialisierung und ein gespeichertes XSS) erneut entdeckt. Der eigentliche Unterschied zeigt sich bei den Befunden mit hohem und mittlerem Schweregrad.

Die schwierigsten und einfachsten CVEs
Die beiden kritischen Fehler und mehrere offensichtliche Injektions- bzw. Zugriffskontrollschwachstellen wurden von jedem Modell entdeckt. Eine Handvoll spezifischer Ketten überwand fast alle davon.
Die CVEs, die jedes Modell findet, folgen demselben Muster: Von Angreifern kontrollierte Eingaben führen über einen kurzen, lokalen Ablauf zu einer bekannten gefährlichen Operation, wie beispielsweise einem Deserialisierungsaufruf, einem Shell-Ausführungsbefehl, einem HTML-Sink oder einer fehlerhaften Signaturprüfung. Hierbei handelt es sich um Mustererkennung, die effektiv gelöst wurde. Sowohl kostengünstige Modelle als auch Flaggschiff-Modelle erzielen hier 13 von 13 Punkten, ohne dass dabei eine Trennung der Fähigkeiten vorgenommen wird.
Die eigentliche Herausforderung – und der Punkt, an dem sich die Leistungsfähigkeit der Modelle tatsächlich unterscheidet – besteht darin, Schlussfolgerungen über nicht vorhandene Prüfmechanismen zu ziehen und komplexe Ketten nachzuvollziehen, die sich nicht aus einer einzelnen Zeile ableiten lassen. Das deutlichste Beispiel hierfür ist „SQL Injection-1“ in unserem Datensatz, eine indirekte Injektion über einen Spaltenalias, den das ORM niemals maskiert. Nur GPT-5.5 und die leistungsstärksten GPT-5.6-Modelle (sol und terra) haben dies aufgedeckt.
Was uns der Unterschied zwischen „Durchschnitt“ und „Vereinigung“ verrät
Die aussagekräftigste Kennzahl in diesem Benchmark ist der Abstand zwischen dem Durchschnittswert eines Modells und der Vereinigung seiner Durchläufe. Da bei jedem Durchlauf eine andere Teilmenge der Fehler aufgedeckt wird, lässt sich durch deren Zusammenfassung (Durchlauf 3) eine überraschend große Anzahl davon aufspüren:

Betrachten wir gpt-5.4-nano: Kein einzelner Durchlauf überschreitet 14, doch drei zusammengefasste Durchläufe erreichen 18 – ein Sprung um vier CVE –, da bei jedem Durchlauf unterschiedliche Fehler zutage treten. claude-haiku-4-5 ist das krasseste Beispiel für diese Schwankungen: Bei ein und demselben Modell und derselben Aufgabe wurden in einem Durchlauf 7 und in einem anderen 13 Punkte erzielt.
Die Erkenntnis daraus ist, dass man nicht gleich zum teuersten Modell greifen muss. Drei Durchläufe mit gpt-5.4-nano kosten etwa 170 US-Dollar und erreichen 18/26 – genauso viel wie ein einzelner Durchlauf eines Flaggschiffmodells wie gpt-5.6-terra im Durchschnitt erzielt, und das zu einem Bruchteil des Preises. Drei Durchläufe mit dem GPT-5.4-Mini (etwa 460 $) erreichen einen Wert von 20. Die wiederholte Nutzung eines soliden Modells der Mittelklasse übertrifft einen einzelnen Durchlauf eines Flaggschiff-Modells weitaus häufiger, als der Preisunterschied vermuten lässt.
Lohnt sich höheres Denken?
Wir haben die entsprechenden Modelle auf zwei Schlussfolgerungsebenen ausgeführt: der Standardeinstellung „high“ und der jeweils höchsten verfügbaren Stufe („xhigh“ für die Modelle GPT-5.4/5.5 und Claude, „max“ für GPT-5.6, grok-4.5 und glm-5.2). Alle Zahlen beziehen sich auf „pass@3-Unions“ und sind somit direkt vergleichbar.

Deutliche Gewinner sind gpt-5.5 (+3 bei 1,5-fachen Kosten) und glm-5.2 (+3 bei 1,3-fachen Kosten). claude-opus-4-8 erzielt +2, kostet dafür aber das Doppelte. In allen anderen Fällen bringt die Spitzenklasse einen oder gar keinen Treffer, und bei GPT-5.6-Luna und GPT-5.4-Nano lag das Ergebnis einen Treffer niedriger, was jedoch im Rahmen der Schwankungen zwischen den einzelnen Durchläufen liegt. GPT-5.6-Terra ist das deutlichste Beispiel für abnehmende Erträge: 2,2-fache Kosten bei denselben 23 Treffern.
Die Gemini-Modelle verfügen über keine Einstellung oberhalb von „hoch“, weshalb sie in diesem Vergleich nicht berücksichtigt werden.
Fazit
Richtet man ein Frontier-Modell auf einen Code-Bestand innerhalb eines speziell für diesen Zweck entwickelten Testumfelds, deckt es die meisten bekannten Schwachstellen wieder auf. Fehler mit einer offensichtlich gefährlichen Auswirkung werden behoben. Diejenigen, die die Modelle weiterhin voneinander trennen, haben keine Auswirkung, auf die man verweisen könnte. Eine fehlende Autorisierungsprüfung oder eine Injektion, die man nur über eine lange, undurchsichtige Kette durch mehrere Dateien erreichen kann.
Die teuerste Stufe rechtfertigt ihren Preis nur selten. Wenn man ein günstigeres Modell ein paar Mal ausführt und die Ergebnisse zusammenfasst, erhält man mehr für weniger Geld als bei einem einzigen Durchlauf eines Flaggschiff-Modells – und dieser Vorteil wird immer größer, je günstiger und leistungsfähiger die Modelle werden. Der Harness entscheidet jedoch nach wie vor darüber, ob diese Herangehensweise überhaupt auf den richtigen Teil der Codebasis ausgerichtet wird.

