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

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

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

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

Ключевая ошибка — ориентироваться только на число CVE. Смотрите на эксплуатируемость, наличие исправления, затронутый пакет и путь попадания в образ. Часто опаснее не сама уязвимость, а то, что слой с ней тянется в десятки сервисов и повторно собирается из кэша без пересмотра зависимостей.

Минимальный контрольный набор: интеграция со CI/CD, запрет на публикацию образа без отчёта, уведомления в канал команды, политика исключений, отдельный аудит для base image и регулярная очистка устаревших тегов. Проверяйте логи, истина всегда скрыта в них.