# Claude Code Sicherheitsprüfung: /security-review und GitHub Action > So prüfst du die Sicherheit eines Vibe-Projekts mit /security-review in Claude Code. Einrichtungsschritte, eine GitHub-Action-Vorlage, 6 Arten von Schwachstellen und ehrliche Grenzen. Source: https://ailoot.ai/blog/de/claude-code-security-review/ Canonical: https://ailoot.ai/blog/de/claude-code-security-review/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-1a3ccd64db434aa014dc7d772e0776d72a6ba4999bdfd42b10ca26c84721e3c3 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](https://ailoot.ai/docs/).
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Was ist /security-review in Claude Code?
Das Wichtigste in diesem Abschnitt `/security-review` ist ein integrierter Claude-Code-Befehl, der direkt im Terminal eine Sicherheitsanalyse des gesamten Projekts oder der aktuellen Änderungen durchführt. Anthropic hat ihn am 20. Februar 2026 als Teil von Claude Code Security eingeführt und für alle Pro-, Max- und API-Console-Nutzer verfügbar gemacht. Die Anfrage wird über dein reguläres Claude-API-Guthaben abgerechnet.
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.

Claude Code Security liest und analysiert deinen Code wie ein menschlicher Sicherheitsforscher: Es versteht, wie Komponenten zusammenwirken, verfolgt, wie sich Daten durch die Anwendung bewegen, und erkennt komplexe Schwachstellen, die regelbasierte Tools übersehen.

— Anthropic, https://www.anthropic.com/news/claude-code-security
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?
Das Wichtigste in diesem Abschnitt Aktualisiere Claude Code auf die neueste Version, öffne das Projekt in einem Terminal, führe `/security-review` aus, warte auf den Bericht (1 bis 5 Minuten bei einem durchschnittlichen Projekt), lies die Schweregrade und bitte Claude, Korrekturen anzuwenden. Der Befehl funktioniert mit jedem Stack: Next.js, Django, FastAPI, Rails, Go, Rust. Eine spezielle Konfiguration ist nicht erforderlich.
**Schritt 1. Claude Code aktualisieren.** Der Befehl funktioniert ab der Version vom 20. Februar 2026. ```bash claude update ``` Wenn du Claude Code über npm installiert hast, kannst du auch Folgendes ausführen: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Prüfe, ob `/security-review` verfügbar ist: ```bash claude /help | grep security ``` **Schritt 2. Projekt öffnen und bei Claude Code anmelden.** ```bash 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.
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
## Welche Schwachstellen findet /security-review?
Das Wichtigste in diesem Abschnitt Claude erkennt 6 Klassen: SQL-Injection und Injections allgemein, XSS, Probleme bei Authentifizierung und Autorisierung, Lecks sensibler Daten, Schwachstellen in Abhängigkeiten von Drittanbietern und fest codierte Geheimnisse im Code. Der Befehl kann außerdem mit über mehrere Dateien verteilter Authentifizierungslogik umgehen, was regelbasierte Scanner nicht können.
Die vollständige Liste der standardmäßig in der Analyse enthaltenen Punkte ist in der [offiziellen Dokumentation von Anthropic](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) beschrieben: | Kategorie | Wonach gesucht wird | |----|----| | **SQL-Injection** | Direkte Zeichenkettenverkettung in SQL, unsichere ORM-Aufrufe (`raw()` ohne Parameter), Prisma `$queryRawUnsafe` | | **XSS** | Ausgabe mit `dangerouslySetInnerHTML` ohne Bereinigung, Template-Systeme ohne automatisches Escaping, `innerHTML` aus Benutzereingaben | | **Authentifizierungsfehler** | Wiederverwendbare Tokens, fehlende Berechtigungsprüfungen in API-Routen, JWT ohne Ablaufdatum, Session Fixation | | **Unsichere Datenverarbeitung** | Validierung nur auf dem Client, Antworten mit zusätzlichen Feldern (Over-Fetching), Open Redirect | | **Schwachstellen in Abhängigkeiten** | Verwundbare Versionen von npm-/pip-/cargo-Paketen, geprüft mit `npm audit` und Äquivalenten | | **Geheimnisse** | Fest codierte API-Schlüssel, Tokens in `.env.example`, Passwörter im Code | 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?
Das Wichtigste in diesem Abschnitt Anthropic hat die offizielle Action `anthropics/claude-code-security-review@main` veröffentlicht. Sie wird über eine einzelne Workflow-Datei eingebunden und kommentiert automatisch inline in jedem Pull Request die gefundenen Schwachstellen. Konfiguriere `CLAUDE_API_KEY` und Workflowberechtigungen. Die offizielle Action warnt, dass sie nicht gegen Prompt-Injection gehärtet ist und vertrauenswürdige PRs prüfen soll. Prüfe vor Aktivierung Mitwirkenden- und Workflowzugriff.
**Schritt 1. API-Schlüssel erstellen.** Öffne [console.anthropic.com](https://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`: ```yaml 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?
Das Wichtigste in diesem Abschnitt Die Action hat 9 Eingaben, mit denen du ihr Verhalten für dein Projekt konfigurieren kannst. Die wichtigsten: `exclude-directories` (zum Beispiel `tests/,fixtures/`), `false-positive-filtering-instructions` (Pfad zu einer MD-Datei mit deinen Regeln nach dem Muster „Das ist keine Schwachstelle, weil …“) und `custom-security-scan-instructions` für zusätzliche domänenspezifische Prüfungen.
Vollständige Tabelle der Eingaben der GitHub Action ([Quelle: Repository-README](https://github.com/anthropics/claude-code-security-review)): | Eingabe | Standardwert | Funktion | |----|----|----| | `claude-api-key` | \- | Anthropic-API-Schlüssel. Erforderlich. | | `comment-pr` | `true` | Gibt an, ob Inline-Kommentare im PR veröffentlicht werden | | `upload-results` | `true` | Gibt an, ob das Ergebnis 90 Tage lang als Artefakt gespeichert wird | | `exclude-directories` | \- | Durch Kommas getrennte Liste: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Zu verwendendes Modell | | `claudecode-timeout` | `20` | Timeout in Minuten | | `run-every-commit` | `false` | Bei jedem Push statt nur bei PRs ausführen | | `false-positive-filtering-instructions` | \- | Pfad zu einer MD-Datei mit deinen Regeln | | `custom-security-scan-instructions` | \- | Pfad zu einer MD-Datei mit zusätzlichen Prüfungen | **Beispiel für die Konfiguration der Filterung falsch positiver Ergebnisse.** Erstelle die Datei `.claude/security/false-positives.md`: ```markdown # 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: ```yaml - 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: ```markdown # 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“](https://ailoot.ai/blog/de/claude-md-template/) und [„Das Second Brain in Claude Code“](https://ailoot.ai/blog/de/claude-code-second-brain/). ## Was erkennt Claude NICHT und warum: ehrliche Grenzen?
Das Wichtigste in diesem Abschnitt Codeprüfung allein führt die laufende Anwendung nicht durch Nutzerszenarien und bestätigt keine reale Bereitstellungsumgebung. Sie kann potenzielle Race Conditions, Geschäftslogikfehler oder Konfigurationsprobleme im Code erkennen. Stagingtests und Prüfung der tatsächlichen Bereitstellung sind nötig, um Verhalten und verbleibende Risiken zu bestätigen.
Anthropic führt klar auf, was standardmäßig deaktiviert ist und warum ([Quelle: Repository-README](https://github.com/anthropics/claude-code-security-review)): - **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
Das Wichtigste in diesem Abschnitt Ich habe `/security-review` in meinem eigenen TypeScript-Projekt mit Next.js, Prisma, PostgreSQL und Redis ausgeführt. In 4 Minuten führte der Befehl ein erstes Audit durch, lieferte mehrere gut begründete Befunde unterschiedlicher Schwere, und schließlich hatte ich die funktionierenden Korrekturen in anderthalb Stunden abgeschlossen. Das war günstiger und schneller als jeder externe Pentest.
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?
Das Wichtigste in diesem Abschnitt Führe vor wesentlichen Commits `/security-review` in der Projektsitzung aus, lies die Funde, behebe bestätigte Probleme und wiederhole passende Tests. Das ist ein Prüfverfahren, kein technisches Commitverbot.
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“](https://ailoot.ai/blog/de/claude-code-hooks/). Als Alternative kannst du mit [Routinen](https://ailoot.ai/blog/de/claude-code-routines/) 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](https://ailoot.ai/blog/de/mcp-servers-claude-code/) 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
Das Wichtigste in diesem Abschnitt 5 häufige Fragen: Was kostet der Befehl, wie oft sollte man ihn ausführen, mit welchen Stacks funktioniert er, was tun, wenn Claude diese Schwachstelle bereits gefunden hat, und ob sich der Befehl nur auf bestimmten Dateien ausführen lässt. Kurze Antworten ohne unnötige Worte.
**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
### Quellen - [Anthropic - Ankündigung zum Start von Claude Code Security](https://www.anthropic.com/news/claude-code-security) - offizielle Ankündigung vom 20. Februar 2026 - [Anthropic Help Center - Automatisierte Sicherheitsprüfungen in Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - offizielle Anleitung zur Ausführung - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - Quelle der GitHub Action mit vollständigem README - [Claude-Code-Dokumentation - Code Review](https://code.claude.com/docs/en/code-review) - allgemeine Anthropic-Dokumentation - [Anthropic Help Center - Claude Security verwenden](https://support.claude.com/en/articles/14661296-use-claude-security) - verwandte Produkte - [Port - Claude-Code-Sicherheitsprüfungen integrieren](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - Integration der Ergebnisse in ein internes Entwicklerportal - [Claude-Code-Changelog](https://code.claude.com/docs/en/changelog) - Verlauf der Befehlsveröffentlichungen
Weitere Materialien findest du in der [Ailoot-Dokumentation](https://ailoot.ai/docs/).
[Ailoot-Anleitungen](https://ailoot.ai/docs/)
[Zu Ailoot](https://ailoot.ai/)
## Fragen und Antworten ### Belegt ein leerer security-review-Bericht eine sichere Anwendung? Nein. Es ist eine erste Codeprüfung mit möglichen übersehenen Problemen und Filterung. Prüfe Korrekturen, Rollen und Gleichzeitigkeit auf Staging und kontrolliere die tatsächlich bereitgestellte Konfiguration. ### Blockiert die gezeigte GitHub Action automatisch Commits oder Merges? Der gezeigte Ablauf belegt das nicht. Er veröffentlicht PR-Funde. Prüfe sie und teste bestätigte Korrekturen. Der Artikel liefert keinen verifizierten lokalen Hook zum Blockieren von Commits. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.