Некоторое время назад помогали клиентам решать следующую задачу: Как можно отловить проблемы безопасности с NetworkPolicy перед их применением? При этом как можно меньше для этого всего дела привлекать специалистов по ИБ (тоесть максимально автоматизировать), так как их мало, а команд разработки очень много.

И в начальных условиях мы еще имеем:
1) GitOps
2) Kyverno, который всегда на любого нового namespace создавал default-deny политику.

В итоге, мы остановились на том что в качестве критерий привлечения ИБ было появление или изменение в NetworkPolicy следующих моментов:
1) Появление/изменение ipBlock (чтобы контролировать все внешние коммуникации в egress)
2) Использование namespaceSelector без podSelector (чтобы не давали доступы целым namespaces)
3) Отсутствие в podSeclector специальных labels (чтобы использовали только определенную уникальную, хранящую имя сервиса)
4) Контроль portRange (чтобы не давать доступ сканировать прям целые диапазоны портов)

Это все для native реализации политик и как вы понимаете можно ее улучшать и ужесточать (например, тригерить при использовании определенного критичного namespаce) и т.д.

Логика по сути была такая, что если NetworkPolicy касается только внутрикластерного взаимодействия и не является какой-то "широковещательной" (диапазоны, подсети, целые namespace), то применяем без привлечения ИБ. Если же политика касалась внешних коммуникаций, была "широковещательной", то требовало ревью ИБ.

Как вам такой план? Может у вас в компании это решено по другому?