GitLab CI’ga SAST va SCA’ni qanday integratsiya qilish: bosqichlar, quality gates va .gitlab-ci.yml namunasi

SAST va SCA GitLab CI’ga test bosqichida alohida topshiriqlar (jobs) sifatida integratsiya qilinadi: ular har bir merge request’da ishga tushadi, hisobot shakllantiradi, quality gate esa birlashtirishni bloklash yoki bloklamaslikni hal qiladi. «Faqat xabardor qilish» rejimidan boshlang, so‘ng muhim topilmalar uchun bloklashni yoqing. Quyida — payplayn arxitekturasi, konfiguratsiya namunasi va odatiy xatolar.

SAST va SCA payplaynda qayerda turadi

«Chapga siljitish» (shift left) tamoyili tekshiruvlar iloji boricha erta o‘tishini va natija dasturchiga o‘sha merge request’ning o‘zida qaytarilishini bildiradi. Bosqichlarning odatiy ketma-ketligi:

1. build — yig‘ish va bog‘liqliklarni aniqlash (SCA uchun lock-fayllar yoki bog‘liqliklar grafi muhim);
2. test — unit-testlar va ular bilan parallel SAST hamda SCA;
3. quality gate — hisobotlarni belgilangan chegaralar bo‘yicha tekshirish;
4. package / deploy — faqat oldingi bosqichlar muvaffaqiyatli o‘tgandagina bajariladi;
5. DAST — deploy’dan keyin test stendida (alohida mavzu, vositalar sinflari sharhiga qarang).

SAST va SCA bir-biriga bog‘liq emas, shuning uchun ularni parallel ishga tushirish foydali — bu payplayn vaqtini oshirmaydi.

GitLab’da «qutidan chiqqan» nimalar bor

GitLab tayyor shablonlarni taqdim etadi. SAST uchun Jobs/SAST.gitlab-ci.yml shablonini ulash yetarli: topshiriqlar odatda test bosqichida bajariladi, har bir analizator esa artefakt sifatida JSON hisobot shakllantiradi. GitLab hujjatlariga ko‘ra, ochiq analizatorlar bilan asosiy skanerlash barcha tariflarda mavjud, kengaytirilgan GitLab Advanced SAST analizatori, merge request’dagi hisobotlar va zaifliklarni boshqarish esa Ultimate tarifida. SCA uchun GitLab’da dependency scanning bor: u Ultimate tarifida mavjud, tavsiya etiladigan zamonaviy yondashuv CycloneDX formatidagi SBOM’ga asoslangan (Jobs/Dependency-Scanning.v2.gitlab-ci.yml shabloni), Gemnasium’ga asoslangan avvalgi analizator esa GitLab 17.9 versiyasidan boshlab eskirgan deb e’lon qilingan. Agar uchinchi tomon yechimlaridan foydalansangiz (masalan, SAST uchun DerScanner yoki SCA uchun Sonatype), integratsiya mantig‘i xuddi shunday: topshiriq skanerni ishga tushiradi, natija esa chegaralar bo‘yicha tekshiriladi.

.gitlab-ci.yml namunasi

Quyida — umumiy sxema. GitLab shablonlari include qatorlari bilan ulanadi, chegaralarni tekshirish esa alohida bosqichga ajratilgan. Nomlar, image’lar va buyruqlarni o‘z muhitingiz va foydalanayotgan vositalarga moslang.

stages:
  - build
  - test
  - security-gate
  - deploy

include:
  # SAST: GitLab’ning tayyor shabloni, topshiriqlar test bosqichida bajariladi
  - template: Jobs/SAST.gitlab-ci.yml
  # SCA: SBOM asosidagi dependency scanning (Ultimate tarifi)
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml
    inputs:
      job_name: "dependency-scanning"
      stage: test

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

build:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

unit-tests:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test

# Quality gate: hisobotlarni chegaralar bo‘yicha tekshirish
security-gate:
  stage: security-gate
  image: alpine:3.20
  needs:
    - job: dependency-scanning
      artifacts: true
      optional: true
  before_script:
    - apk add --no-cache jq
  script:
    - |
      # Bog‘liqliklar hisobotidagi (agar hisobot bo‘lsa) muhim va yuqori topilmalarni sanaymiz
      if [ -f gl-dependency-scanning-report.json ]; then
        COUNT=$(jq '[.vulnerabilities[] | select(.severity=="Critical" or .severity=="High")] | length' gl-dependency-scanning-report.json)
        echo "Bog‘liqliklardagi Critical/High: $COUNT"
        if [ "$COUNT" -gt 0 ]; then
          echo "Quality gate o‘tmadi"
          exit 1
        fi
      fi
  # Joriy etishning birinchi bosqichida faqat xabardor qilish uchun xatoga yo‘l qo‘ying
  allow_failure: true

deploy:
  stage: deploy
  script:
    - echo "Deploy"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Bu namunada nimalar muhim:

• workflow:rules payplaynni merge request’da va asosiy branch’da ishga tushiradi. GitLab hujjatlarida qayd etilishicha, odatda SAST faqat branch payplaynlarida bajariladi, shuning uchun merge request’dagi tekshiruvlar uchun qoidalarni aniq sozlash kerak.
• Quality gate’dagi allow_failure: true parametri — «faqat xabardor qilish» rejimi. Chegaralarni kalibrlagandan so‘ng uni olib tashlang — pipeline birlashtirishni bloklay boshlaydi.
• Agar repozitoriyingizda lock-fayllar saqlanmasa, ularni build bosqichida shakllantirib, artefakt sifatida uzatish kerak, aks holda SCA bog‘liqliklarning to‘liq grafini ko‘rmaydi.
• Windows-runner’lar va ayrim arxitekturalar uchun GitLab SAST shablonlari qo‘llab-quvvatlanmaydi: Docker yoki Kubernetes executor’li Linux-runner kerak.
• Hisobotni tahlil qilish buyrug‘ini (jq) GitLab versiyangiz hisobotining haqiqiy tuzilmasiga moslang yoki o‘rnatilgan siyosatlardan foydalaning: Ultimate tarifida chegaralarni merge request’ni tasdiqlash qoidalari orqali boshqarish mumkin.

Quality gates: chegaralarni qanday belgilash

Quality gate — build keyingi bosqichga o‘ta olmaydigan holatni belgilovchi rasmiylashtirilgan qoida. Joriy etishning tavsiya etiladigan yo‘li:

1. Bir-ikki hafta bloklashsiz. Topilmalar statistikasini yig‘asiz, jamoalar bilan muhokama qilasiz.
2. Faqat yangi muhim topilmalarni bloklash. Eski texnik qarz ishni to‘xtatmasligi kerak; o‘zgarish bilan qo‘shilayotgan narsani bloklaymiz.
3. Chegarani kengaytirish. So‘ng yuqori daraja, keyin litsenziyalar va zararli paketlar.
4. Jarayon bo‘yicha istisnolar. Topilmani bostirish — faqat asoslash va muddat bilan, AppSec bilan kelishilgan holda.

SCA uchun komponentlar siyosati bo‘yicha alohida qoidalar bloki foydali: ma’lum zararli paketlar va eksploiti mavjud muhim CVE’larni taqiqlash, litsenziyalarni cheklash. SBOM shakllantirish «SBOM nima» maqolasida tavsiflangan.

Odatiy xatolar

• Bloklashni darhol yoqish. Jamoalar yuzlab eski topilmalarni ko‘radi, hammada payplayn «qizil», tashabbus qarshilikka uchraydi. Xabardor qilishdan boshlang.
• Faqat asosiy branch’ni skanerlash. Dasturchi muammo haqida birlashtirishdan keyin bilib qoladi. Natija merge request’da kerak.
• Lock-fayllar yo‘q. SCA noaniq versiyalar bo‘yicha ishlaydi yoki tranzitiv bog‘liqliklarni o‘tkazib yuboradi.
• Yolg‘on ishga tushishlarni e’tiborsiz qoldirish. Qoidalar va bostirish jarayoni sozlanmasa, shovqin vositaga ishonchni yo‘qqa chiqaradi.
• Konfiguratsiyada sirlar. Skaner tokenlarini CI’ning himoyalangan o‘zgaruvchilarida yoki sirlar menejerida saqlang (sirlarni boshqarish), repozitoriyda emas.
• Mas’ul yo‘q. Topilmalarni tahlil qilishga hech kim javob bermasa, ular to‘planib boradi. AppSec mas’ulini va jamoalarda Security Champions’ni tayinlang.
• Haddan tashqari uzoq SAST. Har bir commit’da to‘liq tahlil ishlab chiqishni sekinlashtiradi; merge request’da inkremental tekshiruvlardan, to‘liq tahlilni esa jadval bo‘yicha o‘tkazishdan foydalaning.

Hammasi ishlayotganini qanday tekshirish

• Test branch’iga ma’lum zaif namunani (masalan, SQL-inyeksiya) qo‘shing va SAST uni topishiga ishonch hosil qiling.
• Zaif eski versiyali bog‘liqlikni ulang va SCA reaksiyasini tekshiring.
• Hisobotlar artefakt sifatida saqlanayotganiga va auditorlar uchun mavjudligiga ishonch hosil qiling.
• Metrikalarni kuzating: payplaynning o‘tish vaqti, bloklashlar ulushi, bartaraf etish vaqti. Dasturni rivojlantirishni qanday asoslash «AppSec byudjetini qanday asoslash» maqolasida tavsiflangan.

Agar jarayonni to‘liq — vositalarni tanlashdan jamoalarni o‘qitishgacha — qurish kerak bo‘lsa, bizning DevSecOps joriy etish xizmatimizga hamda «DevSecOps: nimadan boshlash kerak» maqolasiga qarang.

Topilmalar bilan ishni qanday tashkil etish

Avtomatik skanerlash faqat tushunarli jarayon bo‘lgandagina natija beradi. Bir necha qoidada kelishib oling: yangi topilmalarni kim tahlil qiladi (o‘zgarish muallifi, AppSec yoki Security Champion); muhim va yuqori zaifliklar qanday muddatlarda tuzatiladi; istisnolar qanday rasmiylashtiriladi va ularni kim tasdiqlaydi; natijalar vazifalar trekeriga qanday tushadi. Merge request’dagi skanerlash natijasi o‘qishga qulay bo‘lishi kerak: dasturchi faylni, qatorni, tushuntirish va tavsiyani ko‘radi. Topilma va tuzatish orasida qadamlar qancha kam bo‘lsa, vositadan qaytim shuncha yuqori.

O‘nlab loyihalari bor yirik tashkilotlar uchun umumiy xavfsizlik konfiguratsiyasini alohida repozitoriyga chiqarib, barcha loyihalarda include orqali ulash qulay. Shunda qoidalar va chegaralar bir joyda o‘zgaradi, jamoalar esa konfiguratsiyani qo‘lda nusxalamaydi.

Ko‘p beriladigan savollar

Manbalar

• GitLab Docs: Static Application Security Testing (SAST)
• GitLab Docs: Dependency scanning
• GitLab Docs: Dependency scanning using SBOM