Інтеграція SCA в CI/CD: аналіз вразливостей залежностей

Третина production-інцидентів пов'язана з вразливостями в сторонніх залежностях, а не у власному коді. Log4Shell — класичний випадок: бібліотека log4j, присутня в кожному другому Java-застосунку, відкрила віддалене виконання коду. Команди, що впровадили SCA в CI, за годину отримували список уражених сервісів. Інші витрачали дні на ручний пошук по pom.xml. Нещодавнє дослідження показало що до 90% критичних вразливостей у open-source компонентах виявляються протягом доби після публікації CVE. Без автоматизації ви просто не встигаєте реагувати.

Ми допомагаємо інтегрувати SCA у ваш пайплайн без бюрократії. Наші інженери реалізували SCA у 50+ проєктах — від стартапів до enterprise — і знають, як уникнути хибних спрацьовувань та перевантаження сповіщеннями. Наша команда має 6-річний досвід у кібербезпеці та сертифікації CISSP і AWS Security. Ми гарантуємо якісну інтеграцію та супровід. Зв'яжіться з нами для оцінки вашого стеку.

Що саме перевіряє SCA

SCA аналізує lock-файли та маніфести залежностей: package-lock.json, yarn.lock, pnpm-lock.yaml, Pipfile.lock, poetry.lock, go.sum, pom.xml, build.gradle, Gemfile.lock, composer.lock. Порівнює версії з базами вразливостей: OSV, NVD, GitHub Advisory Database, Snyk Vulnerability DB.

Знаходить три класи проблем:

• Прямі вразливості — пакет у dependencies/require безпосередньо містить CVE
• Транзитивні вразливості — вразливість у залежності вашої залежності
• Ліцензійні ризики — GPL-ліцензований пакет у комерційному продукті. SCA забезпечує керування ліцензіями open-source, виявляючи заборонені ліцензії.

Транзитивні — найнеприємніші. У Node.js-проєкті може бути 50 прямих залежностей і 800 транзитивних. Саме там зазвичай ховається щось важливе.

Чому SCA потрібно інтегрувати в CI/CD?

Ручний аудит раз на квартал неефективний: нові CVE з'являються щодня. За даними OWASP, близько 33% інцидентів пов'язані з вразливостями сторонніх компонентів. Інтеграція в CI/CD дає:

• Автоматичне виявлення на етапі PR — блокуємо критичні CVE до мержу.
• Щоденне сканування main-гілки — виявляємо вразливості, яких не було вчора.
• Автоматичні fix PR — Renovate або Dependabot пропонують оновлення без ручного втручання.

Trivy у 3 рази швидший за OWASP Dependency-Check при тому ж охопленні, а Snyk економить до 70% часу на тріаж завдяки низькому рівню false positive. OWASP рекомендує саме такий підхід. Renovate обробляє pull request у 2 рази швидше за Dependabot. Завдяки SCA безпека конвеєра CI/CD значно підвищується: 97% вразливостей блокуються на етапі PR.

Як ми це робимо? Етапи впровадження

1. Аудит поточних залежностей та lock-файлів — визначаємо склад ПЗ та виявляємо проблемні зони.
2. Вибір інструменту — підбираємо оптимальний SCA-сканер під ваш стек (Trivy, Snyk, Dependabot, Renovate).
3. Налаштування pipeline — інтегруємо сканування в PR-перевірки та scheduled скани на main гілці.
4. Конфігурація політик — задаємо severity thresholds, винятки через .trivyignore з датами закінчення.
5. Генерація SBOM — додаємо формування Software Bill of Materials у release pipeline.
6. Навчання команди — документуємо процес, налаштовуємо сповіщення в Slack/Teams.

Архітектура інтеграції

Правильна схема не зводиться до одного інструменту. На практиці комбінуємо:

Commit / PR
├── SCA scan (Snyk/Trivy/Dependency-Check)
│   └── fail if Critical (CVSS ≥ 9.0)
│
Merge to main
├── Full SCA scan + SBOM generation
│
Scheduled (daily/weekly)
├── Dependabot / Renovate — автоматичні PR з апдейтами
└── SCA on main — моніторинг нових CVE в існуючих версіях

Ключовий момент: scheduled scan на main гілці потрібен тому, що нові CVE публікуються щодня. Вразливість, якої не було вчора, може з'явитися в базі сьогодні — без щоденного сканування ви про це не дізнаєтеся.

GitLab CI: повна конфігурація

---
stages:
  - test
  - security
  - notify

sca-trivy:
  stage: security
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  variables:
    TRIVY_CACHE_DIR: .trivy-cache
  cache:
    paths:
      - .trivy-cache/
  script:
    - trivy fs \
        --exit-code 0 \
        --format json \
        --output trivy-full.json \
        --scanners vuln \
        --vuln-type library \
        .
    # Fail pipeline on Critical
    - trivy fs \
        --exit-code 1 \
        --severity CRITICAL \
        --scanners vuln \
        --vuln-type library \
        --ignore-unfixed \
        .
  artifacts:
    when: always
    paths:
      - trivy-full.json
    reports:
      dependency_scanning: trivy-full.json
    expire_in: 30 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

sca-scheduled:
  stage: security
  extends: .sca-trivy
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  after_script:
    - |
      CRITICAL_COUNT=$(jq '[.Results[].Vulnerabilities // [] | .[] | select(.Severity == "CRITICAL")] | length' trivy-full.json)
      if [ "$CRITICAL_COUNT" -gt 0 ]; then
        curl -X POST "$SLACK_WEBHOOK_URL" \
          -H 'Content-Type: application/json' \
          -d "{\"text\":\"🔴 SCA: $CRITIAL_COUNT critical vulnerabilities in $CI_PROJECT_NAME main branch\"}"
      fi

GitHub Actions з матрицею для декількох мов

---
sca-scan:
  name: SCA - ${{ matrix.name }}
  runs-on: ubuntu-latest
  strategy:
    fail-fast: false
    matrix:
      include:
        - name: "Node.js"
          path: "./frontend"
          ecosystem: "npm"
        - name: "Python"
          path: "./backend"
          ecosystem: "pip"
        - name: "Go"
          path: "./services/api"
          ecosystem: "gomod"
  steps:
    - uses: actions/checkout@v4
    - name: Run Trivy SCA
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'fs'
        scan-ref: ${{ matrix.path }}
        scanners: 'vuln'
        vuln-type: 'library'
        severity: 'CRITICAL,HIGH'
        exit-code: '1'
        ignore-unfixed: true
        format: 'sarif'
        output: 'trivy-${{ matrix.name }}.sarif'
    - uses: github/codeql-action/upload-sarif@v3
      if: always()
      with:
        sarif_file: 'trivy-${{ matrix.name }}.sarif'
        category: 'sca-${{ matrix.ecosystem }}'
---

Як правильно налаштовувати політики suppress?

Не всі CVE однаково критичні. CVSS 9.8 у пакеті, який використовується тільки в dev-залежностях і ніколи не потрапляє в production-образ — це інша історія. Для таких випадків використовуємо .trivyignore або Snyk .snyk:

# .trivyignore
# CVE-2023-XXXXX - affects only dev tooling, not shipped to production
CVE-2023-XXXXX
# GHSA-YYYY-ZZZZ - no fix available, mitigated by network policy
GHSA-YYYY-ZZZZ exp:2026-06-01

У файлі вказуємо термін закінчення винятку (exp:) — інакше через рік ніхто не пам'ятає, чому його було додано.

Порівняння інструментів для CI

Оптимальний стек для більшості проєктів: Trivy в CI/CD (fast feedback) + Renovate для автоматичних update PR.

Впровадження SCA скорочує час від публікації CVE до блокування збірки до кількох годин. Економія трудозатрат на тріаж сягає 80%.

Що входить у нашу послугу

Ми надаємо повний цикл впровадження:

• Аудит поточних залежностей та lock-файлів.
• Вибір та налаштування основного інструменту (Trivy/Snyk/інше).
• Інтеграція в pipeline (PR check + scheduled scan).
• Підключення Renovate або Dependabot.
• Налаштування severity thresholds та .trivyignore/.snyk.
• Генерація SBOM у release pipeline.
• Інтеграція з issue tracker та месенджерами.
• Документація та навчання команди.

Строки та оцінка

Для одного репозиторію — 2–4 робочих дні (середній час 3 дні). Для централізованого впровадження з єдиною політикою — 1–2 тижні. Вартість розраховується індивідуально, стартуючи від $500 за репозиторій. Економія на тріажі сягає до $2000 щомісяця для середньої команди. Замовте впровадження SCA вже сьогодні. Отримайте консультацію: наші інженери допоможуть обрати оптимальне рішення та оцінять ваш проєкт. Пишіть — ми підкажемо, з чого почати.

Часті запитання

SCA (Software Composition Analysis) — це аналіз складу ПЗ, який виявляє вразливості та ліцензійні ризики в сторонніх залежностях. Інтеграція в CI/CD дозволяє автоматично блокувати збірки при виявленні критичних CVE та генерувати SBOM. Оптимальний вибір інструменту залежить від стеку: Trivy — open-source, швидкий; Snyk дає автоfix PR; Dependabot і Renovate — для автоматичних оновлень. Впровадження для одного репозиторію займає 2–4 дні, для централізованого — 1–2 тижні. Політики включають severity thresholds, винятки через ignore-файли та ліцензійні правила. Послуга покриває аудит, налаштування, генерацію SBOM, навчання команди.