Claude Code saugumo peržiūra: nuoseklus vadovas ir GitHub Action automatizavimas 2026 m.

Pradinės medžiagos autorius pasakoja apie savo patirtį: „Ką tik paleidau security-review savo vibe projekte, ir komanda per 4 minutes aptiko kelias tikras problemas, kurios jau ištaisytos.“ Anksčiau tokiam darbui išorinis konsultantas skirdavo visą dieną.

Daugiau medžiagos apie įrankių konfigūravimą rasite Ailoot dokumentacijoje.

Kas yra /security-review programoje Claude Code?#

Komanda veikia dviem režimais. Vietinis: paleiskite terminale /security-review, ir Claude perskaitys saugyklą bei parengs ataskaitą. Serverio pusėje: tas pats variklis įdiegiamas kaip GitHub Action ir automatiškai pateikia komentarus kiekviename Pull Request.

Kitaip nei klasikiniai SAST skaitytuvai (Snyk Code, Semgrep, SonarQube), /security-review neveikia pagal fiksuotas taisykles. Ji skaito kodą kaip realiuoju laiku dirbantis inžinierius: seka duomenų srautą, supranta, kokią sistemą naudojate ir kur yra pasitikėjimo ribos, aptinka pažeidžiamumus, kurių neaprašo jokia taisyklė.

Tai nereiškia, kad /security-review pakeičia išorinį pentest arba testavimą veikiančioje parengiamojoje aplinkoje. Ji gali automatizuoti dalį pradinės kodo peržiūros, tačiau šis straipsnis nematuoja audito aprėpties dalies. Toliau paaiškinsiu, kaip ją tinkamai paleisti ir ką Claude aptiks jūsų projekte.

Kaip paleisti /security-review per 5 žingsnius?#

1 žingsnis. Atnaujinkite Claude Code. Komanda veikia nuo 2026 m. vasario 20 d. išleistos versijos.

claude update

Jei Claude Code įdiegėte per npm, taip pat galite vykdyti:

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

Patikrinkite, ar atsirado /security-review:

claude /help | grep security

2 žingsnis. Atidarykite projektą ir prisijunkite prie Claude Code.

cd ~/projects/my-vibe-project
claude

3 žingsnis. Paleiskite komandą. Claude Code tiesiog įveskite:

/security-review

Claude automatiškai atliks 3 analizės etapus:

1. Saugyklos konteksto tyrimas – perskaitys struktūrą ir nustatys technologijų rinkinį, maršrutus bei duomenų bazės užklausas.
2. Lyginamoji analizė – palygins dabartinę būseną su tipiniais šio technologijų rinkinio pažeidžiamumų šablonais.
3. Pažeidžiamumų vertinimas – išvardys kiekvieną įtarimą ir nurodys pasitikėjimo lygį skalėje nuo 1 iki 10. Ataskaitoje pateikiami tik radiniai, kurių pasitikėjimo lygis ≥ 8.

4 žingsnis. Perskaitykite ataskaitą. Išvestis pateikiama markdown lentele. Apie kiekvieną problemą Claude nurodo:

• Failą ir eilutės numerį (pavyzdžiui, src/auth/login.ts:42)
• Rimtumą (HIGH / MEDIUM / LOW)
• Kategoriją (sql_injection, xss, auth_bypass, insecure_storage)
• Aprašymą – kas negerai
• Išnaudojimo scenarijų – kaip užpuolikas galėtų tai panaudoti
• Rekomendaciją – kaip tai ištaisyti

5 žingsnis. Paprašykite pritaikyti pataisas. Tada galite dirbti su juo kaip su įprastu agentu:

„Pritaikyk ataskaitoje nurodytas HIGH rimtumo pataisas po vieną ir pateik PR aprašymą.“

Claude atidarys kiekvieną failą ir pasiūlys pakeitimą; jūs jį patvirtinsite. Tikrame projekte per 40 minučių užbaigiau 5 radinių taisymą, nors buvau suplanavęs 3 valandas.

Kokius pažeidžiamumus aptinka /security-review?#

Išsamus sąrašas to, kas įtraukta į numatytąją analizę, pateiktas oficialioje Anthropic dokumentacijoje:

Be to, komanda apima kategorijas, kurias automatizuoti skaitytuvai retai tikrina:

• Command injection – naudotojo įvesties vykdymas apvalkale (child_process.exec(userInput))
• Path traversal – failo įkėlimas per ../../etc/passwd
• XXE – XML su išorinėmis esybėmis
• Template injection – SSTI sistemoje Jinja/Handlebars/EJS
• NoSQL injection – $ne, $gt operatoriai MongoDB užklausose
• Netinkamas kriptografijos naudojimas – MD5, ECB režimo arba statinio IV naudojimas

Claude kiekvienam radiniui priskiria rimtumą. Skalė paprasta:

• HIGH – nuotolinis išnaudojimas be autentifikavimo, duomenų nutekėjimas, paveikiantis visus naudotojus
• MEDIUM – išnaudojimui reikalingos papildomos sąlygos (būtina sesija / konkreti įvestis)
• LOW – galimas atakos vektorius, šiuo metu nekritinis, bet vertas pataisymo

Naudinga žinoti: pagal standartinę konfigūraciją Claude nepraneša apie DoS, užklausų dažnio ribojimą, atminties išsekimą, atvirus peradresavimus be įrodyto poveikio, regex injection / ReDoS ar žurnalų klastojimą. Taip daroma sąmoningai, kad jūsų neužverstų triukšmu. Jei šios klasės svarbios, išplėskite taisykles (žr. toliau esantį skyrių apie klaidingai teigiamų rezultatų filtravimą).

Kaip nustatyti automatinę peržiūrą vykdančią GitHub Action?#

1 žingsnis. Gaukite API raktą. Eikite į console.anthropic.com, sukurkite API raktą ir jį nukopijuokite.

2 žingsnis. Įrašykite raktą į saugyklos paslaptis. GitHub aplinkoje pasirinkite: Settings → Secrets and variables → Actions → New repository secret. Pavadinkite jį CLAUDE_API_KEY; reikšmė yra jūsų raktas.

3 žingsnis. Sukurkite workflow failą. Išsaugokite jį kaip .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 }}

4 žingsnis. Sujunkite šaką su main. Action automatiškai pasileis su kitu PR.

Ką daro action:

• Paleidžiama su kiekvienu atviru Pull Request ir jo sinchronizavimu.
• Paimamas skirtumas tarp PR šakos ir main.
• Paleidžiamas tas pats variklis kaip ir vykdant vietinę /security-review.
• Tiesiai prie įtartinų kodo eilučių paskelbiami komentarai.
• Visa ataskaita pateikiama ir Job Summary.

Svarbios permissions detalės:

• pull-requests: write – komentarams tiesiai kode paskelbti.
• contents: read – kodui skaityti. Be write. Action pati kodo nekeičia, tik praneša apie radinius.

Šių leidimų pakanka privačiai saugyklai. Viešoje saugykloje galite papildomai nurodyti actions: read, jei naudojate pakartotinai naudojamus workflows.

Kaip filtruoti klaidingai teigiamus rezultatus ir keisti jautrumą?#

Visa GitHub Action įvesčių lentelė (šaltinis: saugyklos README):

Klaidingai teigiamų rezultatų filtravimo konfigūravimo pavyzdys. Sukurkite failą .claude/security/false-positives.md:

# Mūsų projekto klaidingai teigiamų rezultatų filtravimo taisyklės

- Bet koks `dangerouslySetInnerHTML` naudojimas faile `src/lib/email/layout.ts` yra saugus -
  HTML sudaromas iš patikimų šablonų ir apdorojamas naudojant `sanitize-html`
  įrašant į duomenų bazę, o ne atvaizdavimo metu.
- Nepraneškite apie faile `__tests__/fixtures/*.ts` įrašytus bandomuosius API raktus.
  Visi raktai prasideda `sk-test-fake-`.
- SQL eilučių jungimas faile `src/lib/admin/migrations.ts` yra priimtinas - failas vykdomas
  tik kaip root, o įvesties duomenys gaunami iš aplinkos kintamųjų.

Prijunkite jį workflow faile:

- 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

Pasirinktinės saugumo skenavimo instrukcijos veikia panašiai. Sukurkite failą su taisyklėmis, kurios ypač svarbios jūsų projektui:

# Papildomos mūsų projekto patikros

- Kiekvienas endpoint adresu `/api/admin/*` turi tikrinti administratoriaus vaidmenį
  naudodamas bendrą wrapper. Be šio wrapper pažeidimo rimtumas yra HIGH.
- Visi „YooKassa“ / „CloudPayments“ webhook pranešimai turi patikrinti parašą prieš
  analizuodami užklausos turinį. Be šios patikros pažeidimo rimtumas yra HIGH.
- Magic-link žetonus galima naudoti tik vieną kartą (po
  pirmos galiojančios užklausos jie pažymimi kaip panaudoti). Pakartotinai naudojamų žetonų rimtumas yra MEDIUM.

Tai jau ne Anthropic paruoštas rinkinys: savo žinias apie projektą perkelsite į taisykles, kurias Claude taikys kaskart. Tokia yra „metodikos svarbiau už modelį“ esmė.

Daugiau apie Claude konteksto metodiką skaitykite vadovuose „Kaip sukonfigūruoti CLAUDE.md“ ir „Second Brain programoje Claude Code“.

Ko Claude NEaptinka ir kodėl: sąžiningi apribojimai?#

Anthropic aiškiai nurodo, kas pagal numatytuosius nustatymus išjungta ir kodėl (šaltinis: saugyklos README):

• Paslaugos trikdymas – per daug triukšmo, beveik visada mažas poveikis.
• Dažnio ribojimo problemos – sprendžiamos infrastruktūros lygmeniu, o ne kode.
• Atminties / CPU išsekimas – tas pats.
• Bendro pobūdžio įvesties tikrinimas be įrodyto poveikio – tikrinant kiekvieną lauką kyla klaidingai teigiamų rezultatų lavina.
• Atviras peradresavimas – dažnai tai numatytas veikimas.

Ko vien kodo peržiūra negali iki galo patvirtinti be vykdymo ar diegimo įrodymų:

• Gamybinio serverio konfigūracijos. NGINX antraštės, CORS taisyklės, TLS nustatymai, klausymosi prievadai. Juos reikia patikrinti rankiniu būdu parengiamojoje aplinkoje.
• Lenktyniavimo sąlygų. Pavyzdžiui, dvigubo pinigų išleidimo, kai vienu metu pateikiamos pinigų grąžinimo užklausos. Statinė analizė gali pažymėti įtartinus šablonus, tačiau lygiagrečią elgseną vis tiek reikia išbandyti.
• Mokėjimų verslo logikos trūkumų. Jei užsakymo suma apskaičiuojama kliento pusėje ir tiesiog siunčiama mokėjimo paslaugų teikėjui, tai yra HIGH rimtumo problema, tačiau Claude ne visada atpažįsta šį šabloną neturėdamas aiškaus konteksto, kaip mokėjimai turėtų veikti.
• IDOR duomenų bazės lygmeniu. Jei užklausa SELECT * FROM orders WHERE id = $1 netikrina WHERE user_id = $session.userId, Claude dažnai tai pastebi. Tačiau jei patikra įgyvendinta per ORM tarpinę programinę įrangą ir Claude nemato viso duomenų srauto, gali jos nepastebėti.
• Atsparumo socialinei inžinerijai / sukčiavimo apsimetant atakoms. Tai nesusiję su kodu.

/security-review naudokite kaip pradinę statinę peržiūrą. Po jos atlikite dinaminius testus parengiamojoje aplinkoje, vaidmenų ir leidimų patikras, tinkamas SAST patikras ir tikrosios įdiegtos konfigūracijos peržiūrą. Čia nenustatytas joks išmatuotas aprėpties procentas.

Išorinio vertinimo apimtį ir laiką nustatykite pagal sistemos rizikas bei pakeitimus. Nei viena komanda, nei periodinis išorinis auditas nepatvirtina 100% saugumo aprėpties.

Kaip pradinės medžiagos autorius atliko vibe projekto saugumo peržiūrą#

Kas išaiškėjo. Tipiškas vidutinio vibe projekto, esančio etape „veikia gamybinėje aplinkoje, bet nebuvo peržiūrėtas“, vaizdas: keli įtarimai dėl auth srauto, mokėjimų integracijos webhook apdorojimo logikos, failų įkėlimo tvarkymo ir kelios konkrečios pastabos apie HTML apdorojimą atvaizdavimo metu. Detalių viešai neaprašau; dalis rekomendacijų jau pritaikyta, o dėl kitų vis dar atidaryti PR. Šiame aprašytame projekte pradinis skenavimas buvo naudingas ir greitas; tai nenustato audito aprėpties procento ar bendros užbaigimo trukmės.

Ką atmečiau kaip klaidingai teigiamus rezultatus:

• DoS radinius, susijusius su regex įvesties tikrinime – tikroji apkrova šių regex nepasiekia.
• Vieną radinį apie kode įrašytą API raktą – tai buvo bandomasis raktas, kurio aiškus prefiksas fake-, esantis fixtures.

Kiek tai užtruko. Pats paleidimas truko 4 minutes. Ataskaitos peržiūra – 25 minutes. Pataisoms pritaikyti, įskaitant testus, prireikė maždaug valandos. Iš viso: apie pusantros valandos nuo „pradėjau“ iki „viskas main“. Tokio paties paviršiaus išorinis pentest trunka visą kalendorinę savaitę ir kainuoja dešimtis kartų daugiau.

Pagrindinė išvada. /security-review nepakeičia išorinio pentest. Ji gali pateikti naudingų kodo radinių, kaip aprašytame autoriaus keturių minučių skenavime. Peržiūrėkite ir išbandykite pataisas, tada atskirai patikrinkite vykdymo elgseną ir įdiegtą konfigūraciją; skenavimas nepanaikina projekto saugumo rizikos.

Kaip integruoti /security-review į rutiną prieš commit?#

Anksčiau rodytas hook su git_commit, --severity HIGH ir --fail-on-find nėra dokumentuotas veikiantis receptas ir neturi būti naudojamas kaip saugumo vartai. Šis straipsnis nepateikia patikrinto vietinio įrašus blokuojančio hook. Pirmiau parodyta oficiali GitHub Action automatizuoja PR radinius; vien tai, kad ji komentuoja PR, neįrodo įrašų ar sujungimų blokavimo.

Išsamų hook paaiškinimą rasite vadove „Hookai programoje Claude Code“.

Kita galimybė – naudojant routines sukurti pre-deploy-check rutiną, kuri viena komanda paleidžia /security-review + npm run build + npm run test. Daugiau medžiagos rasite Ailoot dokumentacijoje.

Jei naudojate MCP serverius, galite integruoti /security-review radinius su incidentų sistema (Sentry, Linear, Notion), kad kiekvienas HIGH automatiškai taptų užduotimi.

DUK apie /security-review#

Kiek kainuoja vienas paleidimas? Tai priklauso nuo projekto dydžio. Mano 30K eilučių projekte vienas paleidimas sunaudoja apie $0.30-0.50 API balanso. Didelė įmonės saugykla, kurioje yra milijonas eilučių, gali kainuoti iki $5-8 už paleidimą. Tai dešimtis kartų pigiau nei bet kuri SaaS skaitytuvo prenumerata.

Kaip dažnai turėčiau paleisti įrankį vietoje? Bent prieš kiekvieną gamybinės versijos išleidimą. Taip pat svarstykite peržiūrą prieš reikšmingus įrašus ir PR. Šis straipsnis nepateikia patikrinto automatinio įrašus blokuojančio hook.

Su kokiais technologijų rinkiniais jis veikia? Su visais, kuriuos gali perskaityti Claude. Autoriaus pastebėjimais, patikrinti šie: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Egzotiškų kalbų (Erlang, Elixir, Clojure) analizės kokybė prastesnė, bet įrankis ką nors aptiks.

Ką daryti, jei Claude kaskart randa tą patį „pažeidžiamumą“, nors iš tikrųjų tai nėra pažeidžiamumas? Įtraukite jį į false-positive-filtering-instructions ir paaiškinkite, „kodėl tai saugu“. Ateityje Claude apie tai nebepraneš.

Ar galiu tikrinti tik konkrečius failus? Vietoje – taip: tiesiog paleiskite /security-review src/lib/auth/*.ts. GitHub Action tikrina tik dabartinio PR pakeitimus, o tai paprastai ir turima omenyje sakant „konkretūs failai“.

Šaltiniai#

Daugiau medžiagos rasite Ailoot dokumentacijoje.