Kichik jamoa uchun xavfsiz dasturlash jarayoni

Katta kompaniyalarda xavfsiz dasturlash jarayoni alohida jamoa, uzun hujjatlar va qimmat vositalar bilan quriladi. Uch-o'n kishilik jamoada bunga vaqt ham, odam ham yo'q. Natijada xavfsizlik "relizdan keyin ko'ramiz" ro'yxatiga tushadi va rasmiy ekspertiza hisobotida birdaniga o'nlab topilma bo'lib qaytadi.

Bu maqolada kichik jamoa haqiqatda bajara oladigan minimal jarayonni taklif qilamiz: rejalashtirishda o'n besh daqiqalik tahdid tahlili, kod review uchun qisqa ro'yxat, sirlar gigiyenasi, avtomatik CI tekshiruvlari va reliz oldidan nazorat. Har bir qadam mavjud ish oqimiga qo'shiladi, alohida "xavfsizlik bosqichi" talab qilmaydi.

Muammo nimada

Kichik jamoalardagi odatiy holat:

• xavfsizlik bo'yicha qarorlar hech qayerda yozilmaydi va bitta odamning boshida turadi;
• kod review faqat "ishlayaptimi" degan savolga javob beradi;
• .env, kalitlar va test parollari vaqti-vaqti bilan repozitoriyga tushib qoladi;
• bog'liqliklar (composer, npm, pub) yillab yangilanmaydi;
• reliz "tez chiqarish kerak" sharoitida, tekshiruv ro'yxatisiz chiqadi;
• xavfsizlik tekshiruvi birinchi marta faqat rasmiy ekspertizada bo'ladi.

O'z mahsulotimiz (soliq-moliya SaaS platformasi) ekspertizasida veb qismida 6 ta, mobil ilovada 9 ta topilma chiqqan. Ularning aksariyati murakkab hujum emas, balki jarayonda unutilgan narsalar edi: to'lov tasdiqlanmasdan muvaffaqiyat sahifasi ko'rsatilishi, X-Forwarded-Host sarlavhasiga ishonish, brauzerga to'liq marshrutlar ro'yxatining chiqishi, ochiq panel portlari, mobil ilovada root aniqlash va sertifikat pinning yo'qligi. Hammasini yopdik, lekin har biri oddiy checklistda bo'lganda ancha oldin ushlanishi mumkin edi.

Nega bu ekspertiza uchun muhim

Rasmiy ekspertiza tayyor mahsulotni tekshiradi. Har bir topilma — qayta ishlash, qayta topshirish va kutish. Jarayonga xavfsizlikni qo'shish topilmalar sonini kamaytiradi, qolganlarini esa tez yopish imkonini beradi, chunki jamoa nima qayerda ekanini biladi. OWASP SAMM va OWASP ASVS kabi hujjatlar shu yondashuvni tavsiya qiladi; kichik jamoa ulardan kerakli qismni olishi mumkin.

Printsip: xavfsizlik — bu alohida bosqich emas, balki har bir bosqichdagi bir nechta savol.

1. Yengil tahdid modellashtirish

Har bir yangi funksiya uchun (ayniqsa to'lov, autentifikatsiya, fayl yuklash, tashqi integratsiya) rejalashtirishda 15 daqiqa ajrating va to'rtta savolga javob yozing:

1. Nima qilyapmiz? Ma'lumot qayerdan kiradi, qayerda saqlanadi, kimga ko'rinadi. Oddiy chizma yetarli.
2. Nima noto'g'ri ketishi mumkin? STRIDE yordamchi ro'yxat sifatida: o'zini boshqa odam deb ko'rsatish (Spoofing), ma'lumotni o'zgartirish (Tampering), harakatni inkor etish (Repudiation), ma'lumot ochiqlanishi (Information disclosure), xizmatni ishdan chiqarish (Denial of service), huquqni oshirish (Elevation of privilege).
3. Bunga qarshi nima qilamiz? Har bir xavf uchun aniq chora: tekshiruv, cheklov, log.
4. Yaxshi bajardikmi? Choralar test yoki review orqali tasdiqlanadi.

Misol: "to'lov" funksiyasi uchun savol "foydalanuvchi to'lov provayderi tasdiqlamasidan muvaffaqiyat sahifasini ko'ra oladimi?" — bu bizning topilmalarimizdan biri edi. Batafsil: to'lov tasdiqlanmasdan muvaffaqiyat sahifasi.

Javoblarni vazifa (issue) ichida yoki docs/threats/ papkasida qisqa matn sifatida saqlang.

2. Kod review checklisti

Pull request shabloniga qisqa ro'yxat qo'shing. GitHub uchun .github/pull_request_template.md:

### Xavfsizlik
- [ ] Yangi endpoint'larda autentifikatsiya va obyekt darajasida ruxsat tekshiriladi
- [ ] Foydalanuvchi kiritgan ma'lumot validatsiya qilinadi, SQL faqat parametrlangan
- [ ] HTML'ga chiqarishda escape (Blade {{ }}, React'da dangerouslySetInnerHTML yo'q)
- [ ] Fayl yuklashda tur, hajm va saqlash joyi cheklangan
- [ ] Sir, kalit va parol kodda yo'q
- [ ] Loglarda parol, token, shaxsiy ma'lumot yo'q
- [ ] Yangi bog'liqlik bo'lsa: kerakmi, qo'llab-quvvatlanadimi

Reviewer har bir bandni ko'rib chiqadi. Eng ko'p e'tibor talab qiladigan joylar: avtorizatsiya (bir foydalanuvchi boshqasining obyektini ochib bo'lmasligi), biznes mantiq holatlari va tashqi so'rovlar. Laravel uchun misol:

// Yomon: faqat ID bo'yicha
$invoice = Invoice::findOrFail($id);

// Yaxshi: egalik tekshiriladi
$invoice = $request->user()->invoices()->findOrFail($id);
// yoki Policy orqali
$this->authorize('view', $invoice);

Batafsil: IDOR va avtorizatsiya xatolari.

3. Sirlar gigiyenasi

• .env, kalit fayllari, google-services.json kabi konfiguratsiyalar .gitignore da;
• repozitoriyda faqat .env.example qiymatsiz;
• har bir muhit uchun alohida kalitlar, ishlab chiqarish kalitlari dasturchilar kompyuterida emas;
• kalit sizib chiqsa — avval almashtirish, keyin tarixdan tozalash.

Commitdan oldin sirlarni qidirish uchun gitleaks kabi vositani pre-commit hook va CI'ga qo'shing:

gitleaks detect --source . --redact

Tarixda ham tekshiring: bir marta commit qilingan kalit keyingi commitda o'chirilgan bo'lsa ham, git tarixida qoladi. Batafsil: sirlar va kalitlarni boshqarish.

4. CI tekshiruvlari

Avtomatik tekshiruvlar har bir pull request'da ishga tushadi va odam unutadigan narsalarni ushlaydi. GitHub Actions misoli:

name: security
on: [pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Secrets
        uses: gitleaks/gitleaks-action@v2
      - name: PHP dependencies
        run: composer install --no-interaction && composer audit
      - name: JS dependencies
        run: npm ci && npm audit --audit-level=high
      - name: Static analysis
        run: pipx run semgrep --config p/owasp-top-ten --error

Boshlanishda faqat yuqori darajadagi topilmalarda to'xtatish sozlamasini qo'ying, aks holda jamoa tekshiruvni tezda o'chirib qo'yadi. Vaqt o'tishi bilan chegarani pasaytiring. Flutter loyihalari uchun flutter analyze va dart pub outdated, Laravel uchun Larastan (PHPStan) qo'shimcha foyda beradi. Bog'liqliklarni muntazam yangilab turish uchun Dependabot yoki Renovate yoqing.

5. Reliz checklisti

Har bir ishlab chiqarish relizidan oldin (yoki kamida har bir katta reliz oldidan) qisqa ro'yxatdan o'ting:

• APP_DEBUG=false, APP_ENV=production, xato sahifalarida stack trace yo'q;
• xavfsizlik sarlavhalari (HSTS, CSP, X-Content-Type-Options) javobda bor;
• yangi marshrutlar va API endpoint'lar ro'yxati ko'rib chiqilgan, test va debug marshrutlar o'chirilgan;
• migratsiyalar zaxira nusxadan keyin bajariladi;
• mobil ilova uchun: release build, obfuskatsiya yoqilgan, debuggable o'chirilgan, allowBackup=false, cleartext trafik yopiq, APK/IPA nazorat qiymatlari yozib olingan;
• relizni orqaga qaytarish (rollback) yo'li ma'lum.

Bu buyruqlar bilan tez tekshirish mumkin:

curl -sI https://example.uz | grep -iE "strict-transport|content-security|x-content-type|server:"
php artisan route:list --except-vendor | grep -iE "test|debug|telescope"

Tegishli maqolalar: xavfsizlik headerlari, debug rejim va ma'lumot ochiqlanishi, APK/IPA nazorat qiymatlari.

6. Rollar va mas'uliyat

Kichik jamoada alohida xavfsizlik mutaxassisi bo'lmasa ham, bitta "xavfsizlik bo'yicha mas'ul" belgilang. Uning vazifasi hamma narsani o'zi qilish emas, balki:

• CI tekshiruvlari ishlashini va ogohlantirishlar ko'rib chiqilishini kuzatish;
• oyiga bir marta bog'liqliklar va server yangilanishlarini tekshirish;
• yangi zaiflik e'lonlarini (foydalanilayotgan freymvork va kutubxonalar bo'yicha) kuzatib borish;
• hodisa yuz berganda birinchi aloqa nuqtasi bo'lish.

7. Ekspertizadan oldin pre-audit

Yuqoridagi jarayon kundalik xatolarni kamaytiradi, lekin tashqi nigohning o'rnini bosmaydi. Jamoa o'z kodiga o'rganib qoladi va ba'zi narsalarni ko'rmaydi. Rasmiy ekspertizadan oldin mustaqil tekshiruv quyidagilarni beradi:

• ekspertiza tekshiradigan toifalar bo'yicha topilmalar ro'yxati va ularning muhimlik darajasi;
• har bir topilma uchun aniq tuzatish va qayta tekshiruv;
• ekspertizaga topshiriladigan hujjatlar va fayllarning tayyorligi.

Batafsil: pre-audit nima uchun kerak va ekspertizadan oldin checklist.

Qayerdan boshlash

Hammasini bir haftada joriy qilishga urinmang. Amaliy tartib:

1. Birinchi hafta: .gitignore va gitleaks ni sozlang, repozitoriy tarixini sirlar bo'yicha tekshiring, topilgan kalitlarni almashtiring.
2. Ikkinchi hafta: PR shabloniga xavfsizlik bandlarini qo'shing va CI'da composer audit / npm audit ni yoqing.
3. Birinchi oy: reliz checklistini yozing va keyingi relizda undan o'ting; Dependabot yoki Renovate'ni yoqing.
4. Keyingi oylar: statik tahlil qo'shing, muhim funksiyalar uchun tahdid tahlilini odatga aylantiring, chorakda bir marta jarayonni qayta ko'rib chiqing.

Har bir qadamdan keyin jamoa bilan qisqa muhokama qiling: nima qo'shimcha yuk bo'ldi, nima haqiqatan foyda berdi. Jarayon jamoaga mos bo'lmasa, u tezda unutiladi.

Qisqa checklist

• Muhim funksiyalar uchun 15 daqiqalik tahdid tahlili va yozma javoblar
• PR shablonida xavfsizlik bandlari, review ularni tekshiradi
• .env va kalitlar git'da yo'q, gitleaks pre-commit va CI'da
• CI'da composer audit, npm audit, statik tahlil ishlaydi
• Dependabot yoki Renovate yoqilgan
• Reliz checklisti (debug, sarlavhalar, marshrutlar, mobil build sozlamalari)
• Bitta xavfsizlik bo'yicha mas'ul belgilangan
• Rasmiy ekspertizadan oldin mustaqil pre-audit rejalashtirilgan

Xulosa

Kichik jamoa uchun xavfsiz dasturlash — bu katta hujjatlar emas, balki har bir bosqichda takrorlanadigan bir nechta odat. Ular birga ishlaganda ekspertizaga kelgan mahsulotda kutilmagan topilmalar ancha kam bo'ladi. Bizning jarayonda Claude AI agenti kod bazasi, konfiguratsiya va CI sozlamalarini tez ko'rib chiqadi, mutaxassis esa topilmalarni tasdiqlaydi, tuzatadi va jamoangizga jarayonni o'rnatishga yordam beradi.

Mahsulotingiz va jarayoningiz ekspertizaga qanchalik tayyorligini bilmoqchi bo'lsangiz, skanerlash uchun ariza qoldiring. Rasmiy tekshiruvdan oldin teshiklarni yopishga yordam beramiz.