Claude Code /security-review: kontrola kodu i GitHub Action

Autor oryginalnego materiału opisuje swoje doświadczenie: „Właśnie uruchomiłem security-review we własnym projekcie vibe, a zespół w 4 minuty znalazł kilka rzeczywistych problemów, które zostały już naprawione”. Ta sama praca zajmowała wcześniej cały dzień zewnętrznemu konsultantowi.

Dodatkowe materiały dotyczące konfiguracji narzędzi znajdziesz w dokumentacji Ailoot.

Czym jest /security-review w Claude Code?#

Polecenie działa w dwóch trybach. Lokalnie: uruchom /security-review w terminalu, a Claude odczyta repozytorium i przygotuje raport. Po stronie serwera: ten sam silnik można skonfigurować jako GitHub Action, która automatycznie dodaje komentarze w kodzie do każdego Pull Requesta.

W przeciwieństwie do klasycznych skanerów SAST (Snyk Code, Semgrep, SonarQube), /security-review nie działa na podstawie stałych reguł. Czyta kod jak pracujący inżynier: śledzi przepływ danych, rozumie, z jakiego frameworka korzystasz i gdzie przebiegają granice zaufania, a także wykrywa luki, których nie opisuje żadna reguła.

Nie oznacza to, że /security-review zastępuje zewnętrzny pentest lub testy na działającym środowisku stagingowym. Może zautomatyzować część wstępnego przeglądu kodu, ale artykuł nie mierzy odsetka pokrycia audytu. Poniżej wyjaśnię, jak uruchomić je prawidłowo i co Claude znajdzie w twoim projekcie.

Jak uruchomić /security-review w 5 krokach?#

Krok 1. Zaktualizuj Claude Code. Polecenie działa od wydania z 20 lutego 2026 roku.

claude update

Jeśli Claude Code został zainstalowany przez npm, możesz też wykonać:

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

Sprawdź, czy pojawiło się /security-review:

claude /help | grep security

Krok 2. Otwórz projekt i zaloguj się do Claude Code.

cd ~/projects/my-vibe-project
claude

Krok 3. Uruchom polecenie. W Claude Code po prostu wpisz:

/security-review

Claude automatycznie przeprowadza 3 fazy analizy:

1. Badanie kontekstu repozytorium - odczytuje strukturę i identyfikuje stos, trasy oraz zapytania do bazy danych.
2. Analiza porównawcza - porównuje bieżący stan z typowymi wzorcami luk dla tego stosu.
3. Ocena luk - wylicza wszystkie podejrzane przypadki i przypisuje im poziom pewności w skali od 1 do 10. W raporcie uwzględniane są tylko ustalenia z poziomem pewności ≥ 8.

Krok 4. Przeczytaj raport. Wynik ma postać tabeli Markdown. Dla każdego problemu Claude podaje:

• Plik i numer wiersza (na przykład src/auth/login.ts:42)
• Ważność (HIGH / MEDIUM / LOW)
• Kategoria (sql_injection, xss, auth_bypass, insecure_storage)
• Opis - na czym polega problem
• Scenariusz wykorzystania - jak może użyć go atakujący
• Zalecenie - jak go naprawić

Krok 5. Poproś o zastosowanie poprawek. Następnie możesz pracować z Claude jak ze zwykłym agentem:

„Zastosuj poprawki o poziomie HIGH z raportu, po jednej naraz, wraz z opisem PR.”

Claude otworzy każdy plik i zaproponuje zmianę; ty ją zatwierdzisz. W prawdziwym projekcie zamknąłem 5 ustaleń w 40 minut zamiast planowanych 3 godzin.

Jakie luki wykrywa /security-review?#

Pełna lista elementów domyślnie uwzględnianych w analizie znajduje się w oficjalnej dokumentacji Anthropic:

Dodatkowo polecenie obejmuje kategorie rzadko wykrywane przez skanery automatyczne:

• Command injection - wykonywanie danych użytkownika w powłoce (child_process.exec(userInput))
• Path traversal - ładowanie pliku przez ../../etc/passwd
• XXE - XML z zewnętrznymi encjami
• Template injection - SSTI w Jinja/Handlebars/EJS
• NoSQL injection - operatory $ne, $gt w zapytaniach MongoDB
• Niewłaściwe użycie kryptografii - używanie MD5, trybu ECB, statycznego IV

Claude przypisuje każdemu ustaleniu poziom ważności. Skala jest prosta:

• HIGH - zdalne wykorzystanie bez uwierzytelnienia, wyciek danych dotyczący wszystkich użytkowników
• MEDIUM - wykorzystanie wymagające dodatkowych warunków (wymagana sesja / określone dane wejściowe)
• LOW - potencjalny wektor ataku, obecnie niekrytyczny, ale wart naprawienia

Warto wiedzieć: w standardowej konfiguracji Claude nie zgłasza DoS, ograniczania liczby żądań, wyczerpania pamięci, otwartych przekierowań bez potwierdzonego wpływu, wstrzyknięć wyrażeń regularnych / ReDoS ani fałszowania logów. To celowe działanie, dzięki któremu raport nie jest zalewany szumem. Jeśli te klasy mają znaczenie, rozszerz reguły (zobacz sekcję o filtrowaniu fałszywych alarmów poniżej).

Jak skonfigurować GitHub Action do automatycznego przeglądu?#

Krok 1. Uzyskaj klucz API. Przejdź do console.anthropic.com, utwórz klucz API i skopiuj go.

Krok 2. Dodaj klucz do sekretów repozytorium. W GitHub przejdź do: Settings → Secrets and variables → Actions → New repository secret. Ustaw nazwę CLAUDE_API_KEY, a jako wartość wpisz swój klucz.

Krok 3. Utwórz plik workflow. Zapisz go jako .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 }}

Krok 4. Scal gałąź z main. Akcja uruchomi się automatycznie przy następnym PR.

Co robi akcja:

• Uruchamia się przy każdym otwartym Pull Requeście i każdej jego synchronizacji.
• Pobiera różnicę między gałęzią PR a main.
• Uruchamia ten sam silnik co lokalne /security-review.
• Publikuje komentarze bezpośrednio w wierszach kodu z podejrzanym elementem.
• Powiela pełny raport w Job Summary.

Ważne szczegóły w permissions:

• pull-requests: write - umożliwia publikowanie komentarzy w kodzie.
• contents: read - umożliwia odczyt kodu. Brak write. Akcja sama nie modyfikuje kodu; tylko raportuje.

Ten zestaw wystarcza dla prywatnego repozytorium. W publicznym repozytorium możesz dodatkowo ustawić actions: read, jeśli korzystasz z wielokrotnego użytku workflow.

Jak filtrować fałszywe alarmy i zmienić czułość?#

Pełna tabela parametrów wejściowych GitHub Action (źródło: README repozytorium):

Przykład konfiguracji filtrowania fałszywych alarmów. Utwórz plik .claude/security/false-positives.md:

# Zasady filtrowania fałszywych alarmów w naszym projekcie

- Każde użycie `dangerouslySetInnerHTML` w `src/lib/email/layout.ts` jest bezpieczne —
  kod HTML powstaje z zaufanych szablonów i przechodzi przez `sanitize-html`
  podczas zapisu w bazie danych, a nie podczas renderowania.
- Nie zgłaszaj zakodowanych na stałe testowych kluczy API w `__tests__/fixtures/*.ts`.
  Wszystkie klucze zaczynają się od `sk-test-fake-`.
- Łączenie ciągów SQL w `src/lib/admin/migrations.ts` jest dopuszczalne — ten plik jest uruchamiany
  wyłącznie jako root, a dane wejściowe pochodzą ze zmiennych środowiskowych.

Podłącz go w workflow:

- 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

Niestandardowe instrukcje skanowania bezpieczeństwa konfiguruje się podobnie. Utwórz plik z regułami szczególnie ważnymi w twoim projekcie:

# Dodatkowe kontrole w naszym projekcie

- Każdy endpoint pod `/api/admin/*` musi sprawdzać rolę administratora
  za pośrednictwem współdzielonego wrappera. Bez tego wrappera poziom ważności wynosi HIGH.
- Wszystkie webhooki YooKassa / CloudPayments muszą weryfikować podpis przed
  parsowaniem treści żądania. Bez tego poziom ważności wynosi HIGH.
- Tokeny magic link muszą być jednorazowe (oznaczane jako użyte po
  pierwszym prawidłowym żądaniu). Wielokrotnego użytku tokeny mają poziom ważności MEDIUM.

To już nie jest gotowe ustawienie Anthropic — przenosisz swoją wiedzę o projekcie do reguł stosowanych przez Claude przy każdym uruchomieniu. Na tym polega „metodologia ponad modelem”.

Więcej o metodologii kontekstu dla Claude znajdziesz w poradnikach „Jak skonfigurować CLAUDE.md” i „Second Brain w Claude Code”.

Czego Claude NIE wykryje i dlaczego: uczciwe ograniczenia#

Anthropic jasno wylicza, co jest domyślnie wyłączone i dlaczego (źródło: README repozytorium):

• Odmowa usługi - za dużo szumu, a wpływ niemal zawsze jest niewielki.
• Problemy z limitowaniem liczby żądań - rozwiązuje się je na poziomie infrastruktury, a nie kodu.
• Wyczerpanie pamięci / CPU - z tego samego powodu.
• Ogólna walidacja danych wejściowych bez potwierdzonego wpływu - walidowanie każdego pola tworzy lawinę fałszywych alarmów.
• Otwarte przekierowanie - często jest zamierzonym działaniem.

Czego sam przegląd kodu nie może w pełni sprawdzić bez dowodów z działania lub wdrożenia:

• Konfiguracji serwera produkcyjnego. Nagłówków NGINX, zasad CORS, ustawień TLS, portów nasłuchujących. Trzeba je sprawdzać ręcznie w środowisku stagingowym.
• Wyścigów. Na przykład podwójnego wydania środków podczas jednoczesnych żądań zwrotu. Analiza statyczna może wskazać podejrzane wzorce, ale współbieżne zachowanie nadal wymaga testu.
• Błędów logiki biznesowej płatności. Jeśli suma zamówienia jest obliczana po stronie klienta i po prostu wysyłana do dostawcy płatności, ma to poziom HIGH, ale bez wyraźnego kontekstu dotyczącego oczekiwanego działania płatności Claude nie zawsze rozpoznaje ten wzorzec.
• IDOR na poziomie bazy danych. Jeśli zapytanie SELECT * FROM orders WHERE id = $1 nie sprawdza WHERE user_id = $session.userId, Claude często to wykrywa. Jeśli jednak kontrola jest zaimplementowana przez middleware ORM, a Claude nie widzi pełnego przepływu danych, może ją przeoczyć.
• Odporności na inżynierię społeczną / phishing. Nie ma to związku z kodem.

Używaj /security-review jako wstępnego przeglądu statycznego. Następnie wykonaj testy dynamiczne na stagingu, sprawdzenia ról i uprawnień, właściwe kontrole SAST oraz przegląd faktycznie wdrożonej konfiguracji. Nie ustalono tutaj zmierzonego procentu pokrycia.

Zakres i termin zewnętrznej oceny dobierz do ryzyk i zmian systemu. Ani jedno polecenie, ani okresowy zewnętrzny audyt nie ustalają 100% pokrycia bezpieczeństwa.

Jak autor oryginalnego materiału przeprowadził przegląd bezpieczeństwa projektu vibe#

Co wyszło? Typowy obraz przeciętnego projektu vibe na etapie „działa w produkcji, ale nie został sprawdzony”: kilka podejrzeń dotyczących przepływu uwierzytelniania, logiki obsługi webhooków integracji płatności, obsługi przesyłania plików oraz kilka konkretnych uwag o obsłudze HTML podczas renderowania. Nie opisuję publicznie szczegółów; niektóre zalecenia zostały już wdrożone, a inne nadal są w PR. W opisanym projekcie wstępne skanowanie było przydatne i szybkie; nie ustala to procentu pokrycia audytu ani ogólnego czasu ukończenia.

Co odrzuciłem jako fałszywe alarmy:

• Ustalenia o DoS przez wyrażenia regularne używane do walidacji danych wejściowych - rzeczywiste obciążenie nie trafia w te wyrażenia.
• Jedno ustalenie dotyczące zakodowanego na stałe klucza API - był to testowy klucz z jawnym prefiksem fake- w plikach fixtures.

Ile to trwało? Samo uruchomienie zajęło 4 minuty. Przejrzenie raportu - 25 minut. Wprowadzenie poprawek wraz z testami - około godziny. Łącznie od „zaczynam” do „wszystko jest na main” minęło około półtorej godziny. Zewnętrzny pentest tego samego zakresu trwa tydzień kalendarzowy i kosztuje dziesiątki razy więcej.

Najważniejszy wniosek. /security-review nie zastępuje zewnętrznego pentestu. Może wskazać użyteczne problemy na poziomie kodu, jak w opisanym czterominutowym skanowaniu autora. Przejrzyj poprawki i przetestuj je, a następnie osobno sprawdź działanie i wdrożoną konfigurację; skan nie eliminuje ryzyka bezpieczeństwa projektu.

Jak włączyć /security-review do rutyny przed commitem?#

Pokazany wcześniej hook z git_commit, --severity HIGH i --fail-on-find nie jest udokumentowaną działającą receptą i nie może służyć jako bramka bezpieczeństwa. Artykuł nie dostarcza sprawdzonego lokalnego hooka blokującego commity. Oficjalna GitHub Action pokazana wyżej automatycznie zgłasza ustalenia PR; sam komentarz do PR nie dowodzi blokowania commitów lub scaleń.

Pełne wyjaśnienie hooków znajdziesz w poradniku „Hooki w Claude Code”.

Alternatywnie możesz użyć routines i utworzyć rutynę pre-deploy-check, która jednym poleceniem uruchomi /security-review + npm run build + npm run test. Dodatkowe materiały znajdziesz w dokumentacji Ailoot.

Jeśli korzystasz z serwerów MCP, możesz zintegrować ustalenia z /security-review z systemem obsługi incydentów (Sentry, Linear, Notion), aby każde ustalenie HIGH automatycznie stawało się zgłoszeniem.

FAQ dotyczące /security-review#

Ile kosztuje jedno uruchomienie? Zależy od wielkości projektu. W moim projekcie liczącym 30K wierszy jedno uruchomienie zużywa około $0.30-0.50 z salda API. Duże repozytorium korporacyjne z milionem wierszy kosztuje do $5-8 za uruchomienie. To dziesiątki razy mniej niż subskrypcja dowolnego skanera SaaS.

Jak często uruchamiać je lokalnie? Co najmniej przed każdym wydaniem na produkcję. Rozważ też przegląd przed istotnymi commitami i PR. Artykuł nie dostarcza sprawdzonego automatycznego hooka blokującego commit.

Z jakimi stosami działa? Z każdym, który Claude potrafi odczytać. Według obserwacji autora sprawdzono już: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Jakość jest niższa w przypadku bardzo egzotycznych języków (Erlang, Elixir, Clojure), ale narzędzie i tak coś znajdzie.

Co zrobić, jeśli Claude za każdym razem znajduje tę samą „lukę”, choć w rzeczywistości nią nie jest? Dodaj ją do false-positive-filtering-instructions wraz z wyjaśnieniem, „dlaczego jest bezpieczna”. Claude przestanie zgłaszać ją w kolejnych uruchomieniach.

Czy można uruchomić je tylko dla wybranych plików? Lokalnie tak: po prostu uruchom /security-review src/lib/auth/*.ts. GitHub Action sprawdza tylko bieżącą różnicę PR, co zwykle oznacza właśnie „wybrane pliki”.

Źródła#

Dodatkowe materiały znajdziesz w dokumentacji Ailoot.