В пайплайн добавлен шаг сканирования образа на уязвимости (например, Trivy), который блокирует деплой при найденных Critical CVE. Как внедрить это без остановки всех релизов из-за шумных/неактуальных находок?

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

Нужно настроить сканер так, чтобы он блокировал пайплайн только по уязвимостям с доступным исправлением (fixed version) выше согласованного порога серьёзности, вести файл допустимых исключений (ignore-list) с обоснованием и сроком пересмотра для ложных срабатываний/неприменимых CVE, и регулярно пересматривать политику, а не блокировать по любому найденному CVE без разбора.

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

сканеры образов (Trivy, Grype) анализируют установленные пакеты и ОС-слои образа против баз CVE и могут возвращать находки без доступного патча (их исправить сборкой нельзя) или неприменимые к реальному пути выполнения кода находки. Жёсткая блокировка по любому Critical CVE без фильтрации быстро приводит к ситуации, когда релизы блокируются уязвимостями, которые невозможно исправить прямо сейчас, и команда начинает искать способы обойти проверку целиком.

Пример кода

example1.shКопировать

trivy image --severity CRITICAL,HIGH --ignore-unfixed \
  --exit-code 1 --ignorefile .trivyignore registry.example.com/myapp:1.5.0

Пример кода

example2.txtКопировать

# .trivyignore
CVE-2023-12345  # ложное срабатывание: пакет не используется в рантайме, см. тикет SEC-421, пересмотр 2024-06-01

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

• На практике. разумная политика — блокировать только там, где есть fixed version (`trivy image --ignore-unfixed`), и держать отдельный список явных исключений с датой истечения, чтобы временно принятый риск не забывался навсегда. Полезно также разделить gate на «блокирует merge/деплой» (Critical с патчем) и «создаёт тикет на исправление» (High/Medium или без патча), чтобы не тормозить разработку, но не терять видимость проблемы.
• Пример. Ожидаемое поведение: пайплайн падает (`exit code 1`) только при обнаружении Critical/High уязвимостей с доступным патчем, не входящих в `.trivyignore`; записи в ignore-файле видны в код-ревью и имеют явный срок пересмотра.

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

• Частые ошибки. включают блокирующий скан сразу в режиме «fail on any vulnerability» без периода адаптации, из-за чего команда массово добавляет сканер в исключения или вовсе отключает шаг; не обновляют базу уязвимостей сканера регулярно, получая неактуальные или, наоборот, пропуская новые находки.