Сканирование контейнерных образов на CVE ломается не в scanner, а в цепочке поставки

Сканирование контейнерных образов на CVE ломается не в scanner, а в цепочке поставки

Если в pipeline нет обязательного контроля образа до публикации, уязвимый слой легко уезжает в registry и дальше размножается по кластерам. Риск обычно не в одном критичном CVE, а в накоплении слабых мест: базовый образ, транзитивные пакеты, старые зависимости, забытые тестовые теги.

Минимальная схема защиты выглядит так:
— сканирование при сборке и перед деплоем;
— политика блокировки для critical/high в прод-контуре;
— повторная проверка уже опубликованных образов по расписанию;
— запрет на использование mutable tags без digest-пиннинга;
— отдельный контроль для base image и зависимостей из package manager.

Слабое место большинства внедрений — доверие к одному отчёту. Скрипт в CI видит только то, что собралось сейчас; registry scanner — только то, что уже сохранено; runtime admission control — только то, что попало в кластер. Если эти уровни не связаны, атакующий или невнимательный разработчик обходит защиту обычной пересборкой.

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