Контакты
Подписка 2025

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

Редакция журнала "Информационная безопасность", 08/07/25

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

ris1-Jul-08-2025-02-02-20-0054-PM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Темы:Круглый столЖурнал "Информационная безопасность" №2, 2025Container Security

Программа мероприятий
для руководителей и специалистов
по защите информации

Посетить
Кибербезопасность
Форум ITSEC 2025 | Москва | Radisson Blu Belorusskaya. Мероприятия для директоров и специалистов по ИБ, инженеров, ИТ-руководителей и разработчиков
Регистрируйтесь и участвуйте 14-15 октября →
Статьи по той же темеСтатьи по той же теме

  • Один бюджет, один приоритет: как вложиться в безопасность контейнеров?
    Что делать, если есть только один бюджет, а направлений – десятки? Спросили у экспертов: во что стоит инвестировать в 2025 г., если выбирать придется только одно направление – рантайм, цепочка поставок, харденинг или что-то еще?
  • Кто уступит в борьбе за контейнер?
    Дмитрий Беляев, директор управления безопасности ООО “АБТ”
    Эффективная защита контейнеров необходима для обеспечения безопасности микросервисных и облачных инфраструктур, она требует специализированных решений, контроля трафика и системного подхода. Но в погоне за скоростью разработки есть соблазн сознательно пожертвовать безопасностью контейнеров ради скорости вывода продуктов на рынок – и этот компромисс может обойтись слишком дорого.
  • Переход на отечественные АСУ ТП: опыт, ошибки, рекомендации
    Переход на отечественные компоненты в АСУ ТП – задача не только технологическая, но и стратегическая: от правильного выбора решений зависят безопасность, стабильность и сопровождаемость критической инфраструктуры. Участники отрасли отмечают, что при всей интенсивности развития российского рынка, зрелость отечественных решений всё ещё неоднородна – особенно в части интеграции с системами ИБ и реализации принципов безопасной разработки. 
  • Как на практике устранять разрывы между защитой ИТ и AСУ ТП?
    Несмотря на очевидную техническую разницу между ИТ и АСУ ТП, именно организационные барьеры чаще всего мешают выстроить устойчивую систему кибербезопасности в промышленности. Недостаточно просто поделить ответственность между подразделениями: требуется новая модель совместной работы, в которой ИТ, ИБ и технологи не просто "сотрудничают", а действуют как единая команда с общими целями и пониманием процессов. 
  • Аутсорсинг SOC для АСУ ТП: выход или угроза?
    Идея аутсорсинга SOC в промышленности все чаще обсуждается как способ повысить устойчивость и снизить затраты. Однако эксперты сходятся во мнении: применять эту модель в индустриальной сфере напрямую, по шаблону ИТ-инфраструктур, рискованно. Промышленные процессы требуют не просто мониторинга инцидентов, а глубокого понимания технологической специфики и особенностей функционирования АСУ ТП. 

Хотите участвовать?

Выберите вариант!

КАЛЕНДАРЬ МЕРОПРИЯТИЙ 2025
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ АВТОРОМ
Linux
Персональные данные в 2026 году: новые требования
Обсудим 15 октября на Форуме ITSEC 2025. Регистрация →

More...
ТБ Форум 2025
Защита АСУ ТП и КИИ: готовимся к 2026 году
Регистрация участников на конференцию 16 октября →

More...