SAST, DAST va IAST: CI/CD’da xavfsizlik testlarini avtomatlashtirish

Farq bitta jadvalda

SAST (static application security testing) manba kodni ishga tushirmasdan tahlil qiladi. DAST (dinamik testlash) ishlayotgan ilovaga xuddi hujumchi kabi haqiqiy so‘rovlar yuboradi. IAST (interaktiv testlash) ishlayotgan ilova ichiga agent o‘rnatadi va testlar yoki QA uni sinayotganda ma’lumotlar harakatini kuzatadi.

Hech bir yondashuv boshqasining o‘rnini bosmaydi: har biri xavflarning o‘z qismini ko‘radi.

Har biri nimani topadi va nimani o‘tkazib yuboradi

SAST yaxshi topadi:

• kiritilgan ma’lumot xavfli chaqiruvlarga yetib boradigan injection’lar (SQL, shell, fayl yo‘llari);
• kodga yozib qo‘yilgan sirlar va zaif kriptografiya;
• kodda ko‘rinadigan xavfsiz bo‘lmagan freymvork sozlamalari.

SAST o‘tkazib yuboradi: server va TLS konfiguratsiyasini, faqat ishlash vaqtida paydo bo‘ladigan muammolarni va biznes-mantiq xatolarining ko‘pchiligini. U soxta signallar ham beradi: ma’lumot boshqa joyda tekshirilganmi, har doim ham aniq emas.

DAST yaxshi topadi:

• yetishmayotgan xavfsizlik sarlavhalari, cookie bayroqlari, ochiq qolgan debug sahifalar;
• reflected XSS va tashqaridan chaqirish mumkin bo‘lgan ayrim injection’lar;
• haqiqiy server, proksi va TLS konfiguratsiyasidagi xatolar.

DAST o‘tkazib yuboradi: yetib bora olmaydigan qismlarni (murakkab kirish ortidagi sahifalar, ko‘p bosqichli ssenariylar) va qaysi qatorni tuzatish kerakligini aytmaydi.

IAST ikkala nuqtai nazarni birlashtiradi va soxta signallar kamroq bo‘ladi, lekin u faqat testlaringiz bajaradigan kodni ko‘radi, agent esa sizning runtime’ingizni qo‘llab-quvvatlashi kerak. Yetuk open-source variantlar kam, shuning uchun aksariyat jamoalar SAST va DAST’dan boshlaydi.

Qaysi vositalardan boshlash kerak

• Semgrep — o‘qilishi oson qoidalar va ko‘plab tillar uchun hamjamiyat qoidalar to‘plamlariga ega tez SAST. O‘z qoidalaringiz ular qidiradigan kodga o‘xshab ko‘rinadi.
• CodeQL — chuqur semantik tahlil, GitHub code scanning’da mavjud.
• OWASP ZAP — eng keng tarqalgan open-source DAST. Baseline scan passiv va umumiy muhitlar uchun xavfsiz; full scan faol hujum qiladi, uning joyi izolyatsiya qilingan staging’da.
• Bog‘liqliklar va sirlar skanerlari (Dependabot, Gitleaks va shunga o‘xshashlar) SAST qoidalari odatda qamramaydigan narsalarni yopadi.

GitHub Actions’da minimal sozlama

SAST har bir pull request’da, DAST esa jadval bo‘yicha staging’ga qarshi:

name: security
on:
  pull_request:
  schedule:
    - cron: "0 2 * * *"

jobs:
  semgrep:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep scan --config p/default --error

  zap-baseline:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          docker run --rm -v "$PWD:/zap/wrk" ghcr.io/zaproxy/zaproxy:stable \
            zap-baseline.py -t https://staging.example.com -c zap-rules.conf

--error bayrog‘i topilmalar bo‘lsa Semgrep vazifasini xato bilan yakunlaydi. zap-rules.conf fayli ZAP’ga qaysi qoidalar FAIL, WARN berishi yoki e’tiborsiz qoldirilishini aytadi — shunday qilib build’ni nima buzishini o‘zingiz hal qilasiz. Action va image versiyalarini o‘z yangilash siyosatingiz bo‘yicha qotiring.

Soxta signallarga g‘arq bo‘lmaslik uchun

1. «Faqat hisobot» rejimida boshlang. Natijalarni yig‘ing, saralang, keyin bloklashni yoqing.
2. Faqat ishonchli va yuqori darajadagi qoidalarda bloklang. Qolgani — dashboard yoki haftalik ko‘rib chiqishga.
3. Pull request’da faqat diff’ni skanerlang. Dasturchilar hozirgina yozganini tuzatadi; eski topilmalar alohida backlog’ga tushadi. Semgrep bazaviy commit’ga nisbatan diff-aware skanerlashni qo‘llab-quvvatlaydi.
4. Sababi bilan bostiring. Inline ignore (nosemgrep) yoki «nima uchun» degan izohli qoidalar konfiguratsiyasidan foydalaning — keyingi odam qarorni tushunsin.
5. O‘z shablonlaringiz uchun o‘z qoidalaringizni yozing — masalan, «raw SQL helper’imizni hech qachon satrlar konkatenatsiyasi bilan chaqirmaslik». Ulardan deyarli shovqin bo‘lmaydi.
6. Mas’ul shaxs tayinlang. Kimdir yangi qoidalar natijalarini ko‘rib, konfiguratsiyani sozlab turishi kerak, aks holda vositaga e’tibor bermay qo‘yishadi.
7. DAST’ga avtorizatsiya bering. Test akkaunti ZAP’ga faqat kirish sahifasigacha emas, haqiqiy ilovagacha yetib borish imkonini beradi.

Ko‘p uchraydigan xatolar

• Faol DAST’ni production yoki umumiy ma’lumotlar bazasiga qarshi ishga tushirish.
• Birinchi kunning o‘zida barcha qoidalarni yoqish va har bir build’ning yiqilishi.
• Toza hisobotni xavfsizlik isboti deb qabul qilish. Vositalar biznes-mantiqingizni tushunmaydi — code review va tahdidlarni modellashtirish baribir kerak.
• Hisobotlarni hech qayerda saqlamaslik. Relizlar orasidagi dinamikani solishtirish uchun artefaktlarni saqlang.