In den vergangenen Jahren bedeutete die Auswahl eines KI-Modells häufig, nach den besten Benchmark-Ergebnissen zu suchen oder einen vertrauten Anbieter auszuwählen.
Debatten darüber, welches KI-Modell das „beste“ sei, wurden unter KI-Sicherheitsforschern in sozialen Medien üblich. Für Sicherheitsteams, die KI zur Erkennung von Schwachstellen bewerten, reichen diese Maßstäbe nicht mehr aus.
Die reine Leistungsfähigkeit des Modells ist nur ein Teil der Entscheidung. Teams müssen wissen, ob ein Modell echte Schwachstellen finden kann, ohne Analysten mit Fehlalarmen zu überlasten.
Auch die Kosten spielen eine Rolle, insbesondere wenn Sicherheitstests auf große Codebasen skaliert werden müssen.
Organisationen müssen berücksichtigen, wo sensibler Code verarbeitet wird und ob Änderungen an den Richtlinien eines Anbieters die weitere Nutzung beeinträchtigen könnten.
Die nützlichere Frage lautet daher nicht, welches Modell in einer allgemeinen Bestenliste führend ist. Entscheidend ist vielmehr, ob der gesamte Ansatz für die Organisation verlässliche Ergebnisse liefert.
Das bedeutet, das Modell gemeinsam mit dem umgebenden Workflow zu bewerten und zu ermitteln, ob das daraus resultierende System den Sicherheitsanforderungen der Organisation entspricht.
Eine niedrigere Modellrechnung bedeutet nicht automatisch niedrigere Kosten
Nehmen wir als Beispiel Schwachstellen durch unsichere direkte Objektreferenzen (IDOR). Diese Zugriffskontrollfehler ermöglichen es Benutzern, auf Ressourcen zuzugreifen oder sie zu verändern, obwohl sie dazu nicht berechtigt sein sollten. IDORs gehören oft zu den ersten Schwachstellen, deren Erkennung neue Penetrationstester lernen, doch ihre scheinbare Einfachheit kann irreführend sein.
Die Erkennung eines IDOR erfordert kontextbezogenes Schlussfolgern und nicht nur das Auffinden einer offensichtlich gefährlichen Funktion. Ein Modell muss verstehen, wer Zugriff auf eine Ressource haben sollte, und feststellen, ob die erforderliche Autorisierungsprüfung fehlt.
Semgreps Benchmark zur Erkennung von IDOR-Schwachstellen testet Modelle anhand echter Schwachstellen in Open-Source-Codebasen. Die Erkennungsleistung wird anhand von Precision und Recall gemessen, wobei der F1-Score beide Werte ausgleicht und so ein Gesamtmaß für die Qualität liefert. Semgrep erfasst außerdem die Kosten jeder bestätigten Schwachstelle.
In einem kürzlich durchgeführten Lauf erreichte das in China ansässige GLM-5.3 von Z.ai einen F1-Score von 23,8 % bei Kosten von 0,15 US-Dollar pro richtig positivem Treffer. Claude Opus 4.8 erzielte mit 23,6 % einen nahezu identischen F1-Score, doch jeder richtig positive Treffer kostete 1,04 US-Dollar. In diesem speziellen Test lieferten die Modelle somit eine ähnliche Gesamterkennungsqualität zu deutlich unterschiedlichen Kosten.
Dieser Unterschied kann erheblich werden, wenn Anwendungssicherheitsteams große Codebasen prüfen oder häufig neue Änderungen testen. Der Preis allein macht GLM-5.3 jedoch nicht zur besseren Wahl. Sein Recall lag im selben Test bei gerade einmal 13,9 %, das heißt, das Modell erkannte die meisten bekannten IDORs im Datensatz nicht.
GLM-5.3 schnitt außerdem schlechter ab als sein Vorgänger GLM-5.2. Die Semgrep-Forscher weisen darauf hin, dass weitere Durchläufe erforderlich waren, um festzustellen, ob dieser Unterschied eine tatsächliche Regression oder eine normale Testschwankung darstellte.
Letztlich ist die Zahl der Kosten pro richtig positivem Treffer nur im Kontext der von einer Organisation benötigten Erkennungsleistung relevant. Niedrigere Inferenzkosten bringen wenig, wenn zu viele Schwachstellen unentdeckt bleiben oder Analysten erheblich mehr Zeit aufwenden müssen, um die Einschränkungen des Modells auszugleichen.
Die Gesamtkosten umfassen die menschliche Prüfung
Fehlalarme verdeutlichen ein weiteres Problem. Zwei Modelle können ähnliche Gesamtwerte erzielen und dabei für die Ingenieure, die für die Validierung ihrer Ergebnisse zuständig sind, völlig unterschiedliche Arbeitslasten erzeugen.
Ein separates Semgrep-Benchmarking von Kimi K3 zeigte diesen Zielkonflikt. Bei Verwendung derselben Konfiguration mit geführten Prompts erreichte Kimi einen F1-Score von 34,0 %, nahe an GLM-5.2 mit 34,5 % und Claude Opus 4.8 mit 34,3 %. Kimi erzielte jedoch eine Precision von 68,4 %, verglichen mit 86,3 % bei GLM-5.2 und 91,0 % bei Claude Opus 4.8. Daher mussten Ingenieure einen größeren Anteil der Ergebnisse als Fehlalarme untersuchen und verwerfen.
Die Ergebnisse auf Repository-Ebene warfen ein weiteres Problem auf. Kimi erzielte im größten Repository im Unternehmensstil des Benchmarks im Durchschnitt einen F1-Score von etwa 6 %, während GLM und die Spitzenmodelle im Durchschnitt bei rund 20 % lagen. Ein einzelnes Repository kann nicht belegen, dass die Größe der Codebasis den Rückgang verursacht hat. Das Ergebnis zeigt jedoch, warum Teams Modelle an Umgebungen testen sollten, die ihren eigenen ähneln, statt sich ausschließlich auf Gesamtwerte zu verlassen.
Die tatsächlichen Kosten von KI-gestützter Sicherheit gehen ebenfalls über die Nutzung des Modells hinaus. Organisationen müssen die für den Betrieb des Systems erforderliche Infrastruktur und den dafür nötigen technischen Aufwand berücksichtigen.
Übersehene Schwachstellen verursachen weitere potenzielle Kosten, die auf der Preisseite eines Anbieters nicht auftauchen. Zusammengenommen bestimmen diese Faktoren, ob ein System in der Praxis tragfähig ist.
Das Modell selbst ist nur eine Komponente. Das umgebende Harness kann die Sicherheitsleistung wesentlich beeinflussen, indem es bestimmt, wie das Modell Informationen erhält und seine Analyse durchführt.
Im selben Benchmark-Datensatz stieg der Recall von GPT-5.6 Sol von 25 % mit einem geführten Prompt auf 73 % im multimodalen Harness von Semgrep. Das zugrunde liegende Modell blieb gleich, doch das es umgebende System führte zu einem erheblich anderen Ergebnis.
Für Sicherheitsverantwortliche verändert dieser Unterschied den Bewertungsprozess. Zu wissen, welches Modell ein Produkt verwendet, ist weniger aussagekräftig als zu verstehen, wie das Gesamtsystem anhand repräsentativer Codebasen abschneidet und wie viel Arbeit seine Ergebnisse für Sicherheitsteams erzeugen.
Geografie verändert die Rechnung
Hier gibt es noch eine weitere Besonderheit. Einige überzeugende Alternativen kommen nicht ausschließlich von US-amerikanischen Spitzenlaboren.
GLM-5.2 ist beispielsweise Open Weight, sodass Organisationen es herunterladen und auf ihrer eigenen Infrastruktur betreiben können. In Tests von Semgrep übertraf es Claude in einem IDOR-Benchmark und kostete dabei ungefähr 0,17 US-Dollar pro gefundener Schwachstelle.
Für Organisationen, die mit sensibler geistiger Eigentum umgehen oder strengen Datenanforderungen unterliegen, kann der Ort der Codeverarbeitung ebenso wichtig sein wie die Benchmark-Leistung. Ein Open-Weight-Modell, das innerhalb der eigenen Umgebung einer Organisation ausgeführt wird, bietet eine andere Perspektive auf Sicherheit und Governance als ein geschlossenes Modell, auf das über einen externen Anbieter zugegriffen wird.
Auch die Widerstandsfähigkeit ist wichtig. Anbieter können die Verfügbarkeit oder die Preise eines Modells ändern, ohne dass Kunden darauf großen Einfluss haben. Auch die Richtlinien für den Zugriff können sich im Laufe der Zeit verändern. Einen kritischen Sicherheits-Workflow um einen einzigen Anbieter herum aufzubauen bedeutet, diese externe Abhängigkeit zu akzeptieren.
Das bedeutet nicht, dass ausländische oder Open-Weight-Modelle einen Freibrief verdienen. Organisationen müssen weiterhin bewerten, woher ein Modell stammt und ob sein Verhalten für Sicherheitsaufgaben zuverlässig genug ist. Außerdem müssen sie feststellen, ob der Bereitstellungsansatz ihre Sicherheitsanforderungen erfüllt. Das Herkunftsland ist kein sinnvoller Ersatzmaßstab für die Leistungsfähigkeit, genauso wenig wie eine bekannte US-Marke garantiert, dass ein Modell die richtige Wahl ist.
Die zunehmende Qualität von Modellen wie GLM und Kimi verschafft Sicherheitsteams etwas Wertvolles: Verhandlungsspielraum und Auswahlmöglichkeiten.
Die Aufgabe benchmarken, nicht die Marke
Es wird wahrscheinlich nicht das eine beste KI-Modell für jedes Anwendungssicherheitsprogramm geben.
Ein Team, das eine möglichst umfassende Erkennung von Schwachstellen priorisiert, wird dem Recall möglicherweise mehr Gewicht geben. Ein anderes, das mit einer hohen Zahl von Warnungen kämpft, bevorzugt vielleicht die Precision.
Eine Organisation mit strengen Anforderungen an die Datenresidenz priorisiert möglicherweise das Hosting auf eigener Infrastruktur, während ein Team, das große Mengen an Code prüft, stärker auf die Kosten pro bestätigtem Fund achten wird.
Eine aussagekräftige Bewertung beginnt mit repräsentativen Codebasen, einschließlich der größten Repositories, die ein Team voraussichtlich mit dem System verarbeiten wird. Teams sollten Precision und Recall messen und zugleich untersuchen, welche Schwachstellen unentdeckt bleiben. Bei den Kostenberechnungen sollten sowohl die für den Betrieb des Systems erforderlichen Ressourcen als auch der Aufwand für die Prüfung seiner Ergebnisse berücksichtigt werden.
Die Tests sollten außerdem die tatsächliche Umgebung rund um das Modell widerspiegeln, statt das Modell isoliert zu bewerten. Diese Bewertungen müssen wiederholt werden, wenn sich die Technologie und die Angebote der Anbieter verändern.
Für Verantwortliche im Bereich Anwendungssicherheit sollte die Modellauswahl weniger einer Entscheidung anhand einer Bestenliste und mehr einer technischen Bewertung gleichen.
Das bekannteste Modell kann weiterhin die richtige Wahl sein, sollte aber deshalb gewinnen, weil es unter den Rahmenbedingungen der Organisation das beste Sicherheitsergebnis liefert – nicht, weil sein Name ganz oben in dem Benchmark eines anderen steht.
KI-Modelle sind nur eine Möglichkeit, Sicherheitsschwachstellen in Code und Infrastruktur zu finden. Sehen Sie sich unseren Leitfaden zu den besten Tools zum Scannen auf Schwachstellen an, um weitere Ansätze zur Erkennung von Schwachstellen zu vergleichen.