Claude Code xavfsizlik tekshiruvi: qo‘llanma va GitHub Action

Asl material muallifi o‘z tajribasini tasvirlaydi: “Men o‘z vibe loyihamda security-review’ni ishga tushirdim va jamoa 4 daqiqada bir nechta haqiqiy muammoni topdi; ular allaqachon tuzatildi.” Ilgari tashqi maslahatchiga bir kun ketadigan ish shu edi.

Vositalarni sozlash bo‘yicha qo‘shimcha materiallar Ailoot hujjatlarida mavjud.

Claude Code’dagi /security-review nima?#

Buyruq ikki rejimda ishlaydi. Lokal rejim: terminalda /security-review buyrug‘ini ishga tushiring, Claude repozitoriyni o‘qib, hisobot tuzadi. Server tomoni rejimi: ayni dvigatel GitHub Action sifatida o‘rnatiladi va har bir Pull Request’da avtomatik ravishda kod satrlariga izoh qoldiradi.

Klassik SAST skanerlaridan (Snyk Code, Semgrep, SonarQube) farqli ravishda, /security-review qat’iy qoidalar asosida ishlamaydi. U kodni tajribali muhandis kabi o‘qiydi: ma’lumotlar oqimini kuzatadi, qaysi freymvorkdan foydalanayotganingizni va ishonch chegaralari qayerdaligini tushunadi hamda qoidada tasvirlanmagan zaifliklarni aniqlaydi.

Bu /security-review tashqi pentest yoki stend muhitidagi jonli sinov o‘rnini bosadi degani emas. Dastlabki kod ko‘rigining bir qismini avtomatlashtirishi mumkin, lekin maqola audit qamrovi ulushini o‘lchamaydi. Quyida uni qanday to‘g‘ri ishga tushirish va Claude loyihangizda nimalarni topishi haqida tushuntiraman.

/security-review’ni 5 bosqichda qanday ishga tushirish mumkin?#

1-bosqich. Claude Code’ni yangilang. Buyruq 2026-yil 20-fevraldagi relizdan boshlab ishlaydi.

claude update

Agar Claude Code’ni npm orqali o‘rnatgan bo‘lsangiz, quyidagini ham bajarishingiz mumkin:

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

/security-review paydo bo‘lganini tekshiring:

claude /help | grep security

2-bosqich. Loyihani ochib, Claude Code’ga kiring.

cd ~/projects/my-vibe-project
claude

3-bosqich. Buyruqni ishga tushiring. Claude Code ichida shunchaki quyidagini kiriting:

/security-review

Claude avtomatik ravishda tahlilning 3 bosqichidan o‘tadi:

1. Repozitoriy kontekstini o‘rganish - tuzilmani o‘qiydi va stek, marshrutlar hamda ma’lumotlar bazasi so‘rovlarini aniqlaydi.
2. Qiyosiy tahlil - joriy holatni ushbu stek uchun odatiy zaiflik namunalariga solishtiradi.
3. Zaifliklarni baholash - har bir shubhali holatni 1–10 shkalasida ishonch darajasi bilan sanab o‘tadi. Hisobotga faqat ishonch darajasi ≥ 8 bo‘lgan topilmalar kiritiladi.

4-bosqich. Hisobotni o‘qing. Natija Markdown jadvali shaklida bo‘ladi. Har bir muammo uchun Claude quyidagilarni beradi:

• Fayl va satr raqami (masalan, src/auth/login.ts:42)
• Jiddiylik (HIGH / MEDIUM / LOW)
• Toifa (sql_injection, xss, auth_bypass, insecure_storage)
• Tavsif - nima noto‘g‘ri
• Ekspluatatsiya ssenariysi - tajovuzkor undan qanday foydalanishi mumkin
• Tavsiya - qanday tuzatish kerak

5-bosqich. Tuzatishlarni qo‘llashni so‘rang. Shundan keyin u bilan odatiy agent kabi ishlashingiz mumkin:

“Hisobotdagi HIGH darajali tuzatishlarni bittadan qo‘llang va PR tavsifini ham yozing.”

Claude har bir faylni ochib, o‘zgarishni taklif qiladi; siz uni tasdiqlaysiz. Haqiqiy loyihada rejalashtirilgan 3 soat o‘rniga 40 daqiqada 5 ta topilmani yopdim.

/security-review qanday zaifliklarni topadi?#

Odatiy tahlilga nimalar kirishi haqida to‘liq ro‘yxat Anthropic’ning rasmiy hujjatlarida keltirilgan:

Bundan tashqari, buyruq avtomatlashtirilgan skanerlar kamdan-kam qamrab oladigan toifalarni ham tekshiradi:

• Buyruq inʼeksiyasi - foydalanuvchi kiritgan ma’lumotni qobiqda bajarish (child_process.exec(userInput))
• Yo‘l bo‘ylab yuqoriga chiqish - faylni ../../etc/passwd orqali yuklash
• XXE - tashqi obyektlarga ega XML
• Shablon inʼeksiyasi - Jinja/Handlebars/EJS’dagi SSTI
• NoSQL inʼeksiyasi - MongoDB so‘rovlaridagi $ne, $gt operatorlari
• Kriptografiyadan noto‘g‘ri foydalanish - MD5, ECB rejimi, statik IV’dan foydalanish

Claude har bir topilmaga jiddiylik darajasini beradi. Shkala sodda:

• HIGH - autentifikatsiyasiz masofadan foydalanish, barcha foydalanuvchilarga ta’sir qiladigan ma’lumotlar sizishi
• MEDIUM - qo‘shimcha shartlar bilan foydalanish (sessiya talab qilinadi / muayyan kiritma)
• LOW - ehtimoliy yo‘l; hozircha muhim emas, ammo tuzatishga arziydi

Bilish foydali: standart sozlamada Claude DoS, tezlikni cheklash, xotira tugashi, isbotlangan ta’sirsiz ochiq yo‘naltirishlar, regex inʼeksiyasi / ReDoS yoki loglarni soxtalashtirish haqida hisobot bermaydi. Bu shovqinga ko‘milib ketmasligingiz uchun ataylab qilingan. Agar bu toifalar muhim bo‘lsa, qoidalarni kengaytiring (quyidagi yolg‘on ijobiy natijalarni filtrlash bo‘limiga qarang).

Avtomatik tekshiruv uchun GitHub Action’ni qanday sozlash mumkin?#

1-bosqich. API kalitini oling. console.anthropic.com saytiga o‘ting, API kalitini yarating va nusxalang.

2-bosqich. Kalitni repozitoriy sirlariga qo‘shing. GitHub’da: Settings → Secrets and variables → Actions → New repository secret. Uni CLAUDE_API_KEY deb nomlang; qiymati kalitingiz bo‘ladi.

3-bosqich. Workflow faylini yarating. Uni .github/workflows/security.yml nomi bilan saqlang:

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-bosqich. Tarmoqni main’ga qo‘shib birlashtiring. Keyingi PR kelganda action avtomatik ishga tushadi.

Action nima qiladi:

• Har bir ochiq / sinxronlashtirilgan Pull Request’da ishlaydi.
• PR tarmog‘i va main orasidagi farqni oladi.
• Mahalliy /security-review bilan ayni dvigatelni ishga tushiradi.
• Shubhali holat topilgan kod satrlariga bevosita izoh qoldiradi.
• To‘liq hisobotni Job Summary’da ham takrorlaydi.

permissions ichidagi muhim tafsilotlar:

• pull-requests: write - kod satrlariga izoh qoldirish uchun.
• contents: read - kodni o‘qish uchun. write yo‘q. Action kodni o‘zi o‘zgartirmaydi; faqat hisobot beradi.

Bu ruxsatlar to‘plami shaxsiy repozitoriy uchun yetarli. Ommaviy repozitoriyda qayta ishlatiladigan workflow’lardan foydalansangiz, qo‘shimcha ravishda actions: readni ko‘rsatishingiz mumkin.

Yolg‘on ijobiy natijalarni qanday filtrlash va sezgirlikni o‘zgartirish mumkin?#

GitHub Action kiritmalarining to‘liq jadvali (manba: repozitoriy README):

Yolg‘on ijobiy natijalarni filtrlashni sozlash namunasi. .claude/security/false-positives.md faylini yarating:

# Loyihamiz uchun yolg‘on ijobiy natijalarni filtrlash qoidalari

- `src/lib/email/layout.ts` ichidagi har qanday `dangerouslySetInnerHTML` xavfsiz -
  HTML ishonchli shablonlardan yig‘iladi va render paytida emas,
  ma’lumotlar bazasiga yozish vaqtida `sanitize-html` orqali tozalanadi.
- `__tests__/fixtures/*.ts` ichidagi qattiq yozilgan test API kalitlari haqida xabar bermang.
  Barcha kalitlar `sk-test-fake-` bilan boshlanadi.
- `src/lib/admin/migrations.ts` ichidagi SQL satrlarini birlashtirish maqbul - fayl faqat
  root huquqi bilan ishlaydi, kiritma ma’lumotlari esa muhit o‘zgaruvchilaridan olinadi.

Uni workflow’ga ulang:

- 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

Maxsus xavfsizlik tekshiruvi ko‘rsatmalari ham shunga o‘xshaydi. Aynan loyihangiz uchun muhim qoidalar yozilgan fayl yarating:

# Loyihamiz uchun qo‘shimcha tekshiruvlar

- `/api/admin/*` ostidagi har qanday endpoint administrator rolini
  umumiy wrapper orqali tekshirishi shart. Bu wrapper bo‘lmasa, jiddiylik HIGH.
- Barcha YooKassa / CloudPayments webhook’lari tanani tahlil qilishdan oldin
  imzoni tekshirishi shart. Bu bajarilmasa, jiddiylik HIGH.
- Magic-link tokenlari faqat bir marta ishlatilishi kerak (birinchi yaroqli
  so‘rovdan so‘ng ishlatilgan deb belgilanadi). Qayta ishlatiladigan tokenlar MEDIUM jiddiylikka ega.

Bu endi Anthropic’ning tayyor sozlamasi emas: siz Claude har safar qo‘llaydigan qoidalarga loyiha haqidagi tajribangizni ko‘chiryapsiz. “Modeldan ustun metodologiya” degani shu.

Claude uchun kontekst metodologiyasi haqida ko‘proq ma’lumot olish uchun “CLAUDE.md faylini qanday sozlash mumkin” va “Claude Code’dagi Second Brain” qo‘llanmalarini ko‘ring.

Claude nimalarni topa olmaydi va nega: xolis cheklovlar?#

Anthropic sukut bo‘yicha nimalar o‘chirilganini va nima sababdanligini aniq sanab o‘tadi (manba: repozitoriy README):

• Xizmat ko‘rsatishni rad etish (DoS) - shovqin juda ko‘p, ta’siri deyarli doim past.
• So‘rovlar tezligini cheklash masalalari - kodda emas, infratuzilma darajasida hal qilinadi.
• Xotira / protsessor resurslarining tugashi - xuddi shunday.
• Ta’siri isbotlanmagan umumiy kiritma tekshiruvi - har bir maydonni tekshirish yolg‘on ijobiy natijalar ko‘payib ketishiga olib keladi.
• Ochiq yo‘naltirish - ko‘pincha mo‘ljallangan xatti-harakat.

Runtime yoki deploy dalilisiz kod ko‘rigi to‘liq tasdiqlay olmaydigan narsalar:

• Ishlab chiqarish serveri konfiguratsiyasi. NGINX sarlavhalari, CORS siyosatlari, TLS sozlamalari, tinglaydigan portlar. Bularni stend muhitida qo‘lda tekshirish kerak.
• Poyga holatlari. Masalan, bir vaqtda yuborilgan pulni qaytarish so‘rovlari vaqtida mablag‘ni ikki marta sarflash. Statik tahlil shubhali andozani ko‘rsatishi mumkin, ammo parallel xulqni baribir sinash kerak.
• To‘lov biznes-mantiqidagi xatolar. Buyurtma summasi mijoz tomonida hisoblanib, to‘lov provayderiga shunchaki yuborilsa, bu jiddiylik darajasi HIGH bo‘lgan muammo. Ammo to‘lov qanday ishlashi kerakligi haqida aniq kontekstsiz, Claude bu namunani har doim ham ko‘ra olmaydi.
• Ma’lumotlar bazasi darajasidagi IDOR. Agar SELECT * FROM orders WHERE id = $1 so‘rovida WHERE user_id = $session.userId tekshiruvi bo‘lmasa, Claude buni ko‘pincha aniqlaydi. Ammo tekshiruv ORM middleware orqali amalga oshirilsa va Claude ma’lumotlar oqimini to‘liq ko‘ra olmasa, uni o‘tkazib yuborishi mumkin.
• Ijtimoiy muhandislik / fishingga chidamlilik. Buning kodga aloqasi yo‘q.

/security-review’ni dastlabki statik ko‘rik sifatida ishlating. Keyin staging dinamik testlari, rol/ruxsat tekshiruvi, mos SAST va haqiqiy deploy konfiguratsiyasi ko‘rigini bajaring. O‘lchangan qamrov foizi aniqlanmagan.

Tashqi baholash ko‘lami va vaqtini tizim xatari hamda o‘zgarishlaridan tanlang. Bitta buyruq ham, davriy tashqi audit ham 100% xavfsizlik qamrovini isbotlamaydi.

Asl material muallifi vibe loyihasida xavfsizlik tekshiruvini qanday o‘tkazdi#

Nimalar aniqlandi. Ishlab chiqarishda ishlayotgan, ammo tekshirilmagan bosqichdagi o‘rtacha vibe loyihasiga xos manzara: autentifikatsiya oqimi, to‘lov integratsiyasidan keladigan webhook’larni qayta ishlash mantiqi, fayl yuklash va render vaqtida HTML bilan ishlashga oid bir-ikki aniq eslatma haqida bir nechta shubha. Tafsilotlarni ommaga oshkor qilmayman; ayrim tavsiyalar allaqachon qo‘llangan, boshqalari esa hali PR’da. Tasvirlangan loyihada dastlabki scan foydali va tez bo‘lgan; bu audit qamrovi foizi yoki umumiy tugallash vaqtini belgilamaydi.

Yolg‘on ijobiy natija sifatida nimalarni bekor qildim:

• Kiritmani tekshirishdagi regex’lar orqali DoS yuzaga kelishi haqidagi topilmalar - haqiqiy yuklama o‘sha regex’larga tushmaydi.
• Qattiq yozilgan API kaliti haqidagi bitta topilma - u fixture’lardagi aniq fake- prefiksli test kaliti edi.

Qancha vaqt ketdi. Ishga tushirishning o‘zi 4 daqiqa oldi. Hisobotni ko‘rib chiqish 25 daqiqa oldi. Tuzatishlarni testlar bilan qo‘llash taxminan bir soat ketdi. Jami: “boshladim”dan “hammasi main’da”gacha taxminan bir yarim soat. Xuddi shu qamrovdagi tashqi pentest bir kalendar hafta oladi va bir necha o‘n baravar qimmat turadi.

Asosiy xulosa. /security-review tashqi pentest o‘rnini bosmaydi. Muallifning to‘rt daqiqalik scan’idagidek foydali kod topilmalarini berishi mumkin. Tuzatishni ko‘rib sinang, runtime va deploy konfiguratsiyasini alohida tekshiring. Scan loyiha xavfsizlik xatarini yo‘q qilmaydi.

/security-review’ni pre-commit jarayoniga qanday qo‘shish mumkin?#

Oldingi git_commit, --severity HIGH va --fail-on-find hook’i hujjatli ishlaydigan retsept emas, xavfsizlik darvozasi sifatida ishlatilmasin. Bu maqolada sinalgan mahalliy commit-bloklovchi hook yo‘q. Yuqoridagi rasmiy GitHub Action PR topilmasi beradi; PR izohi commit yoki merge’ni to‘sishini bildirmaydi.

Hook’lar haqida to‘liq tushuntirish “Claude Code’dagi Hooks” qo‘llanmasida berilgan.

Muntazam amallar yordamida boshqa yo‘l — /security-review + npm run build + npm run test’ni bitta buyruq bilan bajaradigan pre-deploy-check rutinini yaratish. Qo‘shimcha materiallar Ailoot hujjatlarida mavjud.

Agar MCP serverlaridan foydalansangiz, /security-review topilmalarini hodisalarni boshqarish tizimiga (Sentry, Linear, Notion) ulab, har bir HIGH topilmasini avtomatik topshiriqqa aylantirishingiz mumkin.

/security-review haqida tez-tez beriladigan savollar#

Bitta ishga tushirish qancha turadi? Bu loyiha hajmiga bog‘liq. Mening 30K satrli loyihamda bitta ishga tushirish API balansidan taxminan $0.30–0.50 sarflaydi. Million satrli yirik korporativ repozitoriyda bitta ishga tushirish $5–8 gacha turadi. Bu istalgan SaaS skaner obunasidan bir necha o‘n baravar arzon.

Uni lokalda qanchalik tez-tez ishga tushirish kerak? Kamida har bir ishlab chiqarish relizidan oldin. Muhim commit va PR’dan oldin ham ko‘rib chiqing. Maqolada tasdiqlangan avtomatik commit-bloklovchi hook berilmagan.

Qaysi steklar bilan ishlaydi? Claude o‘qiy oladigan istalgan stek bilan. Muallif kuzatuvlariga ko‘ra, quyidagilar tekshirilgan: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Juda noodatiy tillarda (Erlang, Elixir, Clojure) sifat pastroq, ammo baribir nimanidir topadi.

Claude har safar bir xil “zaiflik”ni topaversa-yu, u aslida zaiflik bo‘lmasa, nima qilish kerak? Uni “nega bu xavfsiz” degan izoh bilan false-positive-filtering-instructionsga qo‘shing. Claude keyingi ishga tushirishlarda bu haqda xabar berishni to‘xtatadi.

Uni faqat muayyan fayllarda ishga tushira olamanmi? Lokal rejimda, ha: shunchaki /security-review src/lib/auth/*.ts buyrug‘ini ishga tushiring. GitHub Action’da faqat joriy PR diff’i tekshiriladi; “muayyan fayllar” deganda odatda shu nazarda tutiladi.

Manbalar#

Qo‘shimcha materiallar Ailoot hujjatlarida mavjud.