Claude Code /security-review: was der Sicherheitscheck übergeht - und was er zuverlässig findet

Stand: 17. August 2026. Geprüft mit Claude Code 2.1.233. Anthropic hat den Befehl /security-review am 6. August 2025 eingeführt; sein Prüfumfang ist seither enger geworden. Dieser Beitrag beschreibt, was der Befehl heute leistet, und belegt es mit vier eigenen Durchläufen gegen ein Testrepo - drei gegen einen Branch-Diff, einer gegen die gesamte Codebase. Quellen am Ende des Artikels.

Über /security-review in Claude Code kursieren Beschreibungen, die zwei verschiedene Dinge vermischen: den Befehl, den jeder mit einem Claude-Abo im Terminal aufrufen kann, und ein Forschungsprojekt von Anthropic, das in Open-Source-Software über 500 Schwachstellen hoher Schwere gefunden hat. Das erste ist ein Alltagswerkzeug mit einer langen Liste von Dingen, die es absichtlich nicht meldet. Das zweite lief mit einem anderen Modell in einem anderen Aufbau.

Ich habe deshalb den Anweisungstext des Befehls aus dem ausgelieferten Programm gelesen und ein Testrepo gebaut. Darin sitzen elf Problemstellen: einige, die gemeldet werden müssten, andere, die laut Anweisung stumm bleiben sollten. Drei Läufe später war das Bild klar - der harte Kern der Befunde hielt, der Rand kippte, und fünf Fälle blieben absichtlich stumm.

Was der Befehl heute prüft - und was 2025 anders war

/security-review ist ein eingebauter Befehl in Claude Code, der die Änderungen des aktuellen Branch gegen den Hauptstand des Repositorys vergleicht und dort nach ausnutzbaren Sicherheitslücken sucht. Die Befehlsreferenz beschreibt ihn als “Reviews the diff between your branch and origin’s default branch”. Bestehender Code ausserhalb dieser Änderungen wird ausdrücklich übergangen.

Das war einmal anders. In der Ankündigung vom 6. August 2025 stand: “Claude will search your codebase for potential vulnerabilities.” Die heutige Dokumentation sagt das Gegenteil: “/security-review covers only the changes on your current branch.” Viele Zusammenfassungen zitieren noch den Stand von 2025 und beschreiben damit ein Werkzeug mit deutlich grösserem Prüfumfang, als es heute hat.

Praktisch heisst das zweierlei. Der Befehl braucht ein gesetztes origin/HEAD, sonst bricht er ab, bevor er anfängt. Und er ist heute eine von vier Sicherheitsschichten in Claude Code, neben einem Plugin, das schon beim Schreiben prüft, einem zweiten für tiefere Repository-Scans und dem Code Review für Pull Requests.

Wie er arbeitet: erst suchen, dann sich selbst widerlegen

Der Befehl arbeitet in drei Schritten, und der zweite ist der interessante. Ein erster Durchgang liest den Diff und sammelt Verdachtsfälle. Für jeden Fund startet dann ein eigener Durchgang mit gegenteiligem Auftrag: nachweisen, dass es ein Fehlalarm ist. Diese Gegenprüfungen laufen parallel. Im dritten Schritt fällt alles heraus, was der Gegenprüfer mit weniger als 8 von 10 Konfidenzpunkten bestätigt hat.

01 · Suchen

Ein Durchgang über den Diff

Liest die Änderungen, versteht den Kontext im Repository, sammelt Verdachtsfälle. Gesammelt wird ab 80 Prozent Zutrauen in die Ausnutzbarkeit - gemeldet wird erst nach Schritt 03.

02 · Widerlegen

Je Fund ein Gegenprüfer

Parallel, unabhängig, mit dem Auftrag, den Fund als Fehlalarm zu entlarven. Darf dabei weder Befehle ausführen noch Dateien schreiben.

18 harte Ausschlüsse

03 · Aussortieren

Die Schwelle bei 8 von 10

Wer weniger Konfidenz bekommt, erscheint im Bericht nicht. Übrig bleiben Funde mit Datei, Zeile, Angriffsszenario und Fixvorschlag.

Diese Bauweise erklärt, warum Berichte von /security-review so viel knapper ausfallen als die Ausgabe eines klassischen Scanners: Sie zielt auf wenige belastbare Funde. Wie Claude Code Teilaufgaben generell auf parallele Instanzen verteilt, zeigt der Beitrag über Dynamic Workflows.

Der Test: elf Fälle, drei Läufe, jedes Mal vier Befunde

Ich habe ein Wegwerf-Repository gebaut - ein fiktives Auftragsportal aus Node, Express und SQLite mit einer React-Komponente - und auf einem Feature-Branch 68 Zeilen in vier Dateien geändert. In diesen Zeilen sitzen elf Problemstellen: drei fallen eindeutig in die Kategorien, die der Befehl prüft, fünf stehen ebenso eindeutig auf seiner Ausschlussliste, zwei liegen im Graubereich dazwischen, und eine sitzt im Basis-Commit und damit ausserhalb des Diffs.

Zur Offenlegung gehört: Ich habe die Fälle konstruiert, nachdem ich die Ausschlussliste gelesen hatte. Der Test prüft also, ob die dokumentierten Ausschlüsse in der Praxis greifen - er entdeckt sie nicht. Drei Durchläufe sind eine Stichprobe, kein Datensatz. Läufe 1 und 2 wurden mit demselben Befehl gestartet, Lauf 3 zusätzlich mit maschinenlesbarer Ausgabe für die Kostenmessung. Alle drei liefen mit meinen eigenen Arbeitsanweisungen im Kontext, weshalb die Berichte auf Deutsch herauskamen und einen Abschnitt über die verworfenen Fälle anhängten, den der Befehl so nicht vorsieht. Für die Auswertung war das ein Glücksfall: Er macht sichtbar, was sonst unsichtbar aussortiert wird.

Eingebauter Fall	Lauf 1	Lauf 2	Lauf 3
SQL-Injection in der Kundensuche	HIGH, 10	HIGH, 9	HIGH, 9
Path Traversal beim Belegabruf	HIGH, 9	HIGH, 9	HIGH, 9
Command-Injection im PDF-Export	HIGH, 8	HIGH, 9	HIGH, 8
Hartcodierter Zahlungsschlüssel	verworfen, 7	HIGH, 8	HIGH, 9
Passwortvergleich im Klartext	MEDIUM, 8	verworfen	nicht gemeldet
Die fünf Fälle von der Ausschlussliste	stumm	stumm	stumm
Vorbestehende SQL-Injection im Basis-Commit	stumm	stumm	stumm

SQL-Injection, Path Traversal und Command-Injection sind die gute Nachricht: gefunden in jedem Lauf, mit Konfidenzwerten zwischen 8 und 10 und jedes Mal mit einem konkreten Angriffspfad. Bei der Command-Injection fiel allen drei Durchgängen auf, dass im Repository kein Body-Parser eingerichtet ist und der Endpunkt deshalb heute gar nicht erreichbar wäre. Sie meldeten den Fund trotzdem als schwerwiegend, weil eine einzige nachgezogene Zeile ihn scharf schaltet.

Was er bewusst nicht meldet

Fünf der elf Fälle blieben in allen drei Läufen stumm, und keiner davon aus Versehen. Die Anweisung enthält eine Liste harter Ausschlüsse mit achtzehn Einträgen unter 17 Nummern - die 16 ist doppelt vergeben - und dazu 12 Präzedenzfälle. Die Läufe begründeten ihre Verwerfungen fast durchgehend mit der passenden Regel; nur der Login ohne Versuchsbegrenzung fiel im ersten Lauf kommentarlos unter den Tisch.

Denial of Service bleibt unerwähnt, und mit ihm die Regex mit katastrophalem Backtracking und der ungebremste Login. Veraltete Drittbibliotheken sind ebenfalls ausgenommen; mein Testrepo enthielt ein Paket mit zwei bekannten CVEs, das in keinem Lauf auftauchte. Fehlende Berechtigungsprüfungen in Browser-Code gelten als unproblematisch, weil sie ohnehin auf den Server gehören. Und der Befehl übergeht Befunde in Dokumentationsdateien: Das Datenbank-Passwort im Betriebshandbuch haben alle drei Läufe erkannt, keiner hat es gemeldet.

Ein sechster Fall blieb ebenfalls stumm, aber aus anderem Grund. Die vorbestehende SQL-Injection aus dem Basis-Commit steht auf keiner Ausschlussliste, sie liegt schlicht ausserhalb des Diffs. Alle drei Läufe hatten sie gesehen und aus dem Bericht verwiesen. Für einen gewachsenen Bestand gibt der Befehl keine Antwort.

Das ist kein Mangel, sondern die Bauart: Der Befehl bewacht neue Änderungen, er inventarisiert nicht. Es heisst aber auch, dass ein leerer Bericht keine Aussage über den Zustand einer Anwendung macht. Anthropic formuliert das im eigenen Hilfe-Center so: “While automated security reviews help identify many common vulnerabilities, they should complement, not replace, your existing security practices and manual code reviews.”

Warum derselbe Fund einmal gemeldet wurde und einmal nicht

Jeder Lauf meldete genau vier Funde, und der vierte war jedes Mal ein anderer. Am deutlichsten zeigen das die Läufe 1 und 2: gleicher Befehl, gleicher Diff, gleiche Umgebung - und trotzdem ein anderes Ergebnis. Lauf 1 meldete den Passwortvergleich im Klartext und filterte den hartcodierten Zahlungsschlüssel mit Konfidenz 7 aus, einen einzigen Punkt unter der Schwelle. Lauf 2 tat genau das Umgekehrte. Über alle drei Durchläufe bekam derselbe Schlüssel - ein Wert im Format sk_live_… mitten im Quellcode - die Konfidenzwerte 7, 8 und 9.

Lauf 1 hat sein Ausfiltern sogar begründet. Er sah einen Konflikt zwischen der Prüfkategorie für hartcodierte Schlüssel und dem Ausschluss “Secrets or sensitive data stored on disk (these are handled by other processes)” und entschied im Zweifel gegen die Meldung. Beide Regeln stehen in der Anweisung. Ausgerechnet der Fall, den Zusammenfassungen gern als Stärke führen - das Finden vergessener Zugangsschlüssel -, sitzt an der wackeligsten Stelle des Regelwerks. Auch der stabile Kern hat einen Rand: Die Command-Injection lag in zwei von drei Läufen mit genau 8 auf der Meldeschwelle.

Bemerkenswert ist, dass Anthropic diese Eigenschaft selbst dokumentiert - für das Security-Plugin, das denselben Unterbau nutzt: “Scans are nondeterministic: two scans of the same code can surface different findings.” Wer die Streuung für einen Messfehler hält, liest die Dokumentation nicht.

Zur Einordnung: Eine Studie, die die Streuung zwischen identischen Läufen misst, habe ich in der Recherche nicht gefunden - nur Arbeiten zur Empfindlichkeit gegenüber unterschiedlichen Prompt-Formulierungen und Aussagen von Marktteilnehmern. Der DAST-Anbieter StackHawk schreibt “You can run the same scan twice and get different findings” und nennt das für compliance-getriebene Programme eine echte Einschränkung. Das sind Marktbeobachtungen, keine Messungen; meine drei Läufe auch nicht.

Anthropic selbst geht mit dieser Eigenschaft offen um. Zu den Sicherheitsregeln im zugehörigen Plugin steht in der Dokumentation: “These rules are guidance for the reviewer, not deterministic guardrails.” Und an anderer Stelle: “the review model can miss issues. Treat the plugin as one layer of defense in depth, not a complete security solution.”

Die 500 gefundenen Lücken stammen von einem anderen Aufbau

Die Zahl, die in fast jeder Darstellung auftaucht, ist echt - aber sie gehört nicht zu diesem Befehl. Anthropics Frontier Red Team schrieb am 5. Februar 2026: “So far, we’ve found and validated more than 500 high-severity vulnerabilities.” Das Team liess Claude Opus 4.6 in einer virtuellen Maschine mit Standardwerkzeugen und Fuzzern laufen. Der Beitrag hält ausdrücklich fest, man habe weder Spezialanweisungen noch ein eigenes Gerüst mitgegeben: “nor did we provide a custom harness”. /security-review kommt darin nicht vor.

Zwei Präzisierungen gehen in Nacherzählungen regelmässig verloren. Anthropic schreibt durchgehend “high-severity”, nicht “critical” - in der CVSS-Systematik ist das eine Stufe tiefer. Und als der Beitrag erschien, waren die Funde intern validiert und noch nicht von Maintainern bestätigt; das Wort CVE fällt in keiner der beiden Primärquellen.

Das prominenteste Einzelbeispiel ist ein Pufferüberlauf in der GIF-Bibliothek CGIF: Sie nimmt an, komprimierte Daten seien stets kleiner als die Rohdaten - was fast immer stimmt und sich mit einer vollen LZW-Symboltabelle brechen lässt. Der oft zitierte Satz zur Testabdeckung ist im Original ein Konjunktiv: “even if CGIF had 100% line- and branch-coverage, this vulnerability could still remain undetected”. Das ist eine Aussage über die Grenzen von Fuzzing, kein Bericht über einen Lauf, der versagt hätte. Gefunden hat das Modell die Lücke über die Annahme im Kopf des Entwicklers, nicht über ein Muster im Code.

Was ein Lauf kostet und wohin der Code geht

Mein dritter Durchlauf lief mit Kostenmessung. Für 68 geänderte Zeilen in vier Dateien fielen rechnerisch 4.23 USD an Modellkosten an, gerechnet mit Claude Opus 5, dem teuersten verfügbaren Modell. Mit einem Abo zahlen Sie das nicht separat, die Nutzung zehrt am Kontingent. Bei API-Abrechnung pro Pull Request sollten Sie die Grössenordnung trotzdem kennen. Für seinen verwalteten Code Review nennt Anthropic 15 bis 25 USD pro Review.

Wichtiger als der Preis ist für die meisten Betriebe die Frage, wohin der Code geht. Die Antwort steht in der Dokumentation: “Claude Code runs locally. To interact with the LLM, Claude Code sends data over the network. This data includes all user prompts and model outputs.” Lokal heisst also, dass das Programm auf Ihrem Rechner läuft - nicht, dass der Quellcode im Haus bleibt.

Drei Punkte gehören vor der Einführung geklärt. Die Abostufe entscheidet über das Training: Pro und Max laufen unter Konsumentenbedingungen, bei denen Anthropic mit den übermittelten Daten trainieren darf, sofern die Einstellung aktiv ist - Claude Code eingeschlossen. Kommerziell bewahrt Anthropic die Daten 30 Tage auf, bei Konsumentenkonten mit Trainingsfreigabe fünf Jahre. Und eine EU- oder Schweizer Datenregion gibt es für die Anthropic-API nicht. Details im Vergleich der Geschäftsabos von ChatGPT, Claude und Copilot und im Beitrag zum revDSG im KMU.

Ein Detail, das gern übersehen wird: Claude Code legt seine Sitzungsprotokolle im Klartext unter ~/.claude/projects/ ab, standardmässig 30 Tage lang. Was serverseitig gelöscht wird, liegt lokal weiter auf dem Gerät.

Eigene Prüfregeln hinterlegen - und die Warnung vor Prompt Injection

Firmenspezifische Prüfregeln lassen sich hinterlegen, aber nicht am eingebauten Befehl - dessen Anweisungstext steckt im Programm. Der Weg führt über das öffentliche Repository anthropics/claude-code-security-review: Dort liegt eine Datei security-review.md, die Sie nach .claude/commands/ in Ihr Projekt kopieren und dort anpassen. Für die GitHub-Action-Variante gibt es Parameter für zusätzliche Prüfkategorien, ein eigenes Filterregelwerk und ausgenommene Verzeichnisse.

Zwei Dinge aus demselben Repository gehören in jede Abwägung. Das README warnt: “This action is not hardened against prompt injection attacks and should only be used to review trusted PRs.” Eine automatische Prüfung von Beiträgen externer Mitwirkender lässt also fremden Text auf den Prüfer wirken. Und der Pflegezustand: letzter Commit am 11. Februar 2026, keine Releases, 78 offene Issues bei 5’865 Sternen (Stand 16. August 2026). Warum es stillsteht, sagt Anthropic nicht.

Wenn Sie den ganzen Bestand prüfen wollen

Für einen Betrieb, der Software entwickeln lässt, ist der Branch-Diff selten die interessante Frage. Die lautet: Was steckt in dem, was seit Jahren läuft? Dafür gibt es zwei Wege, beide geprüft.

Der offizielle Weg ist das Claude-Security-Plugin. Es wird mit /plugin install claude-security@claude-plugins-official nachgerüstet und kennt den Vollscan von Haus aus - laut Dokumentation sogar ohne Git: “Change scans need a git repository; full scans of an unversioned directory still work.” Anthropic beschreibt es als Mehr-Agenten-Scan, der die Architektur kartiert, ein Bedrohungsmodell baut und jeden Fund unabhängig gegenprüfen lässt. Es läuft lokal und zählt gegen das Nutzungskontingent; einen Preis pro Scan nennt Anthropic nicht. Voraussetzung ist ein Bezahlplan mit eingeschalteten Dynamic Workflows und Python 3.9.6.

Der Umweg funktioniert auch. Zeigt origin/HEAD auf einen leeren Wurzel-Commit, ist der Diff die gesamte Codebase. Ich habe das gegen dasselbe Testrepo laufen lassen: Der erste Befund war die SQL-Injection aus dem Basis-Commit, die vorher dreimal aussortiert worden war - diesmal mit Konfidenz 10 von 10. Insgesamt fünf Befunde statt vier, 4.08 USD, 5,6 Minuten für 89 Zeilen.

Was der Umweg nicht ändert, ist die Ausschlussliste. Auch dieser Lauf schwieg zur CVE-behafteten Abhängigkeit, zum fehlenden Rate-Limiting und zum Passwort im Betriebshandbuch. Der Trick erweitert den Eingabeumfang, nicht die Prüfkategorien - und Anthropic hält für das Plugin fest: “The plugin doesn’t replace your existing source-code security tools.”

Häufige Fragen

Ersetzt /security-review einen Sicherheitsscanner?

Nein. Der Befehl meldet ganze Klassen von Problemen bewusst nicht, darunter veraltete Abhängigkeiten mit bekannten Lücken und alles rund um Denial of Service. Anthropic verweist in der eigenen Dokumentation ausdrücklich darauf, dass statische Analyse und Dependency-Scanner im automatisierten Build weiterhin nötig sind.

Prüft der Befehl meine ganze Anwendung?

Nein, nur die Änderungen des aktuellen Branch. In meinem Test hat er eine vorbestehende Lücke dreimal erkannt und dreimal aus dem Bericht verwiesen. Für den Bestand gibt es das Claude-Security-Plugin oder den Umweg über den leeren Git-Baum - beides oben beschrieben.

Geht mein Quellcode an Anthropic?

Ja. Claude Code läuft auf dem eigenen Rechner, überträgt für die Auswertung aber sämtliche Eingaben und Ausgaben an das Modell. Ob dieser Code zum Training verwendet werden darf, hängt an der Abostufe: Team und Enterprise schliessen es vertraglich aus, Pro und Max nicht.

Was kostet ein Durchlauf?

In meinen Messungen 4.08 bis 4.23 USD rechnerische Modellkosten, gerechnet mit dem teuersten Modell. Innerhalb eines Abos zehrt das am Nutzungskontingent statt an einer eigenen Rechnung; bei API-Abrechnung ist es der reale Preis.

Praxis-Fazit

Was sich real verschiebt, ist der Zeitpunkt: Ein Sicherheitsblick, der früher am Projektende oder gar nicht stattfand, passt jetzt vor den Commit. Die drei Befunde, die in jedem Lauf kamen, und die beiden, die sich den vierten Platz teilten, hätte kein Team ignorieren wollen. Gleichzeitig ist der Bericht schmaler, als er aussieht: Er sagt nichts über Altbestand, nichts über Abhängigkeiten, nichts über das Verhalten der laufenden Anwendung, und er kann beim nächsten Durchlauf anders ausfallen.

Der brauchbare Umgang damit ist Kalibrierung statt Vertrauen. Wenn Sie diese Woche einen Schritt machen wollen: Lassen Sie /security-review einmal über einen echten Branch laufen und lesen Sie den Bericht mit der Ausschlussliste daneben. Interessanter als das, was drinsteht, ist die Frage, welche Ihrer Risiken gar nicht erst geprüft wurden.

---

Quellen (geprüft 17. August 2026):

• Automate security reviews with Claude Code - Anthropic (6. August 2025)
• Slash commands: All commands - Claude Code Docs (abgerufen 16. August 2026)
• Errors: /security-review fails without origin/HEAD - Claude Code Docs (abgerufen 16.8.2026)
• Catch security issues as Claude writes code - Claude Code Docs (abgerufen 16. August 2026)
• Automated security reviews in Claude Code - Anthropic Help Center (16. März 2026)
• Evaluating and mitigating the growing risk of LLM-discovered 0-days - Anthropic Frontier Red Team (5. Februar 2026)
• Making frontier cybersecurity capabilities available to defenders - Anthropic (20. Februar 2026)
• Project Glasswing - Anthropic (7. April 2026)
• cgif v0.5.1 Release - GitHub (19. Januar 2026)
• fix LZW data alloc size calculation, PR #84 - GitHub (19. Januar 2026)
• anthropics/claude-code-security-review - GitHub (letzter Commit 11. Februar 2026)
• Data usage - Claude Code Docs (abgerufen 16. August 2026)
• Data residency - Claude Platform Docs (abgerufen 16. August 2026)
• Code Review - Claude Code Docs (abgerufen 16. August 2026)
• Scan your codebase for vulnerabilities: Claude Security plugin - Claude Code Docs (abgerufen 17. August 2026)
• Claude Code Security vs. /security-review - StackHawk (7. Mai 2026)
• Claude Code Security: A Reasoned Take on What It Means for AppSec - Resilient Cyber (3. März 2026)