AWS AI-Schwachstellenerkennung findet Bugs, doch False Positives offenbaren eine Vertrauenslücke
AWS testete 12 KI-Modelle für allgemeine Zwecke und stellte einen deutlichen Konflikt fest: Sie erkannten die meisten Schwachstellen, stuften jedoch häufig sicheren Code als gefährlich ein.
Der neue Deception Benchmark unterzieht Behauptungen zur AWS AI-Schwachstellenerkennung einem härteren Test als eine weitere Rangliste zur Bug-Erkennung. Er fragt, ob ein Modell erkennen kann, wann verdächtiger Code tatsächlich durch eine funktionierende Gegenmaßnahme abgesichert ist. Bei direkter Aufforderung markierten die getesteten Modelle zwischen 41 % und 99 % der sicheren Beispiele als anfällig.
Dieses Ergebnis verschiebt die Debatte um KI-Sicherheitstools. Verdächtige Muster zu finden, genügt nicht, wenn jede Warnung Engineering-Zeit verbraucht. Der eigentliche Wettbewerb findet nun zwischen schneller Mustererkennung und evidenzbasierter Überprüfung statt – und Sicherheitsteams zahlen die Differenz.
AWS veröffentlichte den Benchmark am 9. September 2026 mit 14.822 Beispielen in 16 Programmiersprachen und mehr als 70 Kategorien der Common Weakness Enumeration. Keine getestete Konfiguration erfüllte die von AWS genannte Mindestanforderung, sowohl die False-Positive- als auch die False-Negative-Rate unter 10 % zu halten.
AWS entwickelte einen Benchmark, bei dem sicherer Code gefährlich aussieht
Der Benchmark prüft, ob ein Modell die Ausnutzbarkeit versteht – nicht, ob es ein bekanntes Schwachstellenmuster erkennt.
Viele Sicherheitsbewertungen beginnen mit anfälliger Software und fragen ein KI-System, ob es den Fehler identifizieren oder ausnutzen kann. Dieser Ansatz zeigt nützliche offensive Fähigkeiten, vermittelt jedoch nur ein unvollständiges Bild der defensiven Leistung. Ein Prüfsystem im Produktiveinsatz muss auch Code verwerfen können, der einer Schwachstelle ähnelt, ohne einen tatsächlichen Angriffspfad zu schaffen.
AWS entwickelte den Deception Benchmark rund um diese Unterscheidung. Seine sicheren Beispiele enthalten realistische Frameworks, gefährlich wirkende Datenflüsse und erkennbare Sicherheitswarnzeichen. Eine subtile Gegenmaßnahme schließt den Angriffspfad, sodass das Modell entscheiden muss, ob der Schutz tatsächlich funktioniert.
Ein im Benchmark-Release beschriebenes Beispiel betrifft einen Flask-Endpunkt, der Nutzereingaben akzeptiert und eine Datenbank abfragt. Das umgebende Muster ähnelt einer SQL-Injection. Parametrisierte Statements verhindern jedoch, dass die Eingabe zu ausführbarer Abfragesyntax wird.
Ein Modell, das nach dem Erkennen des Musters stoppt, wird eine Schwachstelle melden. Ein Modell, das den gesamten Datenfluss nachverfolgt, sollte das Beispiel als sicher einstufen. Dieser Unterschied entscheidet darüber, ob die Ausgabe zu nützlicher Evidenz oder zu einer weiteren Warnung wird, die manuell untersucht werden muss.
Der Benchmark umfasst 6.988 Herausforderungen auf Codeebene. Sie enthalten anfällige und sichere Varianten, die sich durch eine subtile Korrektur unterscheiden. Beide Versionen können verdächtig aussehen, doch nur eine bleibt ausnutzbar.
Weitere 2.707 Herausforderungen ergänzen Deployment-Kontext. Der Quellcode kann anfällig wirken, während eine Infrastrukturkontrolle den Angriff blockiert. Beispiele sind eine Kubernetes Network Policy, die Server-Side Request Forgery stoppt, oder eine Identitätsgrenze, die Privilege Escalation verhindert.
Diese umgebungsabhängigen Fälle sind wichtig, weil Enterprise-Sicherheit selten bei einer Datei endet. Die Ausnutzbarkeit hängt von Konfiguration, Netzwerkerreichbarkeit, Berechtigungen, Laufzeitverhalten und kompensierenden Kontrollen ab. Ein Scanner, der diese Bedingungen ignoriert, kann einen plausiblen Angriff beschreiben, der in der bereitgestellten Umgebung nicht möglich ist.
AWS zufolge wurde jedes Beispiel für den Benchmark erstellt und basiert auf realen Sicherheitsmustern. Das Unternehmen nutzte einen adversarialen Entwicklungszyklus, der Herausforderungen generierte, sie gegen Frontier-Modelle testete, zu einfache Fälle härter machte und den Prozess wiederholte.
Diese Methode macht den Datensatz absichtlich schwierig. Sie bedeutet auch, dass die Ergebnisse nicht als repräsentative Fehlerrate für jedes Quellcode-Repository behandelt werden sollten. Der Benchmark wählt Fälle aus, die oberflächliches Schlussfolgern offenlegen sollen, und keine Zufallsstichprobe alltäglicher Code-Reviews.
Sein Wert liegt darin, eine spezifische Fähigkeit zu isolieren. Kann ein Modell eine Angriffskette weit genug verfolgen, um eine tatsächliche Schwäche von einem überzeugenden Köder zu unterscheiden? Diese Frage steht im Zentrum einer vertrauenswürdigen AWS AI-Schwachstellenerkennung.
Das öffentliche Benchmark-Repository enthält alle 14.822 Beispiele. AWS bewertet 9.695 davon und lässt 5.127 unbewertet. Diese zurückgehaltenen Beispiele umfassen strittige oder bewusst mehrdeutige Fälle.
Labels werden nicht öffentlich bereitgestellt. Teilnehmende müssen für jedes Beispiel Vorhersagen einschließlich Begründungen einreichen, bevor AWS Ergebnisse zu Genauigkeit und Fehlerraten zurückliefert. Dieser Ansatz soll Memorization und benchmark-spezifisches Tuning begrenzen.
AWS erklärt zudem, dass unabhängige Prüfer die Labels wiederholt untersucht hätten. Strittige Beispiele wanderten in den unbewerteten Pool, statt korrigierte Labels zu erhalten. Laut dem Unternehmen ergab eine menschliche Prüfung von 100 zufällig ausgewählten bewerteten Beispielen keine Fehler.
Das macht den Datensatz nicht immun gegen Kritik. Unabhängige Forschende müssen weiterhin seine Konstruktion, Kategorienbalance, den Bewertungsprozess und die Übertragbarkeit auf die Praxis untersuchen. Die Veröffentlichung gibt externen Teams jedoch ein gemeinsames Ziel, um Systeme unter denselben adversarialen Bedingungen zu vergleichen.
Die Ergebnisse der AWS AI-Schwachstellenerkennung offenbaren zwei schlechte Optionen
Direkte Prompts erzeugen zu viele Fehlalarme, während strengere Beweisanforderungen dazu führen, dass Modelle mehr echte Schwachstellen übersehen.
AWS bewertete 12 Modelle von fünf Anbietern mit zwei Prompting-Strategien. Direkte Prompts forderten jedes Modell auf, Code als anfällig oder sicher einzustufen. Proof-of-Exploit-Prompting verlangte, vor der Erklärung einer Schwachstelle einen konkreten Exploit zu konstruieren.
Der Benchmark trennt zwei Fehlerarten, weil sie unterschiedliche operative Probleme verursachen. Ein False Positive stuft sicheren Code als anfällig ein. Ein False Negative klassifiziert eine echte Schwachstelle als sicher.
Bei direkter Aufforderung bevorzugten die Modelle in der Regel Sensitivität. Laut AWS erkannten sie bis zu 95 % der echten Schwachstellen. Gleichzeitig markierten sie jedoch 41 % bis 99 % des sicheren Codes als anfällig.
Diese Verzerrung kann ein Modell aktiv und vorsichtig erscheinen lassen. Sie ist außerdem ein einfacher Weg, den Recall zu schützen, der den Anteil gefundener echter Schwachstellen misst. Ein System, das alles als anfällig bezeichnet, wird niemals eine Schwachstelle übersehen, begräbt Nutzende jedoch unter nutzlosen Warnungen.
Mistral Large veranschaulicht diesen Fehlermodus. Seine Konfiguration mit direktem Prompting verzeichnete eine False-Positive-Rate von 99 % und eine False-Negative-Rate von 0 %. Es fand die anfälligen Fälle, indem es praktisch jeden sicheren Fall als gefährlich behandelte.
Mehrere andere direkte Konfigurationen verhielten sich ähnlich. GPT-5.6 Sol verzeichnete eine False-Positive-Rate von 92,5 % und eine False-Negative-Rate von 0,9 %. Claude Haiku 4.5 erreichte eine False-Positive-Rate von 92,1 %, ohne False Negatives zu verzeichnen.
Auch Amazons eigenes Nova 2 Lite war nicht ausgenommen. Bei direktem Prompting meldete AWS eine False-Positive-Rate von 89,2 % und eine False-Negative-Rate von 1,2 %. Die Einbeziehung des Amazon-Modells macht die Veröffentlichung zu mehr als einem Vergleich, der auf externe Anbieter zielt.
Claude Opus 5 erzielte unter den aufgeführten Systemen bei direktem Prompting die beste Balance. Es erreichte 77,3 % Genauigkeit bei einer False-Positive-Rate von 41,5 % und einer False-Negative-Rate von 5,2 %. Selbst dieses Ergebnis lag noch weit über der von AWS genannten Schwelle für den Produktiveinsatz.
Die Genauigkeit allein verschleiert diese Unterschiede. Der Benchmark ist ungefähr zwischen sicheren und anfälligen Fällen ausgeglichen, sodass ein Klassifikator, der immer „anfällig“ antwortet, nahe an 50 % erzielen kann. Seine scheinbare Genauigkeit verbirgt, dass jedes sichere Beispiel zu einer Warnung wird.
AWS legte deshalb eine, wie das Unternehmen es nannte, großzügige Mindesthürde fest. Eine produktionsreife Konfiguration sollte beide Fehlerraten unter 10 % halten. Keine der getesteten Konfigurationen erreichte dieses Ziel.
Die direkten Ergebnisse zeigen, warum KI-Schwachstellenerkennung nicht allein anhand des Recall bewertet werden kann. Nahezu jeden echten Fehler zu finden klingt beruhigend – bis ein Team erfährt, dass auch der Großteil des sicheren Codes Warnungen ausgelöst hat.
Dies ist kein kosmetisches Qualitätsproblem. Jede falsche Warnung gelangt in einen Workflow. Jemand muss den Code untersuchen, den behaupteten Pfad reproduzieren, die Konfiguration prüfen, das zuständige Team konsultieren und dokumentieren, warum der Befund geschlossen werden kann.
Im Enterprise-Maßstab können diese Prüfungskosten den durch Automatisierung versprochenen Geschwindigkeitsvorteil aufzehren. Sie können zudem zu Alert Fatigue führen, bei der Engineers Befunde zunehmend verwerfen, weil zu viele frühere Warnungen falsch waren.
Die Sicherheitsfolge ist unangenehm. Eine hohe False-Positive-Rate kann das Risiko indirekt erhöhen, selbst wenn das Modell einen ausgezeichneten Recall besitzt. Die wichtige Warnung konkurriert mit Dutzenden überzeugender Fehler um Aufmerksamkeit.
Frühere akademische Arbeiten identifizierten dasselbe Muster. Eine Sicherheitsbewertung aus dem Jahr 2024 testete acht Sprachmodelle in 228 Code-Szenarien und berichtete hohe False-Positive-Raten. Modelle markierten teils weiterhin Schwachstellen, nachdem der getestete Code gepatcht worden war.
Die Studie stellte außerdem nicht-deterministische Antworten und fragiles Schlussfolgern bei einfachen Codeänderungen fest. Die umfangreichere AWS-Veröffentlichung erweitert die Bedenken auf mehr Sprachen, Schwachstellenkategorien, Modelle und adversarial konstruierte sichere Beispiele.
Proof of Exploit reduziert Rauschen, schafft jedoch einen neuen blinden Fleck
Die Forderung nach Evidenz verbessert die Disziplin, doch die getesteten Modelle erkauften diese Präzision häufig durch das Übersehen echter Schwachstellen.
Proof-of-Exploit-Prompting fordert ein Modell auf, über bloßen Verdacht hinauszugehen. Bevor es Code als anfällig einstuft, muss es einen konkreten Pfad beschreiben, den ein Angreifer nutzen könnte. Damit verschiebt sich die Entscheidungsschwelle von „Das sieht gefährlich aus“ zu „Ich kann erklären, wie der Angriff funktioniert“.
AWS berichtete, dass diese Strategie die False-Positive-Raten um 17 bis 74 Prozentpunkte senkte. Das ist eine bedeutende Verbesserung. Sie erhöhte jedoch auch die False-Negative-Raten, die unter dem strengeren Ansatz zwischen 7 % und 44 % lagen.
GPT-5.4 liefert das deutlichste Beispiel für diesen Zielkonflikt. Seine direkte Konfiguration erzeugte eine False-Positive-Rate von 81 % und eine False-Negative-Rate von 1,5 %. Proof-of-Exploit-Prompting senkte die False Positives auf 10,1 %, doch die False Negatives stiegen auf 33,6 %.
Llama 3.3 70B folgte einem ähnlichen Muster. Seine False-Positive-Rate sank von 84,2 % auf 10,2 %. Seine False-Negative-Rate stieg von 1,1 % auf 44,2 %, sodass die Konfiguration nahezu die Hälfte der bewerteten Schwachstellen übersah.
Claude Opus 5 verzeichnete unter Proof-of-Exploit-Prompting mit 79,3 % die höchste Gesamtgenauigkeit. Seine False-Positive-Rate von 24,9 % und seine False-Negative-Rate von 16,8 % verfehlten die AWS-Schwelle jedoch weiterhin auf beiden Seiten.
Die Ergebnisse bedeuten nicht, dass Proof-of-Exploit-Prompting unwirksam ist. Sie zeigen, dass Prompting verändert, welche Fehler ein Modell macht. Sicherheitsverantwortliche müssen entscheiden, ob ihr Workflow mehr Fehlalarme, mehr übersehene Fehler oder eine sorgfältig gemessene Kombination verkraften kann.
Diese Entscheidung hängt von der Anwendung ab. Bei der Prüfung eines internetexponierten Authentifizierungsdienstes sollten weniger übersehene Schwachstellen toleriert werden. Ein internes Repository mit geringem Risiko könnte Präzision priorisieren, um ein kleines Engineering-Team nicht zu überlasten.
Auch der Schweregrad sollte die Schwelle beeinflussen. Ein System könnte kritische Befunde mit hoher Konfidenz zur sofortigen menschlichen Prüfung weiterleiten, während schwächere Warnungen über eine Validierung mit niedrigerer Priorität behandelt werden. Eine einzige globale Klassifikationsschwelle wird kaum für jede Codebasis geeignet sein.
Hier wird das Single-Turn-Design des Benchmarks wichtig. AWS entfernte bewusst Agenten-Scaffolding, externe Tools und wiederholte Validierungsschleifen. Ziel war es, die intrinsische Denkfähigkeit des Basismodells statt eines vollständigen kommerziellen Sicherheitsprodukts zu messen.
Die Ergebnisse belegen daher nicht, dass jeder agentische Scanner dieselben Fehlerraten aufweist. Ein Produkt könnte Sprachmodelle mit statischer Analyse, dynamischen Tests, Repository-Kontext, Richtlinienprüfungen und deterministischer Exploit-Validierung kombinieren. Diese Komponenten können den Arbeitspunkt verändern.
AWS erkennt diese Unterscheidung ausdrücklich an. Der Benchmark akzeptiert agentische Einreichungen getrennt von Single-Turn-Modellergebnissen. Diese Trennung verhindert, dass ein toolgestütztes System als gleichwertig mit einem nicht unterstützten Modellaufruf dargestellt wird.
Der Vorbehalt macht die Baseline nicht irrelevant. Jeder agentische Workflow übernimmt einige Einschränkungen seines zugrunde liegenden Modells. Die Wiederholung einer schwachen Beurteilung kann eine ausführlichere Erklärung erzeugen, ohne die fehlende technische Tatsache hinzuzufügen.
Ein System benötigt eine zuverlässige Quelle neuer Belege. Es könnte einen Test ausführen, Daten über Dateien hinweg verfolgen, eine Bereitstellungsrichtlinie prüfen oder verifizieren, ob ein Endpunkt erreichbar ist. Mehrere Modellaufrufe allein garantieren kein tieferes Verständnis.
Die schwierigste Aufgabe besteht darin, Sicherheit nachzuweisen. Offensive Tests liefern häufig ein sichtbares Ergebnis, weil ein Exploit gelingt oder scheitert. Ein fehlgeschlagener Versuch beweist nicht, dass kein anderer Exploit existiert; daher bleibt das Ausbleiben eines Erfolgs schwer zu interpretieren.
Die umgebungsabhängigen Beispiele von AWS verdeutlichen dieses Problem. Ein Modell muss über Code und Infrastruktur hinweg schlussfolgern und dann erkennen, dass eine Gegenmaßnahme den zunächst erkannten Weg blockiert. AWS zufolge erkannten Modelle häufig das riskante Muster, ignorierten aber die nahegelegene Kontrolle.
Dieses Verhalten ähnelt einem verbreiteten menschlichen Bias bei Sicherheitsprüfungen. Sobald ein Prüfer eine vertraute Form von Schwachstelle erkennt, kann Bestätigung schneller eintreten als Widerlegung. Sprachmodelle verstärken das Problem, weil Mustererkennung zentral für die Erzeugung ihrer Antworten ist.
Für Käufer ist die praktische Lehre konkret. Fragen Sie, ob ein KI-Sicherheitsprodukt die Ausnutzbarkeit verifiziert und wie es beide Fehlerraten misst. Eine Recall-Zahl ohne Daten zu False Positives verrät wenig über den Arbeitsaufwand, den das Produkt verursacht.
Die eigenen Sicherheitssysteme von AWS zeigen, warum Architektur zählt
Die Produktionsaussagen von AWS beruhen auf geschichteten Agenten, deterministischen Prüfungen und menschlicher Freigabe – nicht auf einem nicht unterstützten Modell, das entscheidet, ob Code sicher ist.
Der Benchmark erschien Monate, nachdem AWS zwei agentische Sicherheitssysteme beschrieben hatte. Diese früheren Veröffentlichungen bieten einen wichtigen Kontrapunkt, weil sie zeigen, wie Amazon versucht, die nun direkt gemessenen Einschränkungen zu bewältigen.
RuleForge erzeugt Erkennungsregeln aus öffentlich verfügbaren Exploit-Beispielen. AWS zufolge steigerte das System die Produktivität bei der Regelerstellung während der letzten vier Monate des Jahres 2025 gegenüber einem manuellen Prozess um 336 %.
Seine Architektur teilt die Aufgabe auf spezialisierte Stufen auf. Eine Komponente nimmt Schwachstelleninformationen auf und priorisiert sie. Generierungsagenten schlagen mehrere Erkennungsregeln vor. Ein separater Judge bewertet sie, synthetische Tests prüfen sie, und Traffic-Daten unterstützen die weitere Validierung.
Ein Security Engineer bleibt die letzte Freigabeinstanz. Diese menschliche Rolle ist wichtig, weil RuleForge die Zuversicht eines KI-Modells nicht als ausreichenden Nachweis für die Bereitstellung behandelt.
AWS erklärte, dass das Generierungsmodell fast jede Regel hoch bewertete, wenn es gebeten wurde, seine eigene Arbeit zu beurteilen. Die Verlagerung der Bewertung auf ein separates Modell verringerte laut der RuleForge analysis des Unternehmens die False Positives um 67 %, während die Zahl der True-Positive-Erkennungen erhalten blieb.
Der Judge erhielt zudem domänenspezifische Fragen. Statt zu fragen, ob eine Regel korrekt aussehe, fragte das System, ob sie bösartige Anfragen übersehen könnte. Es prüfte außerdem, ob eine Regel den Mechanismus der Schwachstelle erfasste oder lediglich ein korreliertes Oberflächenmerkmal.
Diese Unterscheidung entspricht dem Deception Benchmark. Ein lockerer Ausdruck könnte Eingaben mit einem einfachen Anführungszeichen abgleichen, doch die Übereinstimmung mit dem Zeichen beweist keine SQL-Injection. Die Regel muss Exploit-Verhalten von harmlosen Traffic unterscheiden, der dasselbe Merkmal teilt.
AWS Security Agent nutzt eine verwandte Strategie für automatisierte Penetrationstests. Spezialisierte Agenten erkunden Anwendungen und erzeugen potenzielle Befunde, während Validatoren Exploit-Belege verlangen.
AWS berichtete, dass sein System auf CVE Bench v2.0 eine Angriffs-Erfolgsrate von 92,5 % erreichte, wenn es Capture-the-Flag-Anweisungen und Grader-Feedback erhielt. Ohne diese Hilfen sank die Rate auf 80 % und erreichte 65 % mit einem Modell, dessen Trainings-Cutoff vor dem Benchmark lag.
Diese Zahlen messen offensiven Erfolg, nicht defensive Präzision. CVE Bench enthält verwundbare Anwendungen und prüft, ob Agenten bekannte Schwachstellen ausnutzen können. Es beantwortet nicht, wie häufig das System sicheren Code beschuldigen würde.
Dennoch veranschaulicht die agent architecture eine glaubwürdige Antwort auf die Schwäche des Benchmarks. Potenzielle Befunde durchlaufen deterministische und modellbasierte Prüfungen, während Berichte Exploit-Belege und technischen Kontext enthalten.
Dies erzeugt nur dann einen scheinbaren Widerspruch, wenn „KI-gestützte Schwachstellenerkennung“ als eine einzige Technik behandelt wird. Der Basismodell-Benchmark legt schwaches Urteilsvermögen in einem einzelnen Durchlauf offen. Die Produktionssysteme von AWS beanspruchen ihren Nutzen aus Workflows, die Belege sammeln und dieses Urteilsvermögen begrenzen.
Der Vergleich stützt eine präzisere Schlussfolgerung. General-Purpose-Modelle sind nützliche Komponenten für die Sicherheitsautomatisierung, doch das sie umgebende System bestimmt, ob ihr Output operatives Vertrauen verdient.
Ein Anbieter kann die Lücke nicht schließen, indem er wiederholten Prompts ein Agent-Label gibt. Die relevanten Fragen betreffen Tools, Belege, Kalibrierung, Fehlerbehandlung und menschliche Aufsicht. Käufer sollten fragen, was sich zwischen dem ersten Verdacht und dem endgültigen Befund verändert.
Führt das Produkt den angeblich verwundbaren Pfad aus? Prüft es Infrastrukturkontrollen? Kann es Daten über Repository-Grenzen hinweg verfolgen? Vergleicht es Ergebnisse mit deterministischen Analysetools? Kann ein Prüfer nachvollziehen, warum der Befund die Validierung überstanden hat?
Teams benötigen während der Untersuchung außerdem dauerhaften Kontext. Architekturnotizen, frühere Ausnahmen, Threat Models und Entscheidungen zur Behebung liegen oft über Dokumente und Gespräche verteilt. Eine durchsuchbare engineering knowledge base kann Prüfern helfen, diesen Kontext wiederherzustellen, ersetzt jedoch keine technische Validierung.
Beschaffungsevaluierungen sollten drei Ebenen unterscheiden. Die erste ist das zugrunde liegende Modell, für das Deception Benchmark eine gemeinsame Baseline bietet. Die zweite ist die Validierungsarchitektur, die bestimmt, wie das System zusätzliche Belege sammelt. Die dritte ist der Betriebsprozess, einschließlich der Zuständigkeit für Reviews und des akzeptablen Risikos.
Ein Produkt kann auf einer Ebene gut und auf einer anderen schlecht abschneiden. Ein leistungsfähiges Modell kann durch vage Prompts und fehlenden Kontext geschwächt werden. Ein weniger leistungsfähiges Modell kann nützlicher werden, wenn enge Tools und strikte Validierung seine Entscheidungen begrenzen.
Die Veröffentlichungen von AWS enthalten zudem unternehmenseigene Angaben und keine unabhängigen Audits der Produktionsleistung. Die Produktivitätsaussage von 336 % und die Verringerung der False Positives um 67 % beschreiben RuleForge unter der Bewertung von Amazon. Sie sollten nicht auf nicht verwandte Repositories oder Produkte verallgemeinert werden.
Diese Unsicherheit stärkt das Argument für einen öffentlichen Benchmark. Anbieter können ihre vollständigen Systeme beim Deception Benchmark einreichen und getrennte agentische Ergebnisse berichten. Kunden können dann Aussagen vergleichen, die unter einer gemeinsamen Aufgabe gemacht wurden, statt sich auf inkompatible Fallstudien zu verlassen.
False Positives verwandeln KI-Geschwindigkeit in menschliche Arbeit
Das Geschäftsrisiko besteht nicht darin, dass KI nichts findet, sondern darin, dass plausible Fehler die Personen binden, die echte Befunde bestätigen müssen.
Sicherheitstools kämpfen seit Langem mit False Positives. Traditionelle statische Anwendungssicherheitstests scannen Quellcode nach gefährlichen Datenflüssen oder Konstrukten, oft ohne vollständigen Laufzeitkontext. KI verspricht besseres semantisches Schlussfolgern, doch die Ergebnisse von AWS zeigen, dass erkennbare Muster weiterhin eine starke Anziehungskraft ausüben.
Stellen Sie sich ein Entwicklungsteam vor, das eine dringende SQL-Injection-Warnung erhält. Ein Engineer unterbricht geplante Arbeit, findet den zuständigen Owner, prüft den Query-Pfad und bestätigt, dass Parameter Binding die Injection verhindert. Die Warnung benötigt anschließend Abschlussnotizen, damit sie beim nächsten Scan nicht erneut geöffnet wird.
Ein Fehler scheint beherrschbar. Tausende Repositories und häufige Scans verändern die Rechnung. Eine hohe False-Positive-Rate verwandelt automatisierte Erkennung in eine wiederkehrende Warteschlange manueller Verifizierung.
Diese Warteschlange verursacht mehrere Kostenarten. Die Engineering-Arbeit verlangsamt sich, weil die Behebung die Feature-Auslieferung unterbricht. Sicherheitsteams verbringen Zeit damit, die Glaubwürdigkeit des Scanners zu verteidigen. Anwendungs-Owner lernen, Warnungen als unbestätigte Vorschläge zu behandeln.
Irgendwann schwindet das Vertrauen. Eine echte Schwachstelle kann über denselben Kanal eintreffen und dieselbe skeptische Reaktion erhalten. Das Erkennungssystem hat den Fehler weiterhin „gefunden“, doch operativ hat es keine rechtzeitige Handlung ausgelöst.
False Negatives schaffen die entgegengesetzte Gefahr. Ein strengeres System kann Unterbrechungen reduzieren, indem es weniger Probleme meldet, doch sein Schweigen wird weniger vertrauenswürdig, wenn es einen großen Anteil echter Schwachstellen übersieht.
Deshalb ist die doppelte Schwelle von AWS wichtig. Eine ausschließliche Messung der Präzision belohnt konservative Systeme, die fast nichts melden. Eine ausschließliche Messung des Recall belohnt aggressive Systeme, die fast alles markieren. Produktionsentscheidungen benötigen beide Werte, segmentiert nach Schwachstellenschwere und Code-Kontext.
Teams sollten außerdem fragen, wie ein Anbieter Ground Truth ermittelt hat. Schwachstellenlabels sind schwierig, weil Code aus Gründen außerhalb der sichtbaren Funktion sicher sein kann. Abhängigkeiten, Konfiguration, Authentifizierung, Netzwerkkontrollen und Bereitstellungszustand können die Ausnutzbarkeit verändern.
Das Team hinter Deception Benchmark versuchte, Label-Fehler durch wiederholte unabhängige Prüfung zu begrenzen und umstrittene Fälle aus der Bewertung auszuschließen. Das ist eine durchdachte Designentscheidung, wirft jedoch eine weitere Frage auf: Wie stark ähneln die eindeutig beurteilten Samples der Mehrdeutigkeit realer Enterprise-Systeme?
Reale Repositories enthalten unvollständige Tests, undokumentierte Annahmen, veraltete Konfiguration, generierten Code und Lücken bei Zuständigkeiten. Ein Tool muss möglicherweise sagen, dass die Belege nicht ausreichen, statt eine binäre Entscheidung zwischen verwundbar und sicher zu erzwingen.
Der Benchmark verlangt derzeit diese binäre Entscheidung. Detaillierte Erklärungen sind erforderlich, aber Enthaltung ist nicht als bewertetes Ergebnis aufgeführt. Künftige Bewertungen könnten untersuchen, ob kalibrierte Unsicherheit Teams hilft, ihren Prüfaufwand zuzuweisen.
Auch Latenz und Kosten verdienen Aufmerksamkeit. Ein Multi-Agent-System könnte False Positives reduzieren, indem es Tests ausführt und breiteren Kontext prüft. Diese Verbesserung könnte mehr Rechenleistung, längere Prüfzeiten und Zugriff auf sensiblen Code oder Infrastruktur erfordern.
Diese Trade-offs entkräften agentische Verifizierung nicht. Sie bestimmen, wo sie hingehört. Änderungen mit hohem Risiko können eine tiefere Analyse rechtfertigen, während Routinecode möglicherweise günstigeres Screening benötigt, gefolgt von selektiver Eskalation.
Sicherheitsverantwortliche sollten vermeiden, eine Vanity Metric durch eine andere zu ersetzen. Ein Gesamt-Accuracy-Score verdeckt die Richtung von Fehlern. Eine dramatische Produktivitätszahl kann den Review-Aufwand verbergen. Eine beeindruckende Exploit-Erfolgsrate sagt wenig über sicheren Code aus.
Eine glaubwürdige Bewertung sollte mindestens fünf Dinge offenlegen: False-Positive-Rate, False-Negative-Rate, Abdeckung, Validierungsmethode und Leistung nach Schwachstellenkategorie. Sie sollte auch Verweigerungen und ungültige Ausgaben ausweisen, statt sie stillschweigend zu entfernen.
Die Abdeckung betraf ein AWS-Ergebnis. Die meisten Konfigurationen lieferten für mindestens 98 % der Stichproben valide Antworten. GPT-5.6 Sol erreichte unter Prompts zum Nachweis eines Exploits 93 %, da ein Sicherheitsfilter des Anbieters einige Anfragen zur Exploit-Konstruktion ablehnte.
Dieses Detail zeigt eine weitere Einschränkung im Produktionseinsatz. Sicherheitsagenten müssen manchmal über schädliche Techniken nachdenken, um Schutzmaßnahmen zu validieren. Sicherheitskontrollen von Modellen können legitime Evaluierungen blockieren und so fehlende Ergebnisse erzeugen, die gemessen statt ignoriert werden müssen.
Für Unternehmenskäufer ist kontrollierte Unterstützung kurzfristig die beste Position. Lassen Sie KI priorisieren, erklären und Belege zusammenstellen. Behalten Sie die menschliche Prüfung bei risikoreichen Codepfaden bei, insbesondere wenn der Deployment-Kontext oder die Geschäftslogik darüber entscheidet, ob ein Angriff funktioniert.
Das Wertversprechen wird dadurch enger, aber besser vertretbar. KI kann die Suchzeit verkürzen und Hypothesen sichtbar machen. Sie sollte keine einseitige Entscheidungsbefugnis erhalten, nur weil ihre Ausgabe selbstsicher klingende technische Sprache enthält.
Worauf Sicherheitsteams als Nächstes achten sollten
Der Benchmark wird erst dann folgenreich, wenn Anbieter vollständige Systeme testen, ausgewogene Fehlerraten veröffentlichen und zeigen, dass die Fortschritte auch in realen Repositories bestehen.
Das erste Signal ist die Beteiligung. AWS lädt Entwickler ein, alle 14.822 Stichproben auszuführen und Vorhersagen zur verifizierten Bewertung einzureichen. Mehrstufige Systeme mit Tools werden getrennt von Single-Turn-Modellen bewertet.
Unabhängige Einreichungen werden zeigen, ob agentische Verifizierung die gemessene Lücke schließt. Wenn vollständige Systeme beide Fehlerraten unter 10 % drücken, würden die Ergebnisse die AWS-Ansicht stützen, dass Architektur schwaches Basisurteil ausgleichen kann. Falls nicht, reicht das Vertrauensproblem tiefer.
Das zweite Signal ist die Reproduzierbarkeit. Forschende sollten die veröffentlichten Stichproben, Herausforderungs-Kategorien, den unbewerteten Pool und den Prozess mit verborgenen Labels prüfen. Vergleichbare Bewertungen unabhängiger Gruppen würden zeigen, ob Modellrankings und Fehlermuster außerhalb der AWS-Konstruktionsmethode bestehen bleiben.
Das dritte Signal sind Belege aus der Praxis. Anbieter sollten offenlegen, wie viele Warnmeldungen Nutzer untersuchen, verwerfen, erneut öffnen und letztlich beheben. Diese Workflow-Ergebnisse sind wichtiger als der isolierte Klassifikationswert eines Modells.
Der Benchmark verschafft Käufern außerdem eine bessere Ausschreibungsanforderung. Bitten Sie Anbieter, ihre Systeme einzureichen und verifizierte Falsch-Positiv- und Falsch-Negativ-Raten zu teilen. Fragen Sie dann, wie sich ihr Validierungsprozess für kritischen Code, umgebungsabhängige Befunde und nicht unterstützte Programmiersprachen verändert.
Entwickler sollten darauf achten, wie Tools Unsicherheit darstellen. Ein nützlicher Prüfer sollte bestätigte Exploit-Pfade von plausiblen Bedenken und fehlendem Kontext trennen. Diese Kategorien gleich zu behandeln, erzeugt vermeidbare Arbeit und verschleiert die tatsächliche Sicherheit des Systems.
Die AWS-Forschung zur KI-gestützten Schwachstellenerkennung hat nicht gezeigt, dass KI-Sicherheitsprüfungen nutzlos sind. Sie hat gezeigt, warum Erkennung ohne disziplinierte Verifizierung teuer und riskant bleibt.
Der nächste Test liegt bei Produktteams und Käufern. Fordern Sie Belege dafür, dass ein Befund Code-Nachverfolgung, Umgebungsprüfungen und reproduzierbare Validierung übersteht, bevor er einem Entwickler als dringende Arbeit vorgelegt wird. Wird Ihr Sicherheitsanbieter beide Arten von Fehlern veröffentlichen oder weiterhin Geschwindigkeit verkaufen, ohne die dahinterliegende Prüfwarteschlange offenzulegen?
