Anthropic hat das Claude Security Plugin für Claude Code als Beta vorgestellt. Claude Code ist Anthropics terminalbasierter agentischer Coding-Assistent, und das Plugin erweitert ihn in den Bereich der Sicherheitsanalyse, der traditionell spezialisierten Tools für Static Application Security Testing (SAST) vorbehalten ist. Das Plugin führt direkt innerhalb einer bestehenden Claude-Code-Sitzung einen Multi-Agenten-Schwachstellenscan eines Repositorys aus und wandelt ausgewählte Befunde in Patch-Dateien um, die der Nutzer manuell prüft und anwendet. Anthropic hob zum Start die Flexibilität des Tools hervor und erklärte, dass es entweder einen umfassenden Scan über eine gesamte Codebasis durchführen oder Änderungen unmittelbar vor einem Commit direkt aus dem Terminal prüfen kann.

Was das Plugin hinzufügt

Das Plugin führt einen einzigen Befehl ein, /claude-security, der laut der offiziellen Dokumentation ein Menü mit drei Aufgaben anzeigt:

• Codebasis scannen — das gesamte Repository oder einen abgegrenzten Teil davon
• Änderungen scannen — den Diff eines Branches, den Diff eines Pull Requests oder einen einzelnen Commit
• Patches vorschlagen — die Befunde eines Berichts in .patch-Dateien umwandeln

Die Installation erfordert zwei Befehle aus dem offiziellen Anthropic-Marktplatz. Wird der Marktplatz nicht gefunden, muss zuerst /plugin marketplace add anthropics/claude-plugins-official ausgeführt werden. Der Quellcode des Plugins ist im Repository claude-plugins-official öffentlich verfügbar, derzeit in Version 0.10.0.

Wie die Scan-Pipeline aufgebaut ist

Der Scan ist als dynamischer Workflow implementiert — ein JavaScript-Orchestrierungsskript, das Arbeit auf Subagenten verteilt. Das Skript definiert sechs Phasen:

1. Inventarisierung: Aufteilung des Repositorys in Komponenten. Jedes Verzeichnis auf oberster Ebene muss entweder gescannt oder mit einer Begründung ausdrücklich übersprungen werden.
2. Bedrohungsmodell: ein Modellierer pro Komponente, der Einstiegspunkte, Senken, Vertrauensgrenzen und Dateien ermittelt, die ein Researcher vollständig lesen muss.
3. Research: ein Researcher pro Komponente × Kategorie-Zelle.
4. Sweep: Lückenfüllung in Bereichen, die von der Matrix nicht abgedeckt wurden.
5. Panel: adversariale Verifikation mit drei Perspektiven, ein Abstimmender pro Perspektive.
6. Adversarial (nur bei maximalem Aufwand): erneutes Panel für grenzwertig beibehaltene Befunde, anschließend Red-Teaming jedes verbleibenden Befunds.

Die Analyse arbeitet mit vier festen Kategorien: injection-and-input, auth-and-access, memory-and-unsafe sowie crypto-and-secrets. Die Perspektive memory-and-unsafe wird bei Komponenten ausgelassen, die vollständig in speichersicheren Sprachen geschrieben sind; eine reine Python- oder TypeScript-Komponente erhält daher drei statt vier Perspektiven.

Der operative Umfang eines Laufs wird durch vier unterschiedliche Aufwandsebenen gesteuert: low, medium, high und max. Je nach ausgewählter Ebene werden bestimmte Schwellenwerte durchgesetzt: Die maximale Anzahl von Komponenten ist bei low und medium auf 12 begrenzt und steigt bei high und max auf 24; Matrix-Zellen erhalten auf niedrigeren Ebenen 1 Researcher, bei high und max steigt dies auf 2; und die Anzahl der Gap-Fill-Sweeps skaliert von 0 bei low über 1 bei medium bis auf 2 bei high und max. Bei einem begrenzten Umfang oder einem kleinen Diff wird der Prozess auf eine Konfiguration mit einem einzelnen Researcher verdichtet, statt die vollständige Matrix einzusetzen. Dadurch bleibt die Bewertung strikt proportional zum Ziel, während derselbe Verifikationsstandard beibehalten wird.

Das System verwendet Agenten mit unterschiedlichen Modellstufen: Der Orchestrator läuft auf Opus, während der Repository-Kartograf und der schreibgeschützte Code-Explorer auf Sonnet laufen. Das Sitzungsmodell wird von Researchern und Verifizierern übernommen, und Scan-Agenten sind ausschließlich auf schreibgeschützte Tools beschränkt.

Wie ein Befund in den Bericht gelangt

False Positives sind seit Langem eine anhaltende Herausforderung bei der automatisierten Schwachstellenerkennung und zwingen Sicherheitsteams häufig dazu, verrauschte Berichte zu triagieren. Die Architektur des Plugins adressiert dies, indem ein potenzieller Befund nicht allein deshalb in den Bericht aufgenommen wird, weil ein Researcher ihn identifiziert hat. Er wird nur aufgenommen, nachdem er ein Panel überstanden hat.

Jeder Kandidat wird von drei unabhängigen Verifizierern bewertet, je einer pro Perspektive: REACHABILITY, IMPACT und DEFENSES. Jeder gibt ein strukturiertes Urteil von TRUE_POSITIVE oder FALSE_POSITIVE zurück, zusammen mit ein oder zwei Zeilen, die die entscheidende Datei:Zeile benennen. Das Quorum für das Beibehalten beträgt 2 von 3. Wenn weniger als drei Abstimmende antworten, kann der Kandidat überhaupt nicht beibehalten werden.

Das Panel-Ergebnis begrenzt außerdem die angegebene Konfidenz des Befunds. Ein einstimmiges 3/3-Panel erlaubt eine Konfidenzobergrenze von high; ein 2/3-Quorum begrenzt sie auf medium. Ein Befund kann keine höhere Konfidenz beanspruchen, als seine Verifikation ergeben hat.

Entscheidend ist, dass die Auszählung in Python durch den Report-Renderer berechnet wird und nicht von dem Modell behauptet wird, das die Befunde erzeugt hat. Der verification.status des Revision-Stamps wird nur dann auf verified gesetzt, wenn der Abstimmungsdatensatz belegt, dass das Panel für jeden Befund im Bericht durchgeführt wurde; andernfalls wird er mit einer angegebenen Begründung als unverified markiert. Damit lässt sich die Aussage des Berichts über seine eigene Strenge überprüfen, statt sie lediglich vorauszusetzen.

Was ein Scan auf die Festplatte schreibt

Jeder Scan erstellt im Repository ein mit Zeitstempel versehenes Verzeichnis CLAUDE-SECURITY-<timestamp>/, das drei Artefakte enthält:

• CLAUDE-SECURITY-RESULTS.md — der menschenlesbare Bericht. Jeder Befund enthält eine ID wie F1 sowie Schweregrad (HIGH/MEDIUM/LOW), Konfidenz, CWE-ID, die exakte Senken-Zeile, Auswirkungen, Exploit-Szenario, Vorbedingungen und eine Empfehlung. Die Verwendung von CWE-Kennungen (Common Weakness Enumeration) ordnet Befunde dem breit eingesetzten MITRE-Klassifikationsstandard zu und macht Ergebnisse mit bestehenden Workflows für Schwachstellenverfolgung und Behebung interoperabel.
• CLAUDE-SECURITY-RESULTS.jsonl — dieselben Befunde, ein JSON-Objekt pro Zeile.
• CLAUDE-SECURITY-REVISION-.json — der Revision-Stamp: welcher Commit gescannt wurde, mit welchem Aufwand, die Anzahl der Schweregrade und wie gründlich der Lauf verifiziert wurde. Der Dateiname enthält -dirty, wenn nicht committete Änderungen Teil des gescannten Baums waren.

Dieses Verzeichnis ist die einzige Änderung, die ein Scan am Checkout vornimmt, und es enthält eine eigene .gitignore, sodass ein versehentliches git add keinen Bericht in einen Commit übernimmt. Das Entfernen dieser .gitignore ermöglicht es, den Bericht für einen Audit-Trail zu committen.

Patches und die drei Aussagen, die jeder Patch erfüllen muss

Der Fix-Job entwickelt jeden Patch in einem Scratch-Klon des Repositorys, sodass Working Tree und Index nie berührt werden. Ein Agent, der unabhängig von dem Agenten ist, der den Patch geschrieben hat, prüft anschließend den staged Diff und führt die eigene Testsuite des Projekts gegen die Änderung aus.

Eine Patch-Datei wird nur geschrieben, wenn der Verifizierer alle drei folgenden Punkte mit Konfidenz bestätigen kann: Die Änderung behebt genau diesen Befund, sie führt keine neue Schwachstelle ein, und das Verhalten bleibt ansonsten unverändert — wobei eine Änderung daran, welche Eingaben der Code akzeptiert, als Verhaltensänderung zählt. Jede Änderung, die die Sicherheit schwächt, während sie vorgibt, sie zu verbessern, etwa eine gelockerte Authentifizierungsprüfung oder ein deaktivierter Test, wird automatisch abgelehnt. Kann der Verifizierer nicht für alle drei Kriterien einstehen, wird statt eines Patches eine kurze Erläuterung bereitgestellt.

Patches werden im Ordner patches/ des Berichts als F<n>.patch abgelegt. Nichts wird automatisch angewendet. Der Patch-Hinweis gibt ausdrücklich an, wenn kein Repository-Test den geänderten Code abdeckt, und stellt damit klar, dass die Verifikation auf Code-Review statt auf Testausführung beruht. Anthropic empfiehlt, jeden Patch über einen eigenen Pull Request anzuwenden.

Anforderungen, Kosten und das Vertrauensmodell

Das Plugin erfordert einen kostenpflichtigen Tarif mit Claude Code v2.1.154 oder neuer, wobei dynamische Workflows in /config aktiviert sein müssen. Außerdem benötigt es Python 3.9.6 oder neuer im System-PATH als python3 (ausschließlich unter Verwendung der Standardbibliothek) sowie Git für Änderungsscans und Patching. Linux, macOS und Windows werden unterstützt, und Scans werden auf die Token-Limits des Tarifs angerechnet.

Da der Scan in der Sitzung des Nutzers und mit dessen Berechtigungen läuft, fügt er keine eigene Isolation hinzu. Das bedeutet, dass committete .claude/-Einstellungen, Hooks und CLAUDE.md weiterhin gelten. Zwar behandelt er Repository-Inhalte als Daten und nicht als Anweisungen, doch ist dies kein Schutz gegen feindliche Repositorys; Anthropic rät dazu, sandbox-runtime zu verwenden, um unbekannte Codebasen in einer Sandbox auszuführen.

Darüber hinaus sind Scans nicht deterministisch und ersetzen weder klassische statische Analyse noch Dependency-Scanning oder Code-Reviews. Das Plugin tritt in ein Umfeld ein, zu dem etablierte Tools wie Semgrep, Snyk und SonarQube gehören, unterscheidet sich jedoch durch seine Multi-Agenten-Pipeline, die eine semantische Analyse von Codepfaden durchführt, statt sich primär auf Pattern-Matching-Regeln zu stützen. Als Beta-Produkt in Version 0.10.0 können sich Umfang, Genauigkeit und Funktionsumfang weiterentwickeln.

Quellen: Dokumentation zum Claude Security Plugin, Claude Security Produktseite, Plugin-Quellcode, claude-plugins-official, Ankündigung von @claudeai und Blog zur öffentlichen Beta von Claude Security