Claude Code Sicherheitsprüfung: /security-review und GitHub Action

Der Autor des Originalmaterials beschreibt seine Erfahrung: „Ich habe security-review in meinem eigenen Vibe-Projekt ausgeführt, und das Team hat in 4 Minuten mehrere echte Probleme gefunden, die inzwischen behoben sind.“ Für dieselbe Arbeit hätte ein externer Berater früher einen ganzen Tag gebraucht.

Weitere Materialien zur Konfiguration von Tools findest du in der Ailoot-Dokumentation.

Was ist /security-review in Claude Code?#

Der Befehl funktioniert in zwei Modi. Lokal: Führe /security-review im Terminal aus, und Claude liest das Repository und erstellt einen Bericht. Serverseitig: Dieselbe Engine wird als GitHub Action installiert und kommentiert automatisch inline in jedem Pull Request.

Im Gegensatz zu klassischen SAST-Scannern (Snyk Code, Semgrep, SonarQube) arbeitet /security-review nicht mit festen Regeln. Es liest den Code wie ein aktiver Entwickler: Es verfolgt den Datenfluss, versteht, welches Framework du verwendest und wo die Vertrauensgrenzen liegen, und erkennt Schwachstellen, die keine Regel beschreibt.

Das bedeutet nicht, dass /security-review einen externen Pentest oder Live-Tests in einer Staging-Umgebung ersetzt. Der Befehl kann Teile einer ersten Codeprüfung automatisieren. Welcher Anteil eines Audits abgedeckt wird, misst dieser Artikel nicht. Im Folgenden erkläre ich, wie du den Befehl richtig ausführst und was Claude in deinem Projekt findet.

Wie führst du /security-review in 5 Schritten aus?#

Schritt 1. Claude Code aktualisieren. Der Befehl funktioniert ab der Version vom 20. Februar 2026.

claude update

Wenn du Claude Code über npm installiert hast, kannst du auch Folgendes ausführen:

npm install -g @anthropic-ai/claude-code@latest

Prüfe, ob /security-review verfügbar ist:

claude /help | grep security

Schritt 2. Projekt öffnen und bei Claude Code anmelden.

cd ~/projects/my-vibe-project
claude

Schritt 3. Befehl ausführen. Gib in Claude Code einfach Folgendes ein:

/security-review

Claude durchläuft automatisch 3 Analysephasen:

1. Recherche zum Repository-Kontext - liest die Struktur und identifiziert den Stack, Routen und Datenbankabfragen.
2. Vergleichende Analyse - vergleicht den aktuellen Stand mit typischen Schwachstellenmustern für diesen Stack.
3. Schwachstellenbewertung - listet jeden Verdacht mit einem Konfidenzwert auf einer Skala von 1-10. Nur Befunde mit einer Konfidenz ≥ 8 werden in den Bericht aufgenommen.

Schritt 4. Bericht lesen. Das Ausgabeformat ist eine Markdown-Tabelle. Für jedes Problem nennt Claude:

• Datei und Zeilennummer (zum Beispiel src/auth/login.ts:42)
• Schweregrad (HIGH / MEDIUM / LOW)
• Kategorie (sql_injection, xss, auth_bypass, insecure_storage)
• Beschreibung - was nicht stimmt
• Angriffsszenario - wie ein Angreifer das Problem ausnutzen könnte
• Empfehlung - wie es behoben werden kann

Schritt 5. Claude bitten, Korrekturen anzuwenden. Danach kannst du mit Claude wie mit einem gewöhnlichen Agenten arbeiten:

„Wende die Korrekturen mit hoher Schwere aus dem Bericht nacheinander an und erstelle eine PR-Beschreibung.“

Claude öffnet jede Datei und schlägt eine Änderung vor; du bestätigst sie. In einem echten Projekt habe ich 5 Befunde in 40 Minuten behoben, statt der geplanten 3 Stunden.

Welche Schwachstellen findet /security-review?#

Die vollständige Liste der standardmäßig in der Analyse enthaltenen Punkte ist in der offiziellen Dokumentation von Anthropic beschrieben:

Außerdem deckt der Befehl Kategorien ab, die automatisierte Scanner selten erfassen:

• Befehlsinjektion - Ausführen von Benutzereingaben in einer Shell (child_process.exec(userInput))
• Pfad-Traversal - Laden einer Datei über ../../etc/passwd
• XXE - XML mit externen Entitäten
• Template-Injection - SSTI in Jinja/Handlebars/EJS
• NoSQL-Injection - Operatoren wie $ne, $gt in MongoDB-Abfragen
• Falsche Kryptografie-Verwendung - Verwendung von MD5, ECB-Modus oder einer statischen IV

Claude gibt jedem Befund einen Schweregrad. Die Skala ist einfach:

• HIGH - Remote-Ausnutzung ohne Authentifizierung, Datenleck mit Auswirkungen auf alle Nutzer
• MEDIUM - Ausnutzung unter zusätzlichen Bedingungen (eine Sitzung ist erforderlich / eine bestimmte Eingabe)
• LOW - ein potenzieller Angriffsvektor, derzeit nicht kritisch, aber eine Behebung ist sinnvoll

Gut zu wissen: In der Standardkonfiguration meldet Claude keine DoS, Probleme mit Rate-Limiting, Speichererschöpfung, Open Redirects ohne nachgewiesene Auswirkungen, Regex-Injection / ReDoS oder Log-Spoofing. Das ist beabsichtigt, damit du nicht mit Meldungen überflutet wirst. Wenn diese Klassen wichtig sind, erweitere die Regeln (siehe den Abschnitt zur Filterung falsch positiver Ergebnisse weiter unten).

Wie richtest du eine GitHub Action für automatische Prüfungen ein?#

Schritt 1. API-Schlüssel erstellen. Öffne console.anthropic.com, erstelle einen API-Schlüssel und kopiere ihn.

Schritt 2. Schlüssel in den Repository-Secrets hinterlegen. In GitHub: Settings → Secrets and variables → Actions → New repository secret. Nenne ihn CLAUDE_API_KEY; als Wert verwendest du deinen Schlüssel.

Schritt 3. Workflow-Datei erstellen. Speichere sie unter .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Schritt 4. Branch in main mergen. Die Action startet automatisch mit dem nächsten PR.

Was die Action macht:

• Wird bei jedem geöffneten oder synchronisierten Pull Request ausgeführt.
• Ermittelt den Diff zwischen dem PR-Branch und main.
• Verwendet dieselbe Engine wie das lokale /security-review.
• Veröffentlicht Inline-Kommentare direkt an den Codezeilen mit einem Verdacht.
• Stellt den vollständigen Bericht zusätzlich in der Job Summary bereit.

Wichtige Details zu permissions:

• pull-requests: write - zum Veröffentlichen von Inline-Kommentaren.
• contents: read - zum Lesen des Codes. Kein write. Die Action ändert den Code nicht selbst, sondern erstellt nur einen Bericht.

Diese Berechtigungen reichen für ein privates Repository aus. Bei einem öffentlichen Repository kannst du zusätzlich actions: read angeben, wenn du wiederverwendbare Workflows verwendest.

Wie filterst du falsch positive Ergebnisse und änderst die Empfindlichkeit?#

Vollständige Tabelle der Eingaben der GitHub Action (Quelle: Repository-README):

Beispiel für die Konfiguration der Filterung falsch positiver Ergebnisse. Erstelle die Datei .claude/security/false-positives.md:

# Regeln zur Filterung falsch positiver Ergebnisse für unser Projekt

- Jedes `dangerouslySetInnerHTML` in `src/lib/email/layout.ts` ist sicher –
  das HTML wird aus vertrauenswürdigen Vorlagen zusammengesetzt und beim Schreiben
  in die Datenbank durch `sanitize-html` geleitet, nicht beim Rendern.
- Melde keine fest codierten Test-API-Schlüssel in `__tests__/fixtures/*.ts`.
  Alle Schlüssel beginnen mit `sk-test-fake-`.
- SQL-Verkettungen in `src/lib/admin/migrations.ts` sind zulässig – die Datei wird
  nur als root ausgeführt, und Eingabedaten stammen aus Umgebungsvariablen.

Binde die Datei im Workflow ein:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

Benutzerdefinierte Anweisungen für Sicherheitsprüfungen funktionieren ähnlich. Erstelle eine Datei mit Regeln, die speziell für dein Projekt wichtig sind:

# Zusätzliche Prüfungen für unser Projekt

- Jeder Endpunkt unter `/api/admin/*` muss die Administratorrolle
  über einen gemeinsamen Wrapper prüfen. Ohne diesen Wrapper ist die Schwere HIGH.
- Alle YooKassa- / CloudPayments-Webhooks müssen die Signatur prüfen, bevor
  der Body geparst wird. Ohne diese Prüfung ist die Schwere HIGH.
- Magic-Link-Tokens müssen nur einmal verwendbar sein (nach
  der ersten gültigen Anfrage als verwendet markiert). Wiederverwendbare Tokens haben die Schwere MEDIUM.

Das ist kein Anthropic-Preset mehr: Du überträgst dein Fachwissen über das Projekt in Regeln, die Claude jedes Mal anwendet. Das ist das Wesen von „Methodik vor Modell“.

Weitere Informationen zur Kontextmethodik für Claude findest du in den Anleitungen „CLAUDE.md konfigurieren“ und „Das Second Brain in Claude Code“.

Was erkennt Claude NICHT und warum: ehrliche Grenzen?#

Anthropic führt klar auf, was standardmäßig deaktiviert ist und warum (Quelle: Repository-README):

• Denial of Service - zu viele Meldungen, fast immer mit geringen Auswirkungen.
• Rate-Limiting-Probleme - werden auf Infrastrukturebene behandelt, nicht im Code.
• Erschöpfung von Speicher / CPU - ebenso.
• Allgemeine Eingabevalidierung ohne nachgewiesene Auswirkungen - die Validierung jedes Feldes erzeugt eine Flut falsch positiver Ergebnisse.
• Open Redirect - häufig beabsichtigtes Verhalten.

Was Codeprüfung allein ohne Laufzeit- oder Bereitstellungsnachweise nicht vollständig verifizieren kann:

• Produktionsserverkonfiguration. NGINX-Header, CORS-Richtlinien, TLS-Einstellungen, lauschende Ports. Diese müssen manuell in einer Staging-Umgebung geprüft werden.
• Race Conditions. Zum Beispiel doppelte Ausgaben bei gleichzeitigen Rückerstattungsanfragen. Statische Analyse kann verdächtige Muster markieren; gleichzeitiges Verhalten muss weiterhin getestet werden.
• Fehler in der Zahlungslogik. Wenn die Bestellsumme auf dem Client berechnet und einfach an den Zahlungsanbieter gesendet wird, ist das ein Problem mit Schwere HIGH. Claude erkennt dieses Muster jedoch nicht immer, wenn ihm der Kontext fehlt, wie die Zahlungsabwicklung funktionieren soll.
• IDOR auf Datenbankebene. Wenn die Abfrage SELECT * FROM orders WHERE id = $1 keine Prüfung mit WHERE user_id = $session.userId enthält, erkennt Claude das oft. Ist die Prüfung jedoch über ORM-Middleware implementiert und kann Claude den vollständigen Datenfluss nicht sehen, übersieht der Befehl den Fehler möglicherweise.
• Widerstandsfähigkeit gegen Social Engineering / Phishing. Das hat nichts mit Code zu tun.

Nutze /security-review als erste statische Prüfung. Ergänze dynamische Stagingtests, Rollen- und Berechtigungsprüfungen, passende SAST-Kontrollen und die Prüfung der tatsächlich bereitgestellten Konfiguration. Eine gemessene Abdeckungsquote ist hier nicht belegt.

Lege Umfang und Zeitpunkt externer Prüfungen nach Systemrisiken und Änderungen fest. Weder ein einzelner Befehl noch ein regelmäßiges externes Audit belegt 100 % Sicherheitsabdeckung.

Wie der Autor des Originalmaterials eine Sicherheitsprüfung für ein Vibe-Projekt durchgeführt hat#

Was dabei herauskam. Ein typisches Bild für ein durchschnittliches Vibe-Projekt in der Phase „läuft in Produktion, wurde aber noch nicht geprüft“: mehrere Verdachtsfälle beim Auth-Flow, bei der Verarbeitung von Webhooks aus der Zahlungsintegration, bei der Dateiupload-Verarbeitung sowie einige konkrete Hinweise zur HTML-Verarbeitung beim Rendern. Ich beschreibe die Details nicht öffentlich; einige Empfehlungen wurden bereits umgesetzt, andere sind noch in PRs. Im beschriebenen Projekt war der erste Scan nützlich und schnell. Daraus folgt weder eine Audit-Abdeckungsquote noch eine allgemeine Abschlusszeit.

Was ich als falsch positive Ergebnisse verworfen habe:

• Befunde zu DoS durch Regexe in der Eingabevalidierung - die tatsächliche Last trifft diese Regexe nicht.
• Ein Befund zu einem fest codierten API-Schlüssel - es war ein Testschlüssel mit explizitem fake--Präfix in Fixtures.

Wie lange es gedauert hat. Der Lauf selbst dauerte 4 Minuten. Das Prüfen des Berichts dauerte 25 Minuten. Die Korrekturen mit Tests anzuwenden dauerte etwa eine Stunde. Insgesamt: ungefähr anderthalb Stunden von „losgelegt“ bis „alles in main“. Ein externer Pentest für denselben Umfang dauert eine Kalenderwoche und kostet ein Vielfaches.

Wichtigste Erkenntnis. /security-review ersetzt keinen externen Pentest. Er kann nützliche Codefunde liefern, wie beim beschriebenen Vier-Minuten-Scan des Autors. Prüfe und teste Korrekturen und kontrolliere Laufzeitverhalten und tatsächliche Konfiguration separat. Der Scan beseitigt nicht das Sicherheitsrisiko des Projekts.

Wie integrierst du /security-review in deine Pre-Commit-Routine?#

Der frühere Hook mit git_commit, --severity HIGH und --fail-on-find ist kein dokumentiertes funktionierendes Rezept und darf nicht als Sicherheitsbarriere dienen. Dieser Artikel liefert keinen verifizierten lokalen Hook zum Blockieren von Commits. Die oben gezeigte offizielle GitHub Action liefert automatische PR-Funde. Kommentare im PR belegen keine Blockade von Commits oder Merges.

Eine vollständige Erklärung der Hooks findest du in der Anleitung „Hooks in Claude Code“.

Als Alternative kannst du mit Routinen eine pre-deploy-check-Routine erstellen, die /security-review + npm run build + npm run test mit einem Befehl ausführt. Weitere Materialien findest du in der Ailoot-Dokumentation.

Wenn du MCP-Server verwendest, kannst du Befunde aus /security-review in ein Incident-System (Sentry, Linear, Notion) integrieren, sodass jeder Befund mit Schwere HIGH automatisch zu einem Ticket wird.

FAQ zu /security-review#

Was kostet ein einzelner Lauf? Das hängt von der Projektgröße ab. Bei meinen 30K Zeilen verbraucht ein Lauf etwa $0.30-0.50 an API-Guthaben. Ein großes Enterprise-Repository mit einer Million Zeilen kostet bis zu $5-8 pro Lauf. Das ist um ein Vielfaches günstiger als jedes SaaS-Scanner-Abo.

Wie oft sollte ich den Befehl lokal ausführen? Mindestens vor jeder Produktionsfreigabe. Ziehe ihn auch vor wesentlichen Commits und PRs in Betracht. Ein verifizierter automatisch blockierender Commit-Hook wird hier nicht bereitgestellt.

Mit welchen Stacks funktioniert der Befehl? Mit jedem, den Claude lesen kann. Nach den Beobachtungen des Autors wurden folgende geprüft: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Bei sehr exotischen Sprachen (Erlang, Elixir, Clojure) ist die Qualität geringer, aber der Befehl wird etwas finden.

Was soll ich tun, wenn Claude jedes Mal dieselbe „Schwachstelle“ findet, obwohl es keine ist? Füge sie mit einer Erklärung, „warum das sicher ist“, zu false-positive-filtering-instructions hinzu. Claude wird sie bei künftigen Läufen nicht mehr melden.

Kann ich den Befehl nur auf bestimmten Dateien ausführen? Lokal ja: Führe einfach /security-review src/lib/auth/*.ts aus. In der GitHub Action wird nur der aktuelle PR-Diff geprüft, was normalerweise mit „bestimmten Dateien“ gemeint ist.

Quellen#

Weitere Materialien findest du in der Ailoot-Dokumentation.