Kontrola zabezpečenia v Claude Code: návod krok za krokom a automatizácia GitHub Action v roku 2026

Autor pôvodného materiálu opisuje svoju skúsenosť: „Práve som spustil security-review vo vlastnom vibe projekte a tím za 4 minúty našiel niekoľko skutočných problémov, ktoré už boli opravené.“ Ide o rovnakú prácu, ktorá predtým zabrala externému konzultantovi celý deň.

Ďalšie materiály o konfigurácii nástrojov nájdete v dokumentácii Ailoot.

Čo je /security-review v Claude Code?#

Príkaz funguje v dvoch režimoch. Lokálne: spustite v termináli /security-review a Claude prečíta repozitár a vytvorí správu. Na strane servera: ten istý nástroj sa nainštaluje ako GitHub Action a automaticky pridáva komentáre priamo do každého Pull Requestu.

Na rozdiel od klasických skenerov SAST (Snyk Code, Semgrep, SonarQube) nefunguje /security-review na základe pevne daných pravidiel. Číta kód ako živý inžinier: sleduje tok dát, rozumie tomu, aký framework používate a kde sú hranice dôvery, a zachytáva zraniteľnosti, ktoré žiadne pravidlo neopisuje.

To neznamená, že /security-review nahrádza externý penetračný test alebo testovanie v živom stagingovom prostredí. Môže automatizovať časť úvodnej kontroly kódu, no článok nemeria podiel pokrytia auditu. Nižšie vysvetlím, ako ho správne spustiť a čo Claude vo vašom projekte nájde.

Ako spustiť /security-review v 5 krokoch?#

Krok 1. Aktualizujte Claude Code. Príkaz funguje od vydania z 20. februára 2026.

claude update

Ak ste Claude Code nainštalovali cez npm, môžete použiť aj tento príkaz:

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

Skontrolujte, či sa objavil príkaz /security-review:

claude /help | grep security

Krok 2. Otvorte projekt a prihláste sa do Claude Code.

cd ~/projects/my-vibe-project
claude

Krok 3. Spustite príkaz. V Claude Code jednoducho zadajte:

/security-review

Claude automaticky prejde 3 fázami analýzy:

1. Prieskum kontextu repozitára - prečíta štruktúru a identifikuje stack, trasy a databázové dopyty.
2. Porovnávacia analýza - porovná aktuálny stav s typickými vzormi zraniteľností pre daný stack.
3. Posúdenie zraniteľností - uvedie každé podozrenie spolu s mierou istoty na stupnici od 1 do 10. V správe sú iba zistenia s mierou istoty ≥ 8.

Krok 4. Prečítajte si správu. Výstupom je tabuľka markdown. Pri každom probléme Claude uvedie:

• Súbor a číslo riadka (napríklad src/auth/login.ts:42)
• Závažnosť (HIGH / MEDIUM / LOW)
• Kategóriu (sql_injection, xss, auth_bypass, insecure_storage)
• Opis - čo je nesprávne
• Scenár zneužitia - ako by to mohol útočník využiť
• Odporúčanie - ako to opraviť

Krok 5. Požiadajte ho o vykonanie opráv. Potom s ním môžete pracovať ako s bežným agentom:

„Vykonaj opravy so závažnosťou HIGH zo správy, jednu po druhej, a pridaj opis PR.“

Claude otvorí každý súbor a navrhne zmenu; vy ju potvrdíte. V reálnom projekte som uzavrel 5 zistení za 40 minút namiesto plánovaných 3 hodín.

Aké zraniteľnosti nájde /security-review?#

Úplný zoznam toho, čo analýza štandardne zahŕňa, je uvedený v oficiálnej dokumentácii Anthropic:

Príkaz navyše pokrýva kategórie, ktoré automatizované skenery kontrolujú len zriedka:

• Command injection - vykonanie používateľského vstupu v shelli (child_process.exec(userInput))
• Path traversal - načítanie súboru cez ../../etc/passwd
• XXE - XML s externými entitami
• Template injection - SSTI v Jinja/Handlebars/EJS
• NoSQL injection - operátory $ne, $gt v dopytoch MongoDB
• Nesprávne používanie kryptografie - použitie MD5, režimu ECB alebo statického IV

Claude každému zisteniu priradí závažnosť. Stupnica je jednoduchá:

• HIGH - vzdialené zneužitie bez autentifikácie, únik údajov, ktorý ovplyvňuje všetkých používateľov
• MEDIUM - zneužitie vyžadujúce ďalšie podmienky (potrebná relácia / konkrétny vstup)
• LOW - potenciálny vektor, ktorý teraz nie je kritický, ale oplatí sa ho opraviť

Je dobré vedieť, že v štandardnej konfigurácii Claude nehlási DoS, obmedzovanie frekvencie, vyčerpanie pamäte, otvorené presmerovania bez preukázaného vplyvu, regex injection / ReDoS ani falšovanie záznamov. Je to zámerné, aby ste neboli zahltení šumom. Ak sú tieto triedy dôležité, rozšírte pravidlá (pozrite časť o filtrovaní falošne pozitívnych výsledkov nižšie).

Ako nastaviť GitHub Action na automatickú kontrolu?#

Krok 1. Získajte kľúč API. Prejdite na console.anthropic.com, vytvorte kľúč API a skopírujte ho.

Krok 2. Uložte kľúč do tajomstiev repozitára. V GitHube: Settings → Secrets and variables → Actions → New repository secret. Pomenujte ho CLAUDE_API_KEY; hodnotou je váš kľúč.

Krok 3. Vytvorte súbor workflow. Uložte ho ako .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. Zlúčte vetvu do main. Action sa automaticky spustí pri ďalšom PR.

Čo action robí:

• Spúšťa sa pri každom otvorenom Pull Requeste a jeho synchronizácii.
• Získa rozdiel medzi vetvou PR a main.
• Spustí rovnaký nástroj ako lokálne /security-review.
• Zverejní komentáre priamo na riadkoch kódu, pri ktorých vzniklo podozrenie.
• Skopíruje celú správu do Job Summary.

Dôležité podrobnosti v permissions:

• pull-requests: write - na zverejnenie komentárov priamo v kóde.
• contents: read - na čítanie kódu. Bez write. Action sama kód nemení; iba hlási zistenia.

Táto sada oprávnení stačí pre súkromný repozitár. Vo verejnom repozitári môžete navyše nastaviť actions: read, ak používate opakovane použiteľné workflows.

Ako filtrovať falošne pozitívne výsledky a meniť citlivosť?#

Úplná tabuľka vstupov GitHub Action (zdroj: README repozitára):

Príklad nastavenia filtrovania falošne pozitívnych výsledkov. Vytvorte súbor .claude/security/false-positives.md:

# Pravidlá filtrovania falošne pozitívnych výsledkov pre náš projekt

- Každé použitie `dangerouslySetInnerHTML` v `src/lib/email/layout.ts` je bezpečné -
  HTML sa skladá z dôveryhodných šablón a pri zápise do databázy prechádza cez `sanitize-html`,
  nie až pri vykresľovaní.
- Nehláste pevne zakódované testovacie kľúče API v `__tests__/fixtures/*.ts`.
  Všetky kľúče začínajú na `sk-test-fake-`.
- Spájanie SQL v `src/lib/admin/migrations.ts` je prijateľné - súbor sa spúšťa
  iba ako root a vstupné údaje pochádzajú z premenných prostredia.

Pripojte ho vo 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

Vlastné pokyny pre bezpečnostnú kontrolu fungujú podobne. Vytvorte súbor s pravidlami, ktoré sú kritické práve pre váš projekt:

# Ďalšie kontroly pre náš projekt

- Každý endpoint pod `/api/admin/*` musí kontrolovať rolu správcu
  prostredníctvom spoločného wrappera. Bez tohto wrappera má problém závažnosť HIGH.
- Všetky webhooky YooKassa / CloudPayments musia overiť podpis pred
  analyzovaním tela požiadavky. Bez toho má problém závažnosť HIGH.
- Tokeny magic-link sa musia použiť iba raz (po
  prvej platnej požiadavke sa označia ako použité). Opakovane použiteľné tokeny majú závažnosť MEDIUM.

Toto už nie je prednastavenie Anthropic: prenášate svoje znalosti o projekte do pravidiel, ktoré Claude použije pri každom spustení. To je podstata „metodiky nad modelom“.

Viac o metodike kontextu pre Claude nájdete v sprievodcoch „Ako nakonfigurovať CLAUDE.md“ a „Second Brain v Claude Code“.

Čo Claude nezachytí a prečo: úprimné obmedzenia?#

Anthropic jasne uvádza, čo je predvolene vypnuté a prečo (zdroj: README repozitára):

• Odmietnutie služby - priveľa šumu, takmer vždy nízky dosah.
• Problémy s obmedzovaním frekvencie - riešia sa na úrovni infraštruktúry, nie v kóde.
• Vyčerpanie pamäte / CPU - rovnako.
• Všeobecná validácia vstupu bez preukázaného vplyvu - validácia každého poľa vytvára lavínu falošne pozitívnych výsledkov.
• Otvorené presmerovanie - často ide o zamýšľané správanie.

Čo samotná kontrola kódu nedokáže úplne overiť bez dôkazov z behu či nasadenia:

• Konfiguráciu produkčného servera. Hlavičky NGINX, zásady CORS, nastavenia TLS, porty, na ktorých server počúva. Tie treba manuálne skontrolovať v stagingovom prostredí.
• Súbehové podmienky. Napríklad dvojité minutie peňazí pri súčasných požiadavkách na vrátenie platby. Statická analýza môže označiť podozrivé vzory, no súbežné správanie stále potrebuje testovanie.
• Chyby obchodnej logiky platieb. Ak sa celková suma objednávky vypočíta na strane klienta a iba odošle poskytovateľovi platieb, ide o problém závažnosti HIGH, ale Claude nemusí tento vzor vždy rozpoznať bez výslovného kontextu o tom, ako majú platby fungovať.
• IDOR na úrovni databázy. Ak dopyt SELECT * FROM orders WHERE id = $1 nekontroluje WHERE user_id = $session.userId, Claude to často zachytí. Ak je však kontrola implementovaná cez middleware ORM a Claude nevidí celý tok dát, môže ju prehliadnuť.
• Odolnosť voči sociálnemu inžinierstvu / phishingu. S kódom to nesúvisí.

/security-review používajte ako úvodnú statickú kontrolu. Potom vykonajte dynamické testy v stagingu, kontroly rolí a oprávnení, relevantné kontroly SAST a kontrolu skutočne nasadenej konfigurácie. Článok nedokladá namerané percento pokrytia.

Rozsah a termín externého posúdenia určujte podľa rizík a zmien systému. Jeden príkaz ani pravidelný externý audit nedokazujú 100% bezpečnostné pokrytie.

Ako autor pôvodného materiálu vykonal bezpečnostnú kontrolu vibe projektu#

Čo sa objavilo. Typický obraz priemerného vibe projektu v štádiu „funguje v produkcii, ale ešte neprešiel kontrolou“: niekoľko podozrení týkajúcich sa toku auth, logiky spracovania webhookov z platobnej integrácie, obsluhy nahrávania súborov a pár konkrétnych poznámok k spracovaniu HTML pri vykresľovaní. Podrobnosti verejne neuvádzam; niektoré odporúčania už boli uplatnené a ďalšie sú stále v PR. V opísanom projekte bolo úvodné skenovanie užitočné a rýchle; neurčuje percento pokrytia auditu ani všeobecný čas dokončenia.

Čo som vyhodil ako falošne pozitívne výsledky:

• Zistenia o DoS cez regexy pri validácii vstupu - skutočné zaťaženie tieto regexy nezasahuje.
• Jedno zistenie o pevne zakódovanom kľúči API - išlo o testovací kľúč s výslovným prefixom fake- vo fixtures.

Ako dlho to trvalo. Samotné spustenie trvalo 4 minúty. Preskúmanie správy zabralo 25 minút. Vykonanie opráv vrátane testov trvalo približne hodinu. Spolu: asi hodina a pol od „začal som“ po „všetko je v main“. Externý penetračný test rovnakej oblasti trvá celý kalendárny týždeň a stojí desiatky ráz viac.

Hlavné zistenie. /security-review nenahrádza externý penetračný test. Môže nájsť užitočné problémy v kóde, ako pri autorovom uvádzanom štvorminútovom skenovaní. Opravy skontrolujte a otestujte a potom osobitne overte správanie za behu a nasadenú konfiguráciu; skenovanie bezpečnostné riziko projektu neodstraňuje.

Ako začleniť /security-review do rutiny pred commitom?#

Predtým uvedený hook s git_commit, --severity HIGH a --fail-on-find nie je zdokumentovaný funkčný recept a nesmie slúžiť ako bezpečnostná brána. Článok neposkytuje overený lokálny hook blokujúci commity. Oficiálna GitHub Action vyššie poskytuje automatizované zistenia v PR; zo samotných komentárov nevyvodzujte blokovanie commitov či zlúčení.

Úplné vysvetlenie hookov nájdete v sprievodcovi „Hooky v Claude Code“.

Alternatívou s použitím routines je vytvoriť rutinu pre-deploy-check, ktorá jediným príkazom spustí /security-review + npm run build + npm run test. Ďalšie materiály nájdete v dokumentácii Ailoot.

Ak používate servery MCP, môžete zistenia z /security-review prepojiť so systémom správy incidentov (Sentry, Linear, Notion), aby sa z každého HIGH automaticky vytvorila úloha.

Často kladené otázky o /security-review#

Koľko stojí jedno spustenie? Závisí to od veľkosti projektu. Pri mojich 30K riadkoch stojí jedno spustenie približne $0.30-0.50 zo zostatku API. Veľký podnikový repozitár s miliónom riadkov stojí až $5-8 za spustenie. Je to desiatky ráz lacnejšie než predplatné ľubovoľného SaaS skenera.

Ako často ho mám spúšťať lokálne? Minimálne pred každým produkčným vydaním. Zvážte ho aj pred významnými commitmi a PR. Článok neposkytuje overený hook na automatické blokovanie commitov.

S ktorými stackmi funguje? S každým, ktorý Claude dokáže čítať. Podľa pozorovaní autora boli otestované tieto: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Pri veľmi exotických jazykoch (Erlang, Elixir, Clojure) je kvalita nižšia, ale niečo nájde.

Čo mám robiť, ak Claude zakaždým nájde tú istú „zraniteľnosť“, hoci v skutočnosti o zraniteľnosť nejde? Pridajte ju do false-positive-filtering-instructions s vysvetlením, „prečo je to bezpečné“. Claude ju v budúcich spusteniach prestane hlásiť.

Môžem ho spustiť iba na konkrétnych súboroch? Lokálne áno: jednoducho spustite /security-review src/lib/auth/*.ts. V GitHub Action sa kontroluje iba aktuálny rozdiel PR, čo je zvyčajne to, čo sa myslí pod „konkrétnymi súbormi“.

Zdroje#

Ďalšie materiály nájdete v dokumentácii Ailoot.