Интеграция SCA в CI/CD: анализ уязвимостей зависимостей

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

Мы помогаем интегрировать SCA в ваш пайплайн без бюрократии. Наши инженеры реализовали SCA в 20+ проектах — от стартапов до enterprise — и знают, как избежать ложных срабатываний и перегрузки уведомлениями. Свяжитесь с нами для оценки вашего стека.

Что именно проверяет 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-licensed пакет в коммерческом продукте

Транзитивные — самые неприятные. В 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 рекомендует именно такой подход.

Как мы это делаем? Этапы внедрения

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:
    - |
      # Отправить отчёт в Slack если найдены уязвимости
      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: $CRITICAL_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 рабочих дня. Для централизованного внедрения с единой политикой — 1–2 недели. Стоимость рассчитывается индивидуально, зависит от количества проектов, используемого стека и требуемого уровня автоматизации.

Закажите внедрение SCA уже сегодня. Получите консультацию: наши инженеры помогут выбрать оптимальное решение и оценят ваш проект. Пишите — мы подскажем, с чего начать.