Продолжаем обсуждение темы о сканирование образов (
1) Высокий уровень шума - базовая проблема, которая как снежный ком тянет за собой все последующие пункты. Сканеры всегда что-то находят, даже в самых последних версиях образов ОС. При этом с точки зрения атакующего
2) Это не Shift left security - IMHO это эксплуатация хайпового подхода. Настоящий
3) Наличие False negatives - данные решения также могут и пропускать известные
4) Только известные CVE (1day) - с точки зрения бизнеса не имеет роли как была скомпрометирована система и принесен ущерб. Инцидент должен быть обнаружен максимально быстро как в случае
5) Strong Security Team - разгребать все это должна сильная команда безопасности, способная понимать, что для их сервиса актуально, а что нет, какие риски принять можно, а какие нет. Также хорошо бы иметь security champions внутри команд разработки.
6) Stop delpoy?! - очень красивая история, когда из-за критической уязвимости автоматически блокируют деплой. Но по факту, практически никто так не делает так как из-за простоя сервиса финансовые потери могут быть куда больше, чем он от непонятной уязвимости. Бизнес останавливать не будут.
7) Психология - разработчики и другие сотрудники, видя красные дашборды и успешно функционирующий сервис одновременно, постепенно будут терять мотивацию тщательно следить за этим моментом, ведь есть более важные бизнес фичи, приносящие прибыль.
Одно дело на демонстрации посмотреть дашборд сканера, где все красиво отображается, и совсем другое работать над улучшением данной картинки — это большая работа и мало кто это понимает.
Вещь нужная, но вы должны понимать эти моменты, когда соберетесь заниматься данным вопросом. Нужно адекватно расставлять приоритеты, оценивать силы и возможности своей команды.
images) контейнеров. Сегодня рассмотрим то, о чем в маркетинговых материалах как правило умалчивают.1) Высокий уровень шума - базовая проблема, которая как снежный ком тянет за собой все последующие пункты. Сканеры всегда что-то находят, даже в самых последних версиях образов ОС. При этом с точки зрения атакующего
~90-100% может быть вообще никогда не проэксплотировано, так как уязвимые функции из библиотек не используются.2) Это не Shift left security - IMHO это эксплуатация хайпового подхода. Настоящий
Shift left security в таком случае уже должен работать с исходным кодом в момент разработки сервиса, а не когда он уже написан. Для это есть другой класс инструментов.3) Наличие False negatives - данные решения также могут и пропускать известные
CVE в вашем коде по множеству причин: он качества их БД уязвимостей, до способа добавления стороннего кода разработчиками в проект (куски кода, статически слинкованные библиотеки и т.д.).4) Только известные CVE (1day) - с точки зрения бизнеса не имеет роли как была скомпрометирована система и принесен ущерб. Инцидент должен быть обнаружен максимально быстро как в случае
1day, так и 0day атаки.5) Strong Security Team - разгребать все это должна сильная команда безопасности, способная понимать, что для их сервиса актуально, а что нет, какие риски принять можно, а какие нет. Также хорошо бы иметь security champions внутри команд разработки.
6) Stop delpoy?! - очень красивая история, когда из-за критической уязвимости автоматически блокируют деплой. Но по факту, практически никто так не делает так как из-за простоя сервиса финансовые потери могут быть куда больше, чем он от непонятной уязвимости. Бизнес останавливать не будут.
7) Психология - разработчики и другие сотрудники, видя красные дашборды и успешно функционирующий сервис одновременно, постепенно будут терять мотивацию тщательно следить за этим моментом, ведь есть более важные бизнес фичи, приносящие прибыль.
Одно дело на демонстрации посмотреть дашборд сканера, где все красиво отображается, и совсем другое работать над улучшением данной картинки — это большая работа и мало кто это понимает.
Вещь нужная, но вы должны понимать эти моменты, когда соберетесь заниматься данным вопросом. Нужно адекватно расставлять приоритеты, оценивать силы и возможности своей команды.