Biztonsági felülvizsgálat a Claude Code-ban: lépésről lépésre útmutató és GitHub Action automatizálás 2026-ban

Az eredeti anyag szerzője a saját tapasztalatát írja le: „Épp most futtattam le a security-review-t a saját vibe projektemen, és a csapat 4 perc alatt több valódi problémát talált, amelyeket már ki is javítottunk.” Ugyanez a munka korábban egy külső tanácsadónak egy teljes napjába telt.

Az eszközök konfigurálásáról további anyagok találhatók az Ailoot dokumentációjában.

Mi a /security-review a Claude Code-ban?#

A parancs két módban működik. Helyben: futtasd a /security-review parancsot a terminálban, Claude pedig beolvassa a repót és jelentést készít. Szerveroldalon: ugyanaz a motor GitHub Actionként van telepítve, és automatikusan soron belüli megjegyzéseket fűz minden Pull Requesthez.

A hagyományos SAST-szkennerekkel (Snyk Code, Semgrep, SonarQube) ellentétben a /security-review nem rögzített szabályok alapján működik. Úgy olvassa a kódot, mint egy valódi mérnök: követi az adatfolyamot, megérti, milyen keretrendszert használsz, hol húzódnak a bizalmi határok, és olyan sérülékenységeket is észrevesz, amelyeket egy szabály nem ír le.

Ez nem jelenti azt, hogy a /security-review kiváltja a külső pentestet vagy az éles tesztelést staging környezetben. Automatizálhatja a kezdeti kódfelülvizsgálat egy részét, de a cikk nem mér auditlefedettségi arányt. Az alábbiakban elmagyarázom, hogyan futtasd megfelelően, és mit talál majd Claude a projektedben.

Hogyan futtasd a /security-review parancsot 5 lépésben?#

1. lépés. Frissítsd a Claude Code-ot. A parancs a 2026. február 20-i kiadástól kezdve működik.

claude update

Ha npm-en keresztül telepítetted a Claude Code-ot, ezt is futtathatod:

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

Ellenőrizd, hogy megjelent-e a /security-review:

claude /help | grep security

2. lépés. Nyisd meg a projektet, és jelentkezz be a Claude Code-ba.

cd ~/projects/my-vibe-project
claude

3. lépés. Futtasd a parancsot. A Claude Code-ban egyszerűen írd be:

/security-review

Claude automatikusan végigmegy 3 elemzési fázison:

1. Repository Context Research - beolvassa a struktúrát, és azonosítja a stacket, az útvonalakat és az adatbázis-lekérdezéseket.
2. Comparative Analysis - összehasonlítja az aktuális állapotot a stackre jellemző sérülékenységi mintákkal.
3. Vulnerability Assessment - minden gyanús esetet felsorol 1–10-es skálán megadott megbízhatósági szinttel. Csak a legalább 8-as megbízhatóságú megállapítások kerülnek a jelentésbe.

4. lépés. Olvasd el a jelentést. A kimenet formátuma egy markdown-táblázat. Claude minden problémához megadja:

• Fájl és sorszám (például src/auth/login.ts:42)
• Súlyosság (HIGH / MEDIUM / LOW)
• Kategória (sql_injection, xss, auth_bypass, insecure_storage)
• Leírás - mi a probléma
• Kihasználási forgatókönyv - hogyan használhatja ki egy támadó
• Javaslat - hogyan javítható

5. lépés. Kérd meg a javítások alkalmazására. Ezután úgy dolgozhatsz vele, mint egy hagyományos ügynökkel:

„Alkalmazd a jelentés MAGAS súlyosságú javításait egyenként, PR-leírással együtt.”

Claude megnyitja az egyes fájlokat, és javaslatot tesz egy módosításra; te jóváhagyod. Egy valódi projekten 40 perc alatt zártam le 5 megállapítást a tervezett 3 óra helyett.

Milyen sérülékenységeket talál meg a /security-review?#

Az elemzésben alapértelmezetten szereplő dolgok teljes listáját az Anthropic hivatalos dokumentációja ismerteti:

Emellett a parancs olyan kategóriákat is lefed, amelyeket az automatikus szkennerek ritkán vizsgálnak:

• Command injection - felhasználói bemenet futtatása shellben (child_process.exec(userInput))
• Path traversal - fájl betöltése a ../../etc/passwd útvonalon keresztül
• XXE - külső entitásokat tartalmazó XML
• Template injection - SSTI Jinja/Handlebars/EJS környezetben
• NoSQL injection - $ne, $gt operátorok a MongoDB-lekérdezésekben
• Kriptográfia helytelen használata - MD5, ECB mód vagy statikus IV használata

Claude minden megállapításhoz súlyossági besorolást rendel. A skála egyszerű:

• HIGH - távoli kihasználás hitelesítés nélkül, minden felhasználót érintő adatszivárgás
• MEDIUM - kihasználás további feltételekkel (munkamenet vagy konkrét bemenet szükséges)
• LOW - lehetséges támadási felület, jelenleg nem kritikus, de érdemes javítani

Érdemes tudni: alapértelmezett konfigurációban Claude nem jelent DoS-t, sebességkorlátozást, memóriakimerítést, bizonyított hatás nélküli open redirectet, regex injectiont / ReDoS-t vagy naplóhamisítást. Ez szándékos, hogy ne árasztson el zajjal. Ha ezek az osztályok fontosak, bővítsd a szabályokat (lásd alább a téves pozitív találatok szűréséről szóló részt).

Hogyan állíts be GitHub Actiont az automatikus felülvizsgálathoz?#

1. lépés. Szerezz API-kulcsot. Nyisd meg a console.anthropic.com oldalt, hozz létre egy API-kulcsot, és másold ki.

2. lépés. Helyezd el a kulcsot a repó secrets beállításai között. GitHubon: Settings → Secrets and variables → Actions → New repository secret. Neve legyen CLAUDE_API_KEY; az értéke pedig a kulcsod.

3. lépés. Hozz létre egy workflow-fájlt. Mentsd .github/workflows/security.yml néven:

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 }}

4. lépés. Merge-eld az ágat a mainbe. Az action automatikusan elindul a következő PR-nél.

Mit csinál az action:

• Minden megnyitott / szinkronizált Pull Requestnél lefut.
• Lekéri a PR-ág és a main közötti diffet.
• Ugyanazt a motort futtatja, mint a helyi /security-review.
• Közvetlenül azokhoz a kódsorokhoz fűz soron belüli megjegyzéseket, ahol gyanús esetet talált.
• A teljes jelentést a Job Summary részben is közzéteszi.

Fontos részletek a permissions beállításban:

• pull-requests: write - soron belüli megjegyzések közzétételéhez.
• contents: read - a kód olvasásához. Nincs write. Az action nem módosítja a kódot, csak jelentést készít.

Ez a beállítás privát repóhoz elegendő. Nyilvános repónál megadhatod az actions: read engedélyt is, ha újrafelhasználható workflow-kat használsz.

Hogyan szűrd a téves pozitív találatokat és módosítsd az érzékenységet?#

A GitHub Action bemeneteinek teljes táblázata (forrás: a repó README-je):

Példa a téves pozitív találatok szűrésének beállítására. Hozd létre a .claude/security/false-positives.md fájlt:

# Téves pozitív találatok szűrésére szolgáló szabályok a projektünkhöz

- A `src/lib/email/layout.ts` fájlban lévő minden `dangerouslySetInnerHTML` biztonságos -
  a HTML megbízható sablonokból áll össze, és áthalad a `sanitize-html` eszközön
  az adatbázisba íráskor, nem pedig rendereléskor.
- Ne jelentsd a `__tests__/fixtures/*.ts` fájlokban közvetlenül megadott teszt-API-kulcsokat.
  Minden kulcs `sk-test-fake-` előtaggal kezdődik.
- A `src/lib/admin/migrations.ts` fájlban az SQL-összefűzés elfogadható - a fájl
  csak rootként fut, a bemeneti adatok pedig környezeti változókból származnak.

Kapcsold be a workflow-ban:

- 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

Az egyéni biztonsági vizsgálati utasítások hasonlóan működnek. Hozz létre egy fájlt a projektre különösen jellemző, kritikus szabályokkal:

# További ellenőrzések a projektünkhöz

- Minden `/api/admin/*` alatti végpontnak ellenőriznie kell az adminisztrátori szerepkört
  egy közös wrapperen keresztül. Enélkül a súlyosság MAGAS.
- Minden YooKassa / CloudPayments webhooknak ellenőriznie kell az aláírást a törzs
  feldolgozása előtt. Enélkül a súlyosság MAGAS.
- A magic link tokenek csak egyszer legyenek használhatók (az első érvényes kérés után
  legyenek használtként megjelölve). Az újra felhasználható tokenek súlyossága KÖZEPES.

Ez már nem Anthropic-előbeállítás: a projektre vonatkozó szakértelmedet viszed át olyan szabályokba, amelyeket Claude minden alkalommal alkalmaz. Ez a „módszertan a modell felett” lényege.

A Claude kontextusmódszertanáról bővebben lásd a „A CLAUDE.md konfigurálása” és a „Second Brain a Claude Code-ban” útmutatókat.

Mit NEM talál meg Claude, és miért: őszinte korlátozások?#

Az Anthropic egyértelműen felsorolja, mi van alapértelmezetten letiltva, és miért (forrás: a repó README-je):

• Denial of Service - túl sok zajt okoz, és a hatása szinte mindig csekély.
• Sebességkorlátozási problémák - ezeket infrastruktúraszinten kezelik, nem a kódban.
• Memória-/CPU-kimerítés - ugyanez.
• Általános bemenetellenőrzés bizonyított hatás nélkül - minden mező ellenőrzése téves pozitív találatok tömegét eredményezi.
• Open redirect - gyakran szándékos működés.

Amit a kódfelülvizsgálat önmagában futásidejű vagy telepítési bizonyíték nélkül nem tud teljesen igazolni:

• Éles szerverkonfiguráció. NGINX-fejlécek, CORS-szabályok, TLS-beállítások, figyelt portok. Ezeket staging környezetben, manuálisan kell ellenőrizni.
• Versenyhelyzetek. Például kétszeres költés egyidejű visszatérítési kérések esetén. A statikus elemzés jelezhet gyanús mintákat, de a párhuzamos működést továbbra is tesztelni kell.
• Fizetési üzleti logikájának hibái. Ha a rendelés végösszegét a kliens számolja ki, és egyszerűen elküldi a fizetési szolgáltatónak, az HIGH súlyosságú, de Claude ezt a mintát nem mindig veszi észre annak kifejezett ismerete nélkül, hogyan kellene működnie a fizetésnek.
• Adatbázisszintű IDOR. Ha a SELECT * FROM orders WHERE id = $1 lekérdezésben nincs WHERE user_id = $session.userId ellenőrzés, Claude ezt gyakran felismeri. Ha azonban az ellenőrzés ORM middleware-en keresztül valósul meg, és Claude nem látja a teljes adatfolyamot, előfordulhat, hogy nem veszi észre.
• A social engineeringgel / adathalászattal szembeni ellenállás. Ennek semmi köze a kódhoz.

A /security-review kezdeti statikus felülvizsgálatként használd. Kövessék staging környezetben végzett dinamikus tesztek, szerepkör- és jogosultság-ellenőrzések, releváns SAST-ellenőrzések és a ténylegesen telepített konfiguráció átnézése. Mért lefedettségi százalékot itt nem igazolunk.

A külső értékelés hatókörét és időzítését a rendszer kockázatai és változásai alapján határozd meg. Sem egy parancs, sem egy időszakos külső audit nem igazol 100%-os biztonsági lefedettséget.

Hogyan végzett biztonsági felülvizsgálatot az eredeti anyag szerzője egy vibe projekten?#

Mik merültek fel? Tipikus kép egy átlagos vibe projektnél abban az állapotban, hogy „működik produkcióban, de még nem vizsgálták át”: több gyanús eset a hitelesítési folyamatban, a fizetési integráció webhookjainak feldolgozási logikájában, a fájlfeltöltés kezelésében, valamint néhány konkrét megjegyzés a HTML rendereléskori kezelésével kapcsolatban. A részleteket nem teszem közzé; néhány javaslatot már alkalmaztunk, mások még PR-ben vannak. A bemutatott projektben a kezdeti vizsgálat hasznos és gyors volt; ebből nem következik auditlefedettségi százalék vagy általános teljesítési idő.

Amit téves pozitív találatként elvetettem:

• Bemenetellenőrző regexeken keresztüli DoS-ra vonatkozó megállapítások - a valódi terhelés nem azokon a regexeken jelentkezik.
• Egy kódba égetett API-kulcsról szóló megállapítás - tesztkulcs volt, a fixtures fájlokban kifejezett fake- előtaggal.

Mennyi ideig tartott? Maga a futtatás 4 percet vett igénybe. A jelentés áttekintése 25 percig tartott. A javítások alkalmazása tesztekkel együtt körülbelül egy órát vett igénybe. Összesen körülbelül másfél óra telt el a „kezdéstől” addig, hogy „minden a mainben legyen”. Egy külső pentest ugyanezen a felületen egy naptári hetet vesz igénybe, és több tucatszor többe kerül.

A fő tanulság. A /security-review nem váltja ki a külső pentestet. Hasznos kódszintű megállapításokat adhat, ahogy a szerző leírt négyperces vizsgálatában is. Nézd át és teszteld a javításokat, majd külön ellenőrizd a futásidejű működést és a telepített konfigurációt; a vizsgálat nem szünteti meg a projekt biztonsági kockázatát.

Hogyan építsd be a /security-review parancsot a pre-commit rutinodba?#

A korábban bemutatott, git_commit, --severity HIGH és --fail-on-find elemeket használó hook nem dokumentált, működő recept, ezért nem használható biztonsági kapuként. A cikk nem ad igazolt helyi commitblokkoló hookot. A fent bemutatott hivatalos GitHub Action automatikus PR-megállapításokat ad; a PR megjegyzéseiből ne következtess commit- vagy egyesítésblokkolásra.

A hookok teljes magyarázatát a „Hookok a Claude Code-ban” útmutató tartalmazza.

A routines használatával az a másik lehetőség, hogy létrehozol egy pre-deploy-check rutint, amely egyetlen paranccsal futtatja a /security-review + npm run build + npm run test parancsokat. További anyagok az Ailoot dokumentációjában találhatók.

Ha MCP-szervereket használsz, a /security-review megállapításait incidenskezelő rendszerrel (Sentry, Linear, Notion) is integrálhatod, így minden HIGH súlyosságú megállapításból automatikusan jegy lesz.

GYIK a /security-review parancsról#

Mennyibe kerül egy futtatás? A projekt méretétől függ. Az én 30K soros projektemen egy futtatás körülbelül $0.30-0.50 API-egyenleget használ fel. Egy egymillió soros nagyvállalati repó futtatásonként akár $5-8-ba is kerülhet. Ez több tucatszor olcsóbb bármely SaaS-szkenner-előfizetésnél.

Milyen gyakran futtassam helyben? Legalább minden produkciós kiadás előtt. Jelentős commitok és PR-ek előtt is mérlegeld a futtatást. A cikk nem ad igazolt automatikus commitblokkoló hookot.

Milyen stackeken működik? Mindenen, amit Claude el tud olvasni. A szerző megfigyelései szerint ezeket már ellenőrizték: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Nagyon egzotikus nyelveken (Erlang, Elixir, Clojure) alacsonyabb a minőség, de így is talál valamit.

Mit tegyek, ha Claude minden alkalommal ugyanazt a „sérülékenységet” találja meg, pedig az valójában nem is sérülékenység? Vedd fel a false-positive-filtering-instructions beállításba annak magyarázatával, hogy „miért biztonságos ez”. Claude a következő futtatások során nem fogja többé jelenteni.

Futtathatom csak meghatározott fájlokon? Helyben igen: egyszerűen futtasd a /security-review src/lib/auth/*.ts parancsot. A GitHub Action csak az aktuális PR diffjét ellenőrzi, és általában ezt értjük „meghatározott fájlok” alatt.

Források#

További anyagok az Ailoot dokumentációjában találhatók.