Безпека DevOps Pipeline у 2026: SAST, DAST, Supply Chain та Питання на Співбесіді

Безпека DevOps pipeline вимагає інтеграції перевірок безпеки на кожному етапі CI/CD процесу, від pre-commit хуків до моніторингу продакшену. Звіт Datadog State of DevSecOps 2026 показує, що 87% організацій експлуатують сервіси з принаймні однією відомою вразливістю, яку можна експлуатувати, тоді як атаки на ланцюг постачання програмного забезпечення коштують світовій економіці понад 80 мільярдів доларів щорічно.

SAST: Статичний Аналіз, що Виявляє Вразливості до Merge

Static Application Security Testing (SAST) аналізує вихідний код без його виконання. Інструмент парсить кодову базу, будує абстрактне синтаксичне дерево та зіставляє патерни з відомими сигнатурами вразливостей. Запуск SAST на кожному pull request виявляє SQL injection, XSS та жорстко закодовані облікові дані до того, як код потрапить до основної гілки.

Semgrep став де-факто стандартом SAST з відкритим кодом у 2026 році. На відміну від сканерів на основі регулярних виразів, Semgrep розуміє структуру коду та підтримує власні правила в YAML.

# .github/workflows/sast.yml
name: SAST Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep:latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        run: semgrep scan --config=auto --sarif --output=semgrep.sarif
        
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

Прапорець --config=auto завантажує правила спільноти, що відповідають виявленим мовам. Вивід SARIF інтегрується з вкладкою GitHub Security для відстеження знахідок з часом.

DAST: Runtime Тестування, що Знаходить те, що Пропускає Статичний Аналіз

Dynamic Application Security Testing (DAST) атакує працюючий застосунок для виявлення вразливостей, які проявляються лише під час виконання. Порушена автентифікація, помилки авторизації та вади бізнес-логіки вимагають реальних HTTP-запитів для виявлення. SAST не знайде того, що адміністративний endpoint не має належного контролю доступу, але DAST спробує отримати до нього доступ без облікових даних та позначить експозицію.

OWASP ZAP залишається найбільш поширеним DAST-інструментом з відкритим кодом. ZAP 3.0, випущений на початку 2026 року, додав нативну підтримку сканування GraphQL та gRPC.

# .github/workflows/dast.yml
name: DAST Scan

on:
  deployment:
    types: [created]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"'
          
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

DAST запускається після деплойменту, оскільки потребує живої цілі. Staging-середовище слугує тестовою поверхнею, ізолюючи продакшен від трафіку сканування.

SCA: Сканування Залежностей на Відомі Вразливості

Software Composition Analysis (SCA) сканує залежності проти баз даних вразливостей, таких як National Vulnerability Database та GitHub Advisory Database. Одна вразлива транзитивна залежність може експонувати весь застосунок. Звіт Datadog 2026 показав, що 42% сервісів залежать від бібліотек, які більше не активно підтримуються.

Trivy сканує контейнери, файлові системи та git-репозиторії на вразливості в одному бінарному файлі. Генерує вивід SBOM у форматах CycloneDX та SPDX.

# .github/workflows/sca.yml
name: Dependency Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'  # Щодня о 6:00

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

Заплановане щоденне сканування виявляє щойно розкриті CVE навіть без змін коду. Фільтрація до CRITICAL та HIGH запобігає втомі від алертів через знахідки низького ризику.

Безпека Ланцюга Постачання: SBOM та SLSA Provenance

EU Cyber Resilience Act, з обов'язками звітності, що набувають чинності у вересні 2026, вимагає генерації Software Bill of Materials (SBOM) для продуктів, що продаються в ЄС. SBOM перелічує кожен компонент у програмному забезпеченні, включаючи прямі залежності, транзитивні залежності та їх версії.

SLSA (Supply-chain Levels for Software Artifacts) доповнює SBOM, верифікуючи спосіб збірки програмного забезпечення. SBOM відповідає на питання "які компоненти є в цьому програмному забезпеченні?", тоді як SLSA відповідає на "чи можна довіряти процесу збірки?"

# .github/workflows/supply-chain.yml
name: Supply Chain Security

on:
  push:
    tags:
      - 'v*'

jobs:
  build-with-provenance:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .
        
      - name: Generate SBOM
        uses: anchore/sbom-action@v0.17.0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.json
          
      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3.7.0
        
      - name: Sign image and attach SBOM
        run: |
          cosign sign --yes myapp:${{ github.ref_name }}
          cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }}
          cosign sign --yes --attachment sbom myapp:${{ github.ref_name }}

Cosign від Sigstore підписує артефакти за допомогою безключового підписування, що підтримується центром сертифікації Fulcio. Підпис пов'язує артефакт з CI workflow, що його створив, дозволяючи верифікувати, що образ походить з довіреного pipeline.

Виявлення Секретів: Перша Лінія Захисту

Жорстко закодовані секрети залишаються найпоширенішою знахідкою безпеки в кодових базах. AWS access keys, паролі до баз даних та API токени, закомічені в систему контролю версій, спричиняли витоки на будь-якому масштабі. Виявлення секретів запускається pre-commit, щоб заблокувати облікові дані до того, як вони потраплять до репозиторію.

Gitleaks виявляє секрети за допомогою regex-патернів та аналізу ентропії. Pre-commit хук запобігає коміту секретів.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']

# .github/workflows/secrets.yml
name: Secrets Detection

on:
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          
      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Опція fetch-depth: 0 клонує повну історію, дозволяючи Gitleaks сканувати всі коміти в PR, а не лише останній.

Питання на Співбесіді DevSecOps: Що Питають Рекрутери

Співбесіди DevSecOps оцінюють як знання безпеки, так і практичний досвід CI/CD. Наведені нижче питання часто з'являються на співбесідах 2026 року на позиції senior DevOps та platform engineering. Більше питань про безпеку pipeline можна знайти в модулі CI/CD Pipeline Security interview.

"Як впровадити shift-left безпеку в існуючому pipeline?"

Shift-left безпека переносить тестування раніше в циклі розробки. Практична реалізація включає додавання pre-commit хуків для виявлення секретів, SAST-сканування на pull request та SCA-перевірок у фазі збірки. Ключем є інкрементальне впровадження: починати з виявлення секретів, оскільки воно має найнижчий рівень хибнопозитивних спрацювань та найвищий сигнал, потім додати SCA для відомих CVE, потім налаштувати правила SAST для зменшення шуму перед увімкненням як блокуючої перевірки.

"Поясніть різницю між SAST та DAST. Коли використовувати кожен з них?"

SAST аналізує вихідний код без виконання. Знаходить SQL injection, XSS та незахищену криптографію через зіставлення патернів зі структурою коду. SAST запускається рано, на кожному PR, оскільки потребує лише коду.

DAST атакує працюючий застосунок. Знаходить обхід автентифікації, порушений контроль доступу та injection-вразливості, які проявляються лише під час виконання. DAST запускається після деплойменту проти staging-середовища.

Обидва доповнюють один одного. SAST виявляє помилки кодування до merge; DAST верифікує, що задеплоєний застосунок поводиться безпечно. Зрілий pipeline запускає обидва.

"Що таке SBOM і чому він потрібен?"

Software Bill of Materials перелічує кожен компонент у програмному забезпеченні, включаючи прямі та транзитивні залежності з точними версіями. Регуляторні вимоги, такі як EU Cyber Resilience Act, вимагають генерації SBOM для продуктів, що виходять на ринок ЄС з вересня 2026.

Практично SBOM дозволяє швидке реагування на інциденти. Коли з'являється нове CVE, команда безпеки може запитати базу даних SBOM, щоб ідентифікувати кожен сервіс, що запускає вразливий компонент, замість ручного сканування всіх репозиторіїв.

"Як запобігти втомі від алертів у інструментах безпеки?"

Втома від алертів виникає, коли розробники ігнорують знахідки безпеки через занадто низьке співвідношення сигнал-шум. Запобігання вимагає налаштування кожного інструменту перед увімкненням блокуючих перевірок. Для SAST слід вимкнути правила, що генерують хибнопозитивні спрацювання в кодовій базі, та вмикати їх поступово після очищення. Для SCA зосередитися на знахідках CRITICAL та HIGH з відомими експлойтами. Для DAST налаштувати базові сканування, щоб виключити хибнопозитивні спрацювання з майбутніх запусків.

Метрикою для відстеження є час виправлення реальних вразливостей. Якщо це число зростає, розробники ігнорують алерти.

Безпека Контейнерів та Runtime

Сканування образів контейнерів виявляє вразливості до деплойменту. Runtime-безпека моніторить контейнери в продакшені на аномальну поведінку. Комбінація адресує як відомі вразливості (CVE в базових образах), так і невідомі загрози (скомпрометовані контейнери, криптомайнери).

Trivy сканує образи як частину build pipeline. Falco моніторить runtime-поведінку за допомогою eBPF.

# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [main]

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
        
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true

Прапорець ignore-unfixed: true пропускає вразливості без доступних виправлень. Це запобігає блокуванню деплойментів для CVE, які наразі неможливо виправити.

Для runtime-безпеки правила Falco виявляють підозрілу активність у працюючих контейнерах. Модуль container supply chain security детально охоплює підписування образів та admission control.

Безпека IaC: Сканування Terraform та Kubernetes Маніфестів

Infrastructure as Code вводить ризики безпеки на рівні конфігурації. Надмірно дозвільні IAM-політики, публічно доступні S3-бакети та незашифровані бази даних є результатом незахищених налаштувань за замовчуванням у IaC-шаблонах.

Checkov сканує Terraform, CloudFormation, Kubernetes, Helm та Dockerfile на неправильні конфігурації.

# .github/workflows/iac-scan.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'k8s/**'
      - 'helm/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          framework: terraform,kubernetes,helm
          output_format: sarif
          output_file_path: checkov.sarif
          soft_fail: false
          
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif

Фільтр шляхів забезпечує, що IaC-сканування запускається лише при змінах файлів інфраструктури, зменшуючи час CI для змін лише застосунку.

Повний DevSecOps Pipeline на 2026 Рік

Готовий до продакшену DevSecOps pipeline у 2026 інтегрує ці інструменти на кожному етапі:

• Pre-commit: Gitleaks (секрети), опціонально локальний SAST
• Pull request: Semgrep (SAST), Trivy (SCA), Checkov (IaC)
• Build: Сканування образів контейнерів, генерація SBOM
• Pre-deploy: Підписування образів з Cosign, admission control з Kyverno
• Post-deploy: DAST з ZAP проти staging
• Runtime: Falco для моніторингу контейнерів, управління безпековою позицією хмари

Безкоштовний стек (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) покриває кожну категорію. Комерційні інструменти додають централізовані дашборди, управління політиками та зменшені зусилля на налаштування, але охоплення безпеки досяжне без ліцензійних витрат.

Організації, що готуються до ролей DevSecOps, повинні практикуватися в побудові цих pipeline в особистих проєктах. Модуль cloud identity and secrets management охоплює сторону управління секретами рівняння.