Поговорим о такой возможности/проверке/контроле как блокировать деплоймент на основании какой-то информации об известных уязвимостях. Это прямо мечта многих безопасников) НО реальная жизнь показывает, что с этим может быть множество проблем вплоть до падения прода. В общем, это классно в теории, а на практике до тех пор, пока вы не уроните прод.

И так, что же может пойти нет?!
1) Допустим, пройдя все проверки, выкатывается образ и у него 0 уязвимостей (фантастика, но пускай).
2) Далее происходит обновление feed об уязвимостях и с его учетом у нас в том же самом образе, где минуту назад было 0, появились какие-то уязвимости (critical, high, medium, low)!
3) (Чисто как факт - в проде уже работает уязвимое приложение, через которое можно скомпрометировать систему)
4) ReplicaSets controller решает, что нужны еще Pod с тем самым образом. Это может быть по многим причинам: сработал HPA, какие-то Pods аварийное завершились по OOM, упала Node и утащила за собой эти Pods, Pods переезжают с Node на Node по какой-то причине, происходит обновление Secrets/ConfigMap/... и нужно рестартануть Pods, обновили сам YAML для Deployment и т.д. То есть опять запускается процесс выкатки приложение на том же образе ;)
5) Этот контроль видит этот образ с его critical, high, medium, low уязвимостями и блокирует деплоймент ...
6) Тут можете уже самим придумать как ваша система не справляется, деградирует, складывается как карточный домик. И соответственно бизнес и ИТ совсем не рады такому ... (Встанет вопрос кто принес ущерба больше CVE или контроль)

На бумаге существует множество красивых security подходов, НО которые совсем не учитывают operations специфику системы.

Помните, что задача ИБ не в том, чтобы сделать так чтобы во всех образах было 0 уязвимостей (это даже не реально), а в том чтобы обеспечить непрерывность работы бизнеса и не возможность атакующим реализовать бизнес угроз.