Claude Code security-review: kontrola kódu a GitHub Action

Autor původního materiálu popisuje svou zkušenost: „Právě jsem spustil security-review na vlastním vibe projektu a tým za 4 minuty našel několik skutečných problémů, které už byly opraveny.“ Stejná práce dříve zabrala externímu konzultantovi celý den.

Další materiály o konfiguraci nástrojů najdete v dokumentaci Ailoot.

Co je /security-review v Claude Code?#

Příkaz funguje ve dvou režimech. Lokálně: spusťte v terminálu /security-review a Claude přečte repozitář a vytvoří zprávu. Na straně serveru: stejný engine se nainstaluje jako GitHub Action a automaticky přidává komentáře přímo do každého Pull Requestu.

Na rozdíl od klasických SAST skenerů (Snyk Code, Semgrep, SonarQube) /security-review nepracuje s pevně danými pravidly. Čte kód jako živý inženýr: sleduje tok dat, rozumí tomu, jaký framework používáte a kde leží hranice důvěry, a odhaluje zranitelnosti, které žádné pravidlo nepopisuje.

To neznamená, že /security-review nahrazuje externí penetrační test nebo živé testování ve stagingovém prostředí. Může automatizovat část úvodní revize, článek ale neměří podíl pokrytí auditu. Níže vysvětlím, jak jej správně spustit a co Claude ve vašem projektu najde.

Jak v Claude Code spustit /security-review?#

Krok 1. Aktualizujte Claude Code. Příkaz funguje od vydání z 20. února 2026.

claude update

Pokud jste Claude Code nainstalovali přes npm, můžete použít také tento příkaz:

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

Zkontrolujte, že se objevil /security-review:

claude /help | grep security

Krok 2. Otevřete projekt a přihlaste se do Claude Code.

cd ~/projects/my-vibe-project
claude

Krok 3. Spusťte příkaz. V Claude Code jednoduše zadejte:

/security-review

Claude automaticky provede 3 fáze analýzy:

1. Průzkum kontextu repozitáře - přečte strukturu a určí stack, routy a databázové dotazy.
2. Srovnávací analýza - porovná aktuální stav s typickými vzorci zranitelností pro tento stack.
3. Posouzení zranitelností - vypíše každé podezření spolu se stupněm jistoty na škále od 1 do 10. Do zprávy se zahrnou pouze nálezy se stupněm jistoty ≥ 8.

Krok 4. Přečtěte si zprávu. Výstupem je tabulka v Markdownu. U každého problému Claude uvede:

• Soubor a číslo řádku (například src/auth/login.ts:42)
• Závažnost (HIGH / MEDIUM / LOW)
• Kategorie (sql_injection, xss, auth_bypass, insecure_storage)
• Popis - co je špatně
• Scénář zneužití - jak by toho mohl útočník využít
• Doporučení - jak problém opravit

Krok 5. Požádejte o provedení oprav. Potom s ním můžete pracovat jako s běžným agentem:

„Proveď opravy nálezů se závažností HIGH ze zprávy, jeden po druhém, a ke každému přidej popis PR.“

Claude otevře každý soubor a navrhne změnu; vy ji potvrdíte. Na skutečném projektu jsem za 40 minut uzavřel 5 nálezů namísto plánovaných 3 hodin.

Jaké zranitelnosti /security-review najde?#

Úplný seznam toho, co je ve výchozím nastavení zahrnuto do analýzy, popisuje oficiální dokumentace Anthropic:

Příkaz navíc pokrývá kategorie, které automatizované skenery kontrolují jen zřídka:

• Command injection - spuštění uživatelského vstupu v shellu (child_process.exec(userInput))
• Path traversal - načtení souboru přes ../../etc/passwd
• XXE - XML s externími entitami
• Template injection - SSTI v Jinja/Handlebars/EJS
• NoSQL injection - operátory $ne, $gt v dotazech MongoDB
• Zneužití kryptografie - použití MD5, režimu ECB nebo statického IV

Claude každému nálezu přiřadí závažnost. Stupnice je jednoduchá:

• HIGH - vzdálené zneužití bez autentizace, únik dat ovlivňující všechny uživatele
• MEDIUM - zneužití za dalších podmínek (je potřeba relace / konkrétní vstup)
• LOW - potenciální vektor, který nyní není kritický, ale stojí za opravu

Je dobré vědět: ve standardní konfiguraci Claude nehlásí DoS, omezení počtu požadavků, vyčerpání paměti, přesměrování bez prokázaného dopadu, injekce regulárních výrazů / ReDoS ani podvržení logů. Je to záměr, aby vás nezaplavoval šumem. Pokud jsou tyto třídy důležité, rozšiřte pravidla (viz níže část o filtrování falešně pozitivních nálezů).

Jak nastavit GitHub Action pro automatickou kontrolu?#

Krok 1. Získejte API klíč. Přejděte na console.anthropic.com, vytvořte API klíč a zkopírujte ho.

Krok 2. Uložte klíč do tajných údajů repozitáře. V GitHubu: Settings → Secrets and variables → Actions → New repository secret. Jako název zadejte CLAUDE_API_KEY; hodnotou bude váš klíč.

Krok 3. Vytvořte soubor workflow. Uložte jej 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. Sloučte větev do main. Akce se automaticky spustí při dalším PR.

Co akce dělá:

• Spouští se při každém otevřeném Pull Requestu nebo synchronizaci jeho změn.
• Zjišťuje rozdíl mezi větví PR a větví main.
• Spouští stejný engine jako lokální /security-review.
• Přidává komentáře přímo k řádkům kódu, u nichž zjistí podezřelý problém.
• Kopíruje úplnou zprávu také do Job Summary.

Důležité podrobnosti v permissions:

• pull-requests: write - pro přidávání komentářů přímo k řádkům.
• contents: read - pro čtení kódu. Žádné write. Akce sama kód neupravuje, pouze hlásí nálezy.

Tato sada oprávnění stačí pro soukromý repozitář. U veřejného repozitáře můžete navíc zadat actions: read, pokud používáte opakovaně použitelná workflow.

Jak filtrovat falešně pozitivní nálezy a měnit citlivost?#

Úplná tabulka vstupních parametrů GitHub Action (zdroj: README repozitáře):

Příklad konfigurace filtrování falešně pozitivních nálezů. Vytvořte soubor .claude/security/false-positives.md:

# Filtrování falešně pozitivních nálezů pro náš projekt

- Jakýkoli `dangerouslySetInnerHTML` uvnitř `src/lib/email/layout.ts` je bezpečný -
  HTML se skládá z důvěryhodných šablon a při zápisu do databáze prochází přes `sanitize-html`,
  nikoli při vykreslování.
- Nehlaste natvrdo zadané testovací API klíče v `__tests__/fixtures/*.ts`.
  Všechny klíče začínají prefixem `sk-test-fake-`.
- Spojování SQL řetězců v `src/lib/admin/migrations.ts` je přijatelné - soubor se spouští
  pouze s oprávněními root a vstupní data pocházejí z proměnných prostředí.

Připojte soubor ve 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

Pokyny pro vlastní bezpečnostní kontrolu fungují podobně. Vytvořte soubor s pravidly, která jsou důležitá konkrétně pro váš projekt:

# Další kontroly pro náš projekt

- Každý endpoint pod `/api/admin/*` musí kontrolovat roli správce
  prostřednictvím sdíleného wrapperu. Bez něj jde o závažnost HIGH.
- Všechny webhooky YooKassa / CloudPayments musí ověřit podpis před
  parsováním těla požadavku. Bez toho jde o závažnost HIGH.
- Tokeny magic linku lze použít jen jednou (po
  prvním platném požadavku se označí jako použité). Opakovaně použitelné tokeny mají závažnost MEDIUM.

Nejde už o přednastavení od Anthropic: předáváte své znalosti projektu v podobě pravidel, která Claude použije při každém spuštění. To je podstata „metodologie nad modelem“.

Další informace o metodice práce s kontextem pro Claude najdete v návodech „Jak nakonfigurovat CLAUDE.md“ a „Druhý mozek v Claude Code“.

Co Claude NEZACHYTÍ a proč: upřímná omezení?#

Anthropic jasně uvádí, co je ve výchozím nastavení vypnuté a proč (zdroj: README repozitáře):

• Odepření služby - příliš mnoho šumu, téměř vždy malý dopad.
• Problémy s omezením počtu požadavků - řeší se na infrastrukturní úrovni, ne v kódu.
• Vyčerpání paměti / CPU - totéž.
• Obecná validace vstupu bez prokázaného dopadu - validace každého pole vytváří lavinu falešně pozitivních nálezů.
• Open redirect - často jde o zamýšlené chování.

Co samotná revize kódu bez důkazů běhu či nasazení plně neověří:

• Konfigurace produkčního serveru. Hlavičky NGINX, zásady CORS, nastavení TLS, naslouchající porty. Ty je potřeba ručně zkontrolovat ve stagingovém prostředí.
• Závody. Například dvojí útrata při souběžných požadavcích na vrácení peněz. Statická analýza může označit podezřelé vzory, souběžné chování ale stále potřebuje testování.
• Chyby obchodní logiky plateb. Pokud se celková částka objednávky vypočítá na klientovi a jednoduše odešle poskytovateli plateb, jde o závažnost HIGH. Claude ale tento vzorec nemusí vždy rozpoznat bez výslovného kontextu toho, jak má platba fungovat.
• IDOR na úrovni databáze. Pokud dotaz SELECT * FROM orders WHERE id = $1 nekontroluje WHERE user_id = $session.userId, Claude to často zachytí. Pokud se ale kontrola provádí přes middleware ORM a Claude nevidí celý tok dat, může ji přehlédnout.
• Odolnost vůči sociálnímu inženýrství / phishingu. S kódem to nesouvisí.

/security-review použijte jako úvodní statickou kontrolu. Doplňte ji dynamickými testy na stagingu, kontrolou rolí a oprávnění, vhodným SAST a prohlídkou skutečně nasazené konfigurace. Změřené procento pokrytí zde není prokázáno.

Rozsah a termín externího posouzení určete podle rizik a změn systému. Jediný příkaz ani pravidelný externí audit nedokazuje 100% bezpečnostní pokrytí.

Jak autor původního materiálu provedl bezpečnostní kontrolu vibe projektu#

Co se objevilo. Typický obraz průměrného vibe projektu ve fázi „funguje v produkci, ale nikdo ho nerevidoval“: několik podezření ohledně toku autentizace, logiky zpracování webhooků platební integrace, zpracování nahrávaných souborů a několik konkrétních poznámek ke zpracování HTML při vykreslování. Podrobnosti veřejně nepopisuji; některá doporučení už byla uplatněna a další jsou stále v PR. V uvedeném projektu byla úvodní kontrola užitečná a rychlá; nedokládá procento auditu ani obecnou dobu dokončení.

Co jsem vyřadil jako falešně pozitivní nálezy:

• Nálezy o DoS prostřednictvím regulárních výrazů při validaci vstupu - skutečná zátěž na tyto regulární výrazy nedopadá.
• Jeden nález natvrdo zadaného API klíče - šlo o testovací klíč s výslovným prefixem fake- ve fixtures.

Jak dlouho to trvalo. Samotné spuštění trvalo 4 minuty. Kontrola zprávy zabrala 25 minut. Opravy s testy zabraly přibližně hodinu. Celkem: asi hodina a půl od „začal jsem“ po „všechno je v main“. Externí penetrační test stejného rozsahu trvá celý kalendářní týden a stojí mnohonásobně víc.

Hlavní závěr. /security-review nenahrazuje externí penetrační test. Může odhalit užitečné problémy v kódu, jako v autorově uvedeném čtyřminutovém skenu. Opravy zkontrolujte a otestujte, chování běžící aplikace a nasazení ověřte zvlášť; sken bezpečnostní riziko projektu neodstraní.

Jak začlenit /security-review do rutiny před commitem?#

Dříve uvedený hook s git_commit, --severity HIGH a --fail-on-find není dokumentovaný funkční recept a nesmí sloužit jako bezpečnostní brána. Článek neposkytuje ověřený místní hook blokující commit. Oficiální GitHub Action výše dodává automatické nálezy PR; z komentářů neodvozujte blokování commitů či sloučení.

Úplné vysvětlení hooků najdete v návodu „Hooky v Claude Code“.

Alternativou s využitím routines je vytvořit rutinu pre-deploy-check, která jedním příkazem spustí /security-review + npm run build + npm run test. Další materiály najdete v dokumentaci Ailoot.

Pokud používáte servery MCP, můžete nálezy z /security-review propojit se systémem pro incidenty (Sentry, Linear, Notion), aby se každý nález se závažností HIGH automaticky změnil na tiket.

Časté otázky o /security-review#

Kolik stojí jedno spuštění? Záleží na velikosti projektu. U mých 30K řádků spotřebuje jedno spuštění přibližně $0.30-0.50 ze zůstatku API. Velký podnikový repozitář s milionem řádků stojí až $5-8 za spuštění. To je mnohonásobně méně než předplatné libovolného SaaS skeneru.

Jak často bych měl příkaz spouštět lokálně? Minimálně před každým vydáním do produkce. Zvažte ji také před významnými commity a PR. Článek neposkytuje ověřený automatický hook blokující commit.

S jakými stacky funguje? S každým, který Claude dokáže přečíst. Podle pozorování autora byly ověřeny: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. U velmi exotických jazyků (Erlang, Elixir, Clojure) je kvalita nižší, ale něco najde.

Co mám dělat, když Claude pokaždé najde stejnou „zranitelnost“, přestože o zranitelnost nejde? Přidejte ji do false-positive-filtering-instructions a vysvětlete „proč je to bezpečné“. Claude ji při dalších spuštěních přestane hlásit.

Lze příkaz spustit jen na konkrétních souborech? Lokálně ano: jednoduše spusťte /security-review src/lib/auth/*.ts. V GitHub Action se kontroluje pouze aktuální rozdíl PR, což obvykle odpovídá tomu, co se myslí „konkrétními soubory“.

Zdroje#

Další materiály najdete v dokumentaci Ailoot.