Wenn Ihr Agent eine Sicherheitslücke findet

Nicholas Carlini, Forschungswissenschaftler bei Anthropic, richtete Claude Code auf den Linux-Kernel-Quellcode und gab die Anweisung, Sicherheitslücken zu finden. Das Setup: ein 10-Zeilen-Bash-Skript plus ein Docker-Container mit ASAN-instrumentierten Builds. Quelldateien durchiterieren, das Modell nach Fehlern suchen lassen, zur nächsten Datei weiter.¹³

Das Ergebnis, wie in Michael Lynchs Zusammenfassung des Vortrags beschrieben:² ein aus der Ferne ausnutzbarer Heap-Buffer-Overflow im NFSv4-LOCK-Replay-Cache, vorhanden seit März 2003 — älter als Git selbst. Zwei zusammenarbeitende NFS-Clients können sensiblen Kernel-Speicher auslesen, indem sie einen 112-Byte-Puffer mit einer 1.024 Byte großen Lock-Owner-ID überlaufen lassen. Carlini fand im selben Durchlauf mindestens vier weitere Kernel-Sicherheitslücken. Unabhängig davon lieferte dieselbe Methodik 122 Crash-Inputs an Mozilla, von denen 22 CVEs erhielten.³ Er beschrieb „mehrere hundert Abstürze”, die er noch nicht validieren und melden konnte.²

Dies sind bestätigte, an Maintainer gemeldete Sicherheitslücken, gefunden von einem Agenten mit Opus 4.6 — derselben Modellklasse, die Entwickler täglich für Code-Review, Refactoring und Feature-Entwicklung einsetzen. Carlini präsentierte die Ergebnisse auf der [un]prompted AI Security Conference im April 2026.¹

Kurzfassung

Carlinis Methodik war minimal: Quelldateien durchiterieren, Claude auffordern Sicherheitslücken in jeder einzelnen zu finden, Treffer mit ASAN-Assertions verifizieren. Opus 4.6 fand deutlich mehr Sicherheitslücken als Opus 4.1 (8 Monate älter) oder Sonnet 4.5 (6 Monate älter), was darauf hindeutet, dass kürzlich eine Fähigkeitsschwelle überschritten wurde.² Der Engpass liegt nun bei der menschlichen Validierung, nicht bei der KI-gestützten Entdeckung. Das hat direkte Auswirkungen darauf, wie Entwickler Security-Hooks bauen, Code-Reviews durchführen und über agentengestütztes Auditing nachdenken.

Wichtigste Erkenntnisse

• Sicherheitsingenieure: Die Fähigkeit ist real und verbessert sich rasant. Wer agentengestütztes Code-Review einsetzt, sollte den eigenen PreToolUse-Security-Hooks mehr Aufmerksamkeit denn je schenken — nicht um Claude zu blockieren, sondern um zu steuern, was es mit seinen Entdeckungen tun kann.
• Harness-Entwickler: Der Verifizierungsengpass („mehrere hundert Abstürze, die ich noch nicht validiert habe”) ist ein Harness-Problem. Automatisierte Triage, Deduplizierung und Schweregradklassifizierung sind die nächste Infrastrukturebene.
• Alle anderen: Dasselbe Modell, das 446-fache Performance-Regressionen einführt, findet auch Fehler, die 23 Jahre menschlicher Überprüfung übersehen haben. Beides ist gleichzeitig wahr.

Die Methodik

Carlinis Ansatz erforderte weder ein spezialisiertes Sicherheits-Framework noch ein feingetuntes Modell oder spezielle Prompts. Er beschrieb es als „10-Zeilen-Bash-Skript plus Docker-Container”:³

1. Das Ziel mit ASAN (AddressSanitizer) instrumentiert kompilieren
2. Quelldateien durchiterieren und das Modell die Sicherheitsrelevanz bewerten lassen
3. Claude Code für hochrelevante Dateien mit einem Capture-the-Flag-Framing prompten
4. Mehrere Durchläufe pro Ziel ausführen (5–20 je nach Codebasis)
5. Automatisierte Kritik-Agenten zur Verifizierung der Ergebnisse vor der Offenlegung einsetzen

Das Capture-the-Flag-Framing ist entscheidend. Dem Modell zu sagen „Dieser Code hat einen Fehler” aktiviert einen anderen Modus als „Überprüfe diesen Code auf Probleme.” Entwickler beobachten dasselbe Muster im Arbeitsalltag — Claude findet mehr Probleme, wenn man ihm sagt, dass ein Problem existiert, als wenn man fragt, ob eines existieren könnte.²

Die Kosten des Durchlaufs werden in API-Tokens gemessen, nicht in Personenmonaten. Carlini fand fünf bestätigte Linux-Kernel-Sicherheitslücken und 22 Firefox-CVEs mit einem handelsüblichen Agenten-CLI.³ Dasselbe Werkzeug, das Ihre Unit-Tests schreibt und Ihre Imports formatiert.

Die Fähigkeitsschwelle

Das auffälligste Ergebnis ist der Generationsunterschied zwischen den Modellen. Carlini versuchte, seine Ergebnisse mit älteren Modellen zu reproduzieren:²

• Opus 4.6 (veröffentlicht ca. 2 Monate vor dem Vortrag): fand den Heap-Overflow und mehrere weitere Sicherheitslücken
• Opus 4.1 (8 Monate zuvor): fand nur einen Bruchteil
• Sonnet 4.5 (6 Monate zuvor): fand nur einen Bruchteil

Zwischen den Modellgenerationen wurde offenbar eine Schwelle überschritten. Die Fähigkeit, eine komplexe Codebasis im Kontext zu halten, Datenflüsse über Funktionsgrenzen hinweg nachzuvollziehen und subtile Spezifikationsabweichungen zu identifizieren, scheint sprunghaft entstanden zu sein statt sich graduell zu verbessern.

Carlini formulierte es unverblümt: „Ich habe in meinem ganzen Leben noch nie eine solche Lücke gefunden. Das ist extrem, extrem, extrem schwierig. Mit diesen Sprachmodellen habe ich eine ganze Reihe davon.”²

Das Paradoxon

Dieselbe Agentenarchitektur, die Performance-Regressionen einführt — 118 Funktionen mit Verlangsamungen von 3x bis 446x — findet auch Sicherheitslücken, die jahrzehntelange Expertenprüfung übersehen hat. Beides sind komplementäre Aspekte desselben Fähigkeitsprofils. Schwachstellenforschung ist im Kern Mustererkennung gegen bekannte Klassen (Buffer Overflows, Use-after-Free, Integer-Vorzeichenfehler), was eine Stärke von LLM ist.⁴ Performance-Optimierung verlangt das Gegenteil: Nachdenken über spezifische Ausführungskontexte, Cache-Verhalten und algorithmische Komplexität. Das Modell erkennt einen Buffer Overflow über Millionen Codezeilen hinweg, kann Ihnen aber nicht sagen, dass eine Hash Map für Ihr Zugriffsmuster langsamer ist als ein sortiertes Array. Gestalten Sie Ihren Harness entsprechend — Security-Hooks, die Funde melden, Performance-Hooks, die vor dem Commit messen.

Der Verifizierungsengpass

Carlinis aufschlussreichstes Eingeständnis: „Ich habe so viele Fehler im Linux-Kernel, die ich nicht melden kann, weil ich sie noch nicht validiert habe.”²

Der Engpass hat sich von der Entdeckung zur Triage verlagert. Potenzielle Sicherheitslücken zu finden ist mittlerweile günstiger, als zu bestätigen, dass sie real sind. Das schafft ein neues Infrastrukturproblem für Sicherheitsteams:

Entdeckung ist automatisiert. Ein Agent kann eine Codebasis in Stunden durchsuchen.

Verifizierung ist manuell. Jede potenzielle Sicherheitslücke braucht einen Proof of Concept, eine Auswirkungsanalyse und einen verantwortungsvollen Offenlegungsprozess.

Triage ist die Lücke. Hunderte agentengenerierter Funde in echte Sicherheitslücken, Falsch-Positive und geringfügige Auffälligkeiten zu sortieren — dafür gibt es noch keine guten Werkzeuge.

Es ist dasselbe Muster, das wir beim agentengestützten Code-Review beobachten: Der Agent produziert Rohergebnisse schneller, als Menschen sie bewerten können. Der Wert liegt nicht in der Generierung — er liegt in der Infrastruktur, die den Output verarbeitet, filtert und weiterleitet.

Für Harness-Entwickler bedeutet das: Der nächste hochwertige Hook ist kein Sicherheitsscanner. Es ist ein Sicherheits-Triagesystem: Deduplizierung, Schweregradklassifizierung, Falsch-Positiv-Filterung und automatische Proof-of-Concept-Generierung. Die Governance-Hooks, die den Agenten-Output steuern, sind wichtiger als die Scan-Fähigkeiten selbst.

Was das für Entwickler bedeutet

Wer Claude Code auf Produktions-Codebasen einsetzt, betreibt bereits ein System, das in der Lage ist, echte Sicherheitslücken zu finden. Die Frage ist nicht, ob die Fähigkeit existiert — sondern ob Ihr Harness darauf ausgelegt ist, mit dem umzugehen, was der Agent findet.

Drei praktische Schritte:

Integrieren Sie einen Security-Sweep in Ihre Review-Pipeline. Ein PostToolUse-Hook auf Write/Edit kann einen gezielten Sicherheitsscan für geänderte Dateien auslösen. Der Hook liest den Dateipfad aus stdin (Claude Code übergibt Event-JSON über stdin an Hooks):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Dies ist ein Ausgangspunkt, keine produktionsreife Lösung — Deduplizierung, Schweregrad-Filterung und Ratenbegrenzung müssten noch ergänzt werden. Dennoch entspricht das Grundmuster Carlinis Methodik: eine Schleife über Dateien mit einem gezielten Prompt.³

Bauen Sie Triage-Infrastruktur auf. Rohe Schwachstellenfunde ohne Schweregradklassifizierung sind Rauschen. Wenn Ihr Agent 50 Funde pro Durchlauf produziert, brauchen Sie automatisierte Deduplizierung und Prioritätsbewertung, bevor ein Mensch die Liste sieht. Das ist ein Harness-Problem, kein Modell-Problem.

Akzeptieren Sie das Paradoxon. Dasselbe Modell, das Performance-Leitplanken braucht, ist bei der Mustererkennung von Sicherheitslücken herausragend. Gestalten Sie Ihren Harness so, dass er die Stärke nutzt und die Schwäche kompensiert. Security-Hooks, die scannen. Performance-Hooks, die messen. Quality-Hooks, die verifizieren. Jeder deckt ab, was den anderen entgeht.

Die 23 Jahre alte Linux-Sicherheitslücke war nicht versteckt. Sie lag offen da, in einer Datei, die Tausende von Ingenieuren gelesen hatten. Das Modell fand sie, weil Mustererkennung in großem Maßstab genau das ist, was diese Systeme leisten. Die Lehre ist nicht, dass Agenten besser als Menschen in der Sicherheitsanalyse sind. Die Lehre ist, dass Agenten eine andere Oberfläche abdecken — und der Harness, der beide orchestriert, macht die Kombination zuverlässig.

Quellen

Häufig gestellte Fragen

Kann ich Carlinis Ansatz mit Claude Code reproduzieren?

Die Methodik ist im Podcast-Interview dokumentiert.³ Die Kernschleife: mit ASAN kompilieren, Quelldateien durchiterieren, Claude mit einem Capture-the-Flag-Framing prompten, Treffer verifizieren. Carlini berichtete, dass Opus 4.6 deutlich mehr Sicherheitslücken fand als ältere Modelle — Ergebnisse mit anderen Modellgenerationen können abweichen.

Bedeutet das, dass KI-Agenten besser als Menschen darin sind, Sicherheitslücken zu finden?

Nein. Es bedeutet, dass Agenten eine andere Oberfläche abdecken. Agenten sind hervorragend in der Mustererkennung gegen bekannte Schwachstellenklassen über große Codebasen hinweg. Menschen sind hervorragend darin, neuartige Angriffsvektoren, Geschäftslogik-Fehler und kontextabhängige Sicherheitseigenschaften zu verstehen. Die Kombination ist stärker als jede Seite allein.

Sollte man sich Sorgen machen, dass Angreifer diese Fähigkeit nutzen?

Carlini warnte ausdrücklich vor „einer großen Welle, die kommt.” Dieselbe Fähigkeit, die Verteidigern hilft Sicherheitslücken zu finden, steht auch Angreifern zur Verfügung. Die Asymmetrie besteht darin, dass Verteidiger Triage und Patching automatisieren können, während Angreifer weiterhin Exploits entwickeln müssen — doch die Entdeckungslücke schließt sich.