Как встроить сканирование зависимостей (SCA) в CI-пайплайн так, чтобы оно приносило пользу, а не превращалось в источник постоянных ложных блокировок релиза?

Короткий ответ

Сканирование настраивают с чёткими порогами блокировки (например, падать на Critical/High с доступным исправлением), допускают управляемые исключения (allowlist с обоснованием и сроком пересмотра) для ложных срабатываний или неустранимых на данный момент уязвимостей, и разделяют «блокирующую» и «информационную» часть отчёта.

Как это работает подробнее

сканер зависимостей сопоставляет версии пакетов в lock-файле с базой известных уязвимостей и может найти проблему, не влияющую на приложение реально (например, уязвимая функция библиотеки не вызывается в коде) — это создаёт поток ложных или малозначимых срабатываний, если блокировать релиз на любую найденную запись.

Пример кода

security-example-456.yamlКопировать

# Шаг CI: падать только на Critical/High с доступным фиксом
- name: Dependency scan
  run: |
    trivy fs --scanners vuln --severity CRITICAL,HIGH \
      --ignore-unfixed --exit-code 1 ./

Что использовать на практике

• Практика. настраивают пайплайн так, чтобы падать только на уязвимости severity ≥ порога и с опубликованным исправлением; для исключений используют файл подавления (.trivyignore и аналоги) с указанием причины и даты пересмотра, а не бессрочное игнорирование; периодически (не только в момент сборки) перепроверяют зависимости, так как новые CVE находят и для уже выпущенных версий.
• Проверка. Ожидаемое поведение: пайплайн останавливается только когда найдена Critical/High уязвимость, для которой уже есть исправленная версия (--ignore-unfixed отфильтровывает случаи без патча); Medium/Low попадают в отчёт, но не блокируют релиз — это уменьшает количество ложных остановок при сохранении контроля за реально устранимыми серьёзными проблемами.

Подводные камни

• Ошибка. настраивать жёсткую блокировку на любую найденную уязвимость независимо от severity, что приводит к игнорированию алертов командой («шумные» блокировки); добавлять исключения без срока пересмотра, и они остаются навечно даже когда патч давно вышел; сканировать только на этапе сборки образа и не повторять сканирование уже опубликованных артефактов.