Сканирование контейнерных образов без автоматики превращает CVE в проблему релиза

Сканирование контейнерных образов без автоматики превращает CVE в проблему релиза

Ручная проверка образов в CI почти всегда запаздывает: образ уже уехал в registry, а уязвимый пакет — в продовый пайплайн. Автоматизация нужна не ради отчёта, а чтобы остановить сборку до публикации артефакта.

Базовая схема выглядит так:
— триггер на каждый build и на каждый pull request;
— сканирование не только app-layer, но и base image, системных библиотек и зависимостей;
— жёсткий policy gate: критические CVE блокируют merge или promotion;
— отдельный allowlist для осознанных исключений с TTL и владельцем.

Критичная ошибка — сканировать только финальный тег образа. Это пропускает уязвимости, пришедшие из промежуточных слоёв, и делает бессмысленным кеширование. Второй риск — доверять одному движку анализа: разные базы находят разные совпадения, а ложноположительные срабатывания без ручной валидации быстро убивают доверие команды.

Нормальная эксплуатация строится вокруг двух контуров: превентивного и реактивного. Первый — блокирует выпуск при высоком риске. Второй — регулярно пересканирует уже опубликованные образы, потому что CVE появляются в зависимости от состава SBOM, а не только от факта новой сборки.

Настройте автоматизацию так, чтобы результат сканирования был частью артефакта, а не отдельным письмом. Проверяйте логи, истина всегда скрыта в них.