<b>Сканирование контейнерных образов должно быть частью пайплайна, а не ручной проверкой перед релизом</b>

<b>Сканирование контейнерных образов должно быть частью пайплайна, а не ручной проверкой перед релизом</b>

Если образ собирается без контроля, CVE уезжают в registry вместе с артефактом и живут там до следующего инцидента. Автоматизация нужна не для галочки, а чтобы каждый push проходил одинаковую процедуру: разбор состава образа, сопоставление пакетов с базой уязвимостей, отказ при критичных находках и сохранение отчёта в журнале сборки.

Практически это делается так: • сканирование на этапе CI до публикации в registry; • повторная проверка уже размещённых образов по расписанию; • политика блокировки только для критичных и эксплуатируемых CVE, иначе вы получите постоянный шум и ручные обходы; • исключения оформляются отдельно, с TTL и владельцем, а не в комментариях к job. Особенно важно сканировать не только application layer, но и базовый дистрибутив, библиотечный стек, package manager metadata и конфигурацию запуска.

Ключевой риск — ложное чувство безопасности. Сканер не видит runtime-состояние, секреты в переменных, уязвимости в sidecar и ошибки прав доступа в манифестах. Поэтому отчёт должен уходить в SIEM или систему трекинга, а результаты — коррелироваться с SBOM, политиками admission control и данными о фактическом использовании пакетов.

Если сканирование не встроено в pipeline, у вас нет процесса, есть разовая проверка. Проверяйте логи, истина всегда скрыта в них.