Почему Shift Left не работает в контейнерах?

DevSecOps-инструменты зрелы, автоматизация доступна, сканеры интегрируются в CI/CD – но 70–75% контейнерных образов по-прежнему содержат уязвимости высокого уровня. Что мешает реальному "сдвигу влево"? Мы собрали мнения инженеров и ИБ-специалистов, чтобы разобраться: где именно срывается безопасность – в культуре, инфраструктуре или ожиданиях.

Контейнеры собираются ради функциональности, не ради безопасности

Безопасность редко становится частью задачи разработчиков и сборщиков образов. На первый план выходят сроки, бизнес-ожидания, масштабируемость. Осознанная работа над безопасностью — результат зрелости, а не стартовая установка.

"Технологии и инструменты не работают без культуры их применения среди составителей образов. Далеко не всегда в компаниях есть команда выходного контроля безопасности разрабатываемых продуктов. Зато всегда есть сжатые временные рамки, требования заказчиков и руководства. Поэтому в первую очередь разработчики и составители образов заинтересованы в оперативном решении задачи создания функционала в ограниченный срок. А “сдвиги влево” приходят уже позже с достижением некоторой зрелости команды по части ИБ", – отмечает Алексей Рыбалко, Лаборатория Касперского.

Shift Left возможен только тогда, когда безопасность становится встроенной частью инженерной практики, а не внешней проверкой на выходе.

Публичные образы портят статистику и подставляют инфраструктуру

Большая часть открытых образов в реестрах – тестовые, устаревшие или специально уязвимые. Их не планировали использовать в проде, но они не удаляются, не маркируются и продолжают попадать в автоматические выборки, формируя искаженную статистику и проникая в чужие пайплайны.

"Если посмотреть на Docker Hub и другие открытые ресурсы, то статистику сильно будут размывать "тестовые" и "зараженные для тестирования" образы, которые редко задумывались для использования в проде, и потому особо никогда не исправляются. То же самое можно сказать и о политике хранения, которая редко настраивается для публичных репозиториев владельцами — и мы видим множество старых образов", – подчеркивает Михаил Бессараб, Positive Technologies.

Гигиена хранения образов должна стать частью общей ИБ-стратегии: без неё уязвимости будут наследоваться – вне зависимости от усилий команд.

Образ может быть “чистым” только в моменте

Даже идеально собранный образ с нулевыми уязвимостями через день может оказаться под угрозой – достаточно одной CVE в библиотеке. Реальное мышление Shift Left – это допущение постоянной уязвимости и работа в этой парадигме.

"Уязвимости были, есть и будут. Кода становится только больше, включая заимствованный. Технологии семимильными шагами идут вперед и без особой оглядки на безопасность, кто бы что ни говорил. И даже если в какой-то момент времени в образе нет уязвимостей, это не значит, что через час они там не появятся", – предупреждает Дмитрий Евдокимов, Luntry.

Отказ от иллюзии безопасного состояния – основа устойчивой ИБ-архитектуры. Без регулярной пересборки и контроля артефактов безопасность будет хрупкой.

DevSecOps часто формален и не охватывает жизненный цикл образа

Проверки перед релизом не компенсируют ошибки на этапе проектирования. Зависимости, базовые образы, сторонние библиотеки – все это попадает в финальный артефакт задолго до сканера. Если пайплайн не умеет блокировать уязвимости – он их закрепляет.

"Большинство контейнеров уязвимы из-за формального подхода к DevSecOps, когда проверки проводят на финальных этапах, не учитывая, что уязвимости возникают раньше. Кроме того, бизнес зачастую применяет устаревшие образы и не уделяет должного внимания обновлениям", – считает Игорь Душа, НОТА.

Политики должны работать автоматически: блокировка сборок, отказ от устаревших образов, минималистичные базовые слои. Все это нужно выстраивать заранее – до первого сканирования.

Shift Left требует ресурсов, дисциплины и пересмотра инженерных приоритетов

Даже при желании внедрить практики безопасной сборки, компании сталкиваются с инфраструктурной инерцией. Зачастую проще оставить старую уязвимую версию, чем обновить зависимость – особенно если ее обновление тянет за собой перепроверку всего приложения.

"Shift Left Security требует целостной работы с инженерной и производственной культурой, а также тесной, бесшовной интеграции и автоматизации всех этапов производственного конвейера. Такой комплексный подход требует много времени, ресурсов и инвестиций. Важно также отметить, что уязвимостей много и в базовых репозиториях, откуда собираются образы. С одной стороны, уязвимости постоянно выявляются, а с другой – "поднимать" версии пакетов внешних зависимостей дорого, это всегда дополнительная разработка", – уточняет Максим Чудновский, СберТех.

Поддерживать актуальность безопасной среды – это не разовая кампания, а постоянная инженерная нагрузка. Shift Left означает, что эта нагрузка становится нормой.

Безопасность – это не свойство образа, а зрелость процессов

Контейнерная безопасность не начинается и не заканчивается на сканере. Она строится из инженерной дисциплины, автоматизированного контроля, культуры пересборки и признания того, что уязвимость – это норма. Пока этого признания нет, Shift Left останется лозунгом.

Сдвиг влево невозможен, пока безопасность воспринимается как дополнение. Он начинается с того момента, когда безопасность становится основой сборки.