GitLab CI-ға SAST және SCA қалай енгізу: кезеңдер, quality gates және .gitlab-ci.yml мысалы

SAST пен SCA GitLab CI-ға test кезеңінде бөлек тапсырмалар (jobs) ретінде енгізіледі: олар әр merge request-те іске қосылады, есеп жасайды, ал quality gate біріктіруді бұғаттау-бұғаттамауды шешеді. «Тек ақпараттандыру» режимінен бастаңыз, сосын сыни табылғылар үшін бұғаттауды қосыңыз. Төменде — пайплайн архитектурасы, конфигурация мысалы және жиі кездесетін қателіктер.

SAST және SCA пайплайнның қай жерінде тұрады

«Солға жылжыту» қағидасы тексерулердің мүмкіндігінше ерте жүретінін және нәтиженің сол merge request-те әзірлеушіге қайтарылатынын білдіреді. Кезеңдердің әдеттегі реттілігі:

1. build — құрастыру және тәуелділіктерді шешу (SCA үшін lock-файлдар немесе тәуелділіктер графы маңызды);
2. test — юнит-тесттер және параллель SAST пен SCA;
3. quality gate — есептерді берілген шектер бойынша тексеру;
4. package / deploy — алдыңғы кезеңдер өтсе ғана орындалады;
5. DAST — деплойдан кейін сынақ стендінде (бөлек тақырып, құрал кластарына шолуды қараңыз).

SAST пен SCA бір-біріне тәуелсіз, сондықтан оларды параллель іске қосу тиімді — бұл пайплайн уақытын ұзартпайды.

GitLab-та «қорапшадан» не бар

GitLab дайын үлгілерді ұсынады. SAST үшін Jobs/SAST.gitlab-ci.yml үлгісін қосу жеткілікті: тапсырмалар әдепкі бойынша test кезеңінде орындалады, ал әр анализатор артефакт ретінде JSON-есеп жасайды. GitLab құжаттамасы бойынша, ашық анализаторлармен базалық сканерлеу барлық тарифтерде қолжетімді, ал GitLab Advanced SAST кеңейтілген анализаторы, merge request-тегі есептер және осалдықтарды басқару — Ultimate тарифінде. SCA үшін GitLab-та dependency scanning бар: ол Ultimate тарифінде қолжетімді, ұсынылатын заманауи тәсіл CycloneDX форматындағы SBOM-ға негізделген (Jobs/Dependency-Scanning.v2.gitlab-ci.yml үлгісі), ал Gemnasium негізіндегі бұрынғы анализатор GitLab 17.9-дан бастап ескірген деп жарияланды. Үшінші тарап шешімдерін (мысалы, SAST үшін DerScanner немесе SCA үшін Sonatype) қолдансаңыз, интеграция логикасы сондай: тапсырма сканерді іске қосады, ал нәтиже шектер бойынша тексеріледі.

.gitlab-ci.yml мысалы

Төменде — жалпы схема. GitLab үлгілері include жолдарымен қосылады, ал шектерді тексеру бөлек кезеңге шығарылған. Атауларды, образдарды және пәрмендерді өз ортаңызға және қолданатын құралдарыңызға бейімдеңіз.

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

include:
  # SAST: GitLab-тың дайын үлгісі, тапсырмалар test кезеңінде орындалады
  - template: Jobs/SAST.gitlab-ci.yml
  # SCA: SBOM негізіндегі dependency scanning (Ultimate тарифі)
  - 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: есептерді шектер бойынша тексеру
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:
    - |
      # Тәуелділіктер есебіндегі сыни және жоғары табылғыларды санаймыз (есеп болса)
      if [ -f gl-dependency-scanning-report.json ]; then
        COUNT=$(jq '[.vulnerabilities[] | select(.severity=="Critical" or .severity=="High")] | length' gl-dependency-scanning-report.json)
        echo "Тәуелділіктердегі Critical/High: $COUNT"
        if [ "$COUNT" -gt 0 ]; then
          echo "Quality gate өтпеді"
          exit 1
        fi
      fi
  # Енгізудің бірінші кезеңінде тек ақпараттандыру үшін сәтсіздікке рұқсат беріңіз
  allow_failure: true

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

Бұл мысалда маңызды нәрселер:

• workflow:rules пайплайнды merge request-те және негізгі тармақта іске қосады. GitLab құжаттамасында атап өтілгендей, әдепкі бойынша SAST тек тармақ пайплайндарында орындалады, сондықтан merge request-тегі тексерулер үшін ережелерді анық баптау керек.
• Quality gate-тегі allow_failure: true параметрі — «тек ақпараттандыру» режимі. Шектерді калибрлегеннен кейін оны алып тастаңыз, сонда pipeline біріктіруді бұғаттай бастайды.
• Репозиторийіңіз lock-файлдарды сақтамаса, оларды build кезеңінде жасап, артефакт ретінде беру керек, әйтпесе SCA тәуелділіктердің толық графын көрмейді.
• Windows-раннерлер мен кейбір архитектуралар үшін GitLab SAST үлгілері қолдау таппайды: Docker немесе Kubernetes executor бар Linux-раннер қажет.
• Есепті талдау пәрменін (jq) GitLab нұсқаңыздың есебінің нақты құрылымына бейімдеңіз немесе кірістірілген саясаттарды қолданыңыз: Ultimate тарифінде шектерді merge request-ті бекіту ережелері арқылы басқаруға болады.

Quality gates: шектерді қалай беру керек

Quality gate — құрастыру әрі қарай өте алмайтын формализацияланған ереже. Енгізудің ұсынылатын жолы:

1. Бұғаттаусыз бір-екі апта. Табылғылар статистикасын жинайсыз, командалармен талқылайсыз.
2. Тек жаңа сыни табылғыларды бұғаттау. Ескі техникалық қарыз жұмысты тоқтатпауы тиіс; өзгеріспен қосылғанды бұғаттаймыз.
3. Шекті кеңейту. Сосын жоғары деңгей, одан кейін лицензиялар мен зиянды пакеттер.
4. Үдеріс бойынша ерекшеліктер. Табылғыны басу — тек негіздемемен және мерзіммен, AppSec келіскен жағдайда.

SCA үшін компоненттер саясаты үшін бөлек ережелер блогы пайдалы: белгілі зиянды пакеттерге және эксплойты бар сыни CVE-ге тыйым салу, лицензияларды шектеу. SBOM қалыптастыру «SBOM деген не» мақаласында сипатталған.

Жиі кездесетін қателіктер

• Бірден бұғаттауды қосу. Командалар жүздеген ескі табылғыны көреді, пайплайн бәрінде «қызыл», бастама қарсылыққа тап болады. Ақпараттандырудан бастаңыз.
• Тек негізгі тармақты сканерлеу. Әзірлеуші мәселені біріктіруден кейін біледі. Нәтиже merge request-те қажет.
• Lock-файлдар жоқ. SCA дәл емес нұсқалар бойынша жұмыс істейді немесе транзитивті тәуелділіктерді өткізіп жібереді.
• Жалған іске қосылуларды елемеу. Ережелерді және басу үдерісін баптамаса, шу құралға деген сенімді жояды.
• Конфигурациядағы құпиялар. Сканерлер токендерін CI-дың қорғалған айнымалыларында немесе құпиялар менеджерінде сақтаңыз (құпияларды басқару), репозиторийде емес.
• Иесі жоқ. Табылғыларды талдауға ешкім жауап бермесе, олар жинала береді. AppSec жауаптысын және командалардағы Security Champions тағайындаңыз.
• Тым ұзақ SAST. Әр коммиттегі толық талдау әзірлеуді баяулатады; merge request-те инкрементті тексерулерді, ал толық талдауды кесте бойынша қолданыңыз.

Бәрінің жұмыс істейтінін қалай тексеру керек

• Сынақ тармағына әдейі осал мысал қосыңыз (мысалы, SQL-инъекция) және SAST оны табатынына көз жеткізіңіз.
• Осал ескі нұсқасы бар тәуелділікті қосып, SCA реакциясын тексеріңіз.
• Есептердің артефакт ретінде сақталатынына және аудиторларға қолжетімді екеніне көз жеткізіңіз.
• Метрикаларды бақылаңыз: пайплайннан өту уақыты, бұғаттау үлесі, жою уақыты. Бағдарламаны дамытуды қалай негіздеу керек, «AppSec-ке бюджетті қалай негіздеу керек» мақаласында сипатталған.

Үдерісті түгел — құралдарды таңдаудан командаларды оқытуға дейін — құру қажет болса, біздің DevSecOps енгізу қызметін және «DevSecOps: неден бастау керек» мақаласын қараңыз.

Табылғылармен жұмысты қалай ұйымдастыру керек

Автоматты сканерлеу түсінікті үдеріс болғанда ғана нәтиже береді. Бірнеше ережеге келісіңіз: жаңа табылғыларды кім талдайды (өзгеріс авторының әзірлеушісі, AppSec немесе Security Champion); сыни және жоғары осалдықтар қандай мерзімде түзетіледі; ерекшеліктер қалай ресімделеді және оларды кім бекітеді; нәтижелер тапсырмалар трекеріне қалай түседі. Merge request-тегі сканерлеу нәтижесі оқуға ыңғайлы болуы тиіс: әзірлеуші файлды, жолды, түсіндірмені және ұсынымды көреді. Табылғы мен түзету арасындағы қадамдар неғұрлым аз болса, құрал соғұрлым көп пайда береді.

Ондаған жобасы бар ірі ұйымдар үшін жалпы қауіпсіздік конфигурациясын бөлек репозиторийге шығарып, оны барлық жобаларда include арқылы қосқан ыңғайлы. Сонда ережелер мен шектер бір жерде өзгереді, ал командалар конфигурацияны қолмен көшірмейді.

Жиі қойылатын сұрақтар

Дереккөздер

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