Что такое Container Security и почему это важно? Какие существуют угрозы и риски для контейнерной инфраструктуры? Как правильно выстроить процесс безопасной разработки, сборки и эксплуатации контейнеров? В эфире AM Live обсуждались актуальные проблемы защиты контейнерных сред и опыт их решения на практике.
- Введение
- Понятие о контейнерах и контейнеризации
- Состояние отечественной контейнерной безопасности
- Угрозы и риски для контейнерной инфраструктуры
- Уровни защиты контейнеризации
- Изоляция в контейнерах
- Секреты и проблемы с секретами в контейнерах
- Права доступа в контейнерах
- Сетевое взаимодействие и сетевая безопасность в Kubernetes
- Мониторинг событий в контейнерах
- Инциденты с контейнерами
- Безопасность контейнеров и стандарты
- Прогнозы и эволюция угроз
- Выводы
Введение
В эфире AM Live, посвящённом теме безопасности контейнеризации, ведущие эксперты по информационной безопасности обсудили ключевые вопросы защиты контейнерных сред, включая угрозы и риски, важность правильной настройки, уязвимости образов и контейнеров, управление доступом и секретами, мониторинг, взаимодействие с SOC, стандарты, регулирование, эволюцию угроз и векторы развития.
Рисунок 1. Участники дискуссии
В обсуждении приняли участие:
- Никита Ладошкин, руководитель разработки PT Container Security в Positive Technologies.
- Михаил Черешнев, руководитель по облачной и контейнерной безопасности в Swordfish Security.
- Александр Маникайнен, ведущий системный администратор Selectel.
- Александр Титов, сооснователь компании «Экспресс 42», совладелец и генеральный директор компании «Флант».
- Дмитрий Евдокимов, основатель и технический директор Luntry.
- Артём Чернов, ведущий инженер по информационной безопасности в компании «К2 Кибербезопасность».
- Алексей Рыбалко, специалист по защите сред контейнерной разработки, «Лаборатория Касперского».
Ведущим и модератором встречи выступил Максим Морарь, владелец продуктов Nova и StarVault в компании Orion soft.
Понятие о контейнерах и контейнеризации
Никита Ладошкин начал беседу с базового определения:
«Контейнеризация — это способ упаковки, доставки и запуска приложений, при котором зависимости определяются на этапе сборки в виде образа. Контейнеры могут работать независимо на хосте, будучи легковесными и изолированными друг от друга, что позволяет чётко определить ландшафт и окружение (environment). Благодаря этому упрощается управление разными версиями ПО, ускоряется процесс обновления и повышается отказоустойчивость за счёт репликации».
Никита Ладошкин, Positive Technologies
Как отметил эксперт, в силу специфики архитектуры (изоляция контейнеров, оркестровка) контейнеры требуют особого подхода к защите. Для компаний Никита Ладошкин видит в контейнеризации следующие преимущества:
- Удешевление процесса управления разными версиями ПО за счёт упаковки в образы и запуска контейнеров.
- Ускорение и упрощение доставки обновлений на хосты.
- Повышение отказоустойчивости путём запуска нескольких реплик контейнеров.
С контейнерами компании получают более быстрый, дешёвый и надёжный процесс разработки и эксплуатации приложений, но сталкиваются с новыми проблемными задачами по обеспечению безопасности.
Состояние отечественной контейнерной безопасности
Михаил Черешнев отметил рост интереса к контейнерной безопасности среди российских компаний:
«Если мы, условно, года два-три назад приходили к клиентам и говорили — давайте мы вам предложим услуги по контейнерной безопасности, то нас спрашивали: зачем это всё, почему? Приходилось очень долго всё это объяснять. В текущий момент времени уже к нам приходят и спрашивают, что лучше купить и сколько».
Михаил Черешнев, Swordfish Security
По словам эксперта, объём рынка в России к 2029 году должен вырасти до 8–9 млрд рублей с нынешних примерно 4 млрд. Спрос и предложение активно растут.
Помимо этого, как подчеркнул Максим Морарь, сегодня происходит «культурный сдвиг»: контейнеризация перестаёт восприниматься как нечто второстепенное, компании выделяют на неё существенные бюджеты и ресурсы.
Максим Морарь, Orion soft
Угрозы и риски для контейнерной инфраструктуры
Артём Чернов выделил рост сложности векторов атак, а также сосредоточенность злоумышленников на цепочках поставок и на оркестраторах контейнеров. Основными векторами, по словам эксперта, являются:
- Неверные конфигурации оркестраторов, допускающие несанкционированный доступ (например, открытые наружу консоли без аутентификации).
- Уязвимые приложения, доступные из интернета (небезопасные веб-интерфейсы, API).
- Отсутствие должной сегментации сети (возможность горизонтального перемещения между узлами).
- Избыточные привилегии контейнеров (например, запуск от имени суперпользователя, лишний доступ к файлам).
Эксперты подчеркнули ключевую роль корректных настроек в обеспечении безопасности. Никита Ладошкин отметил, что многие ждут появления неких «коробочных» решений, закрывающих все риски и угрозы, но на деле требуется кропотливая работа с настройками на всех уровнях — хостов, кластера, сетей, контейнеров.
Александр Маникайнен, Selectel
Александр Маникайнен привёл пример того, как заказчики в погоне за удобством пренебрегают базовыми практиками безопасности:
«Заказчики вполне себе качают образы из публичных репозиториев, того же Docker Hub, потому что это удобно. И вдруг оказывается, что теперь нужно с этими удобствами как-то работать, городить вокруг них безопасность. Неожиданно: вроде только что было удобно, и вдруг уже стало небезопасно».
Уязвимости образов
Артём Чернов выделил следующие типичные проблемы:
«Могут быть уязвимые базовые образы, на основе которых строятся все последующие контейнеры, плюс уязвимости ядра, сторонних библиотек и просто используемого ПО. Также, если мы не контролируем то, какие образы к нам попадают, можно столкнуться с целенаправленно вредоносными контейнерами».
Эксперты добавили, что многие проблемы исторически связаны с несовершенством первых версий инструментов оркестровки. Современные версии Kubernetes содержат больше защитных механизмов «из коробки», но те отключены по умолчанию. Командам приходится отдельно их активировать и настраивать.
Алексей Рыбалко отметил проблему поиска и идентификации секретов в образах: «Помимо поиска уязвимостей, нужно искать в образах секреты. Но если уязвимости можно найти с помощью сканеров и баз, то с секретами сложнее: их нужно искать по сигнатурам, паттернам, эвристикам».
Дмитрий Евдокимов подчеркнул, что в контейнерах могут содержаться избыточные инструменты, потенциально полезные хакерам:
«Всегда говорится про вредоносный код, но забывается, что в образе могут находиться различные шеллы, Curl, Wget и интерпретаторы языков, даже целые компиляторы кто-то умудряется класть в образы контейнеров. С помощью этого инструментария атакующий может развить свою атаку, и ему не нужен какой-то специализированный вредоносный инструментарий. Поэтому клиентам важно следить за минимизацией своих образов».
Рисунок 2. Используете ли вы технологии контейнеризации в вашей компании?
Тему внедрения контейнеров подытожили результатами опроса зрителей. Стало ясно, что подавляющее большинство (81 %) компаний уже внедрили или внедряют контейнеризацию.
Уровни защиты контейнеризации
Дмитрий Евдокимов выделил четыре уровня, на каждом из которых требуется обеспечивать защиту: код, контейнер, кластер, облачный провайдер.
Александр Титов раскрыл особенности защиты на этих уровнях. В частности, на уровне инфраструктуры как кода рекомендуется фокусироваться на минимизации образов, включая в них только необходимые компоненты. В этом плане у контейнеров есть преимущество перед виртуальными машинами: можно создавать компактные образы. Далее идёт уровень оркестратора, где ключевое значение имеет управление доступом к API, объектам и данным о состоянии системы.
Эксперт советует уделить особое внимание гранулярности политик и избегать чрезмерных привилегий. Наконец, на уровне облачного провайдера важно обеспечить безопасную конфигурацию всех компонентов платформы, включая систему оркестровки.
Изоляция в контейнерах
В сообществе распространено мнение, что контейнеры обеспечивают меньший уровень изоляции в сравнении с виртуальными машинами. Александр Маникайнен оспорил этот тезис: «Правильно приготовленный контейнер будет ничуть не хуже, чем та же виртуальная машина». По словам Александра, риски сопоставимы, а ключевое значение имеют корректная настройка и ограничение возможностей контейнеров.
Никита Ладошкин добавил, что в отличие от виртуальных машин контейнеры позволяют минимизировать площадь атаки за счёт отказа от полноценного гостевого дистрибутива ОС в пользу урезанных образов.
Михаил Черешнев дополнил тезис словами о необходимости разделения рабочих нагрузок:
«Критически важные компоненты и системы с повышенными требованиями к инфраструктуре и виртуализации лучше оставлять на классических виртуальных машинах, а остальные рабочие нагрузки — смело переносить в контейнеры».
Также эксперты сравнили изоляцию на уровне гипервизора и ядра ОС. Изоляция виртуальных машин часто кажется более надёжной, так как реализовывается на аппаратном уровне процессора — однако и там случаются уязвимости и инциденты. У контейнеров же изоляция осуществляется на уровне ядра Linux, то есть при должной настройке она может быть не менее (а иногда — и более) надёжной и к тому же гибкой. Кроме того, открытость кода ядра упрощает поиск и устранение уязвимостей.
Подытоживая, Никита Ладошкин дал практический совет по конфигурированию контейнеров в условиях невозможности полного отказа от гостевой ОС:
«Если вы не можете обеспечить глубокую изоляцию из-за инфраструктурных ограничений или зависимости от операционной системы, следуйте общей рекомендации: используйте базовый образ, который сертифицирован и проверен вашей инфраструктурной командой. На основе этого базового образа, который регулярно контролируется и обновляется, разворачивайте всё пользовательское и бизнесовое программное обеспечение».
Секреты и проблемы с секретами в контейнерах
Никита Ладошкин отметил, что в целом практики работы с секретами в контейнерах и в традиционных приложениях мало различаются:
«Рекомендую использовать те же подходы при поиске секретов в образах, потому что контейнер — это всё-таки та же самая файловая система и запущенные приложения, просто в миниатюре».
При этом часто встречается хранение секретов внутри образов по небрежности разработчиков. Михаил Черешнев посоветовал системный подход: внедрять проверки на наличие секретов на всех этапах жизненного цикла контейнера, от анализа исходного кода и Docker-файла до сканирования собранного образа в реестре и мониторинга в ходе исполнения (runtime).
Права доступа в контейнерах
Михаил выделил следующие типовые проблемы с правами доступа в кластерах Kubernetes:
- Использование прав администратора кластера для развёртывания приложений через системы CI / CD вроде GitLab или ArgoCD. Это даёт избыточные привилегии и несёт риски компрометации.
- Отсутствие должного контроля за сервисными аккаунтами в кластерах, раздача им избыточных прав.
- Сложность отслеживания прав и управления ими в больших инфраструктурах со множеством кластеров и команд.
В качестве решения эксперт посоветовал внедрять решения для анализа ролей и политик безопасности (RBAC, Kyverno и пр.), следовать принципу минимальных привилегий и встраивать механизмы контроля в процессы CI / CD.
Александр Титов, «Флант»
Александр Титов отметил, что избыточные привилегии — это общая проблема безопасности, не уникальная для Kubernetes. Ключ к решению он видит в правильном применении политик и контроллеров доступа для ограничения возможностей.
Резюмируя, эксперты сошлись во мнении, что для эффективного управления правами в Kubernetes нужно использовать политики и контроллеры доступа, переходить от избыточных привилегий к модели минимально необходимых прав, а также интегрировать проверки в процессы CI / CD.
Сетевое взаимодействие и сетевая безопасность в Kubernetes
Дмитрий Евдокимов раскрыл специфику сетевой безопасности в Kubernetes:
«Сетевая безопасность — наверное, один из ключевых моментов для контейнерных сред. Практически все сервисы общаются по сети, Kubernetes привносит много своей собственной специфики».
Дмитрий отметил, что динамичность выделения IP-адресов усложняет работу классических сетевых СОВ. Однако при этом в Kubernetes есть нативная функциональность сетевых политик (Network Policies), реализовывающая микросегментацию по модели «белых списков».
Михаил Черешнев подтвердил, что многие клиенты из финансового сектора уже используют сетевые политики в Kubernetes, что серьёзно затрудняет латеральное движение и развитие атак.
Эксперты также обсудили вопрос применимости в Kubernetes решений класса IPS / IDS. По их мнению, специализированные сетевые плагины и политики Kubernetes лучше подходят для этой задачи, так как учитывают специфику динамической инфраструктуры. Внешние системы анализа трафика могут вносить излишние задержки, снижая производительность.
Мониторинг событий в контейнерах
Алексей Рыбалко рассказал о подходах к мониторингу событий внутри запущенных контейнеров (runtime):
«Классический подход, изначально, — это смотреть на сеть: что передаётся по сети, в первую очередь... Если в этой активности есть что-то непонятное, потенциально аномальное по сигнатурам или каким-то другим маркерам, то, соответственно, эту активность нужно блокировать».
Алексей Рыбалко, «Лаборатория Касперского»
Также важно контролировать активность контейнеров в файловой системе: какие процессы они запускают и насколько это соответствует ожидаемому поведению.
Использование агентов внутри или рядом с контейнерами для мониторинга вызывает протесты у DevOps, поэтому более перспективный подход — централизованный мониторинг через ядро Linux с помощью eBPF. Это позволяет минимизировать задержки и избыточную нагрузку в сравнении с агентским подходом.
Таким образом, наиболее прогрессивный подход к мониторингу контейнеров на этапе исполнения — интеграция проверок на уровне ядра Linux, централизованный сбор событий и корреляция на уровне платформы безопасности. Это позволяет эффективно выявлять аномалии при минимальном влиянии на производительность.
Инциденты с контейнерами
В блиц-формате участники привели примеры известных инцидентов, связанных с компрометацией контейнерных сред.
Никита Ладошкин рассказал об атаке на облачную инфраструктуру Tesla. Из-за открытых наружу консолей Kubernetes злоумышленники смогли получить доступ к облачным ресурсам и запустить майнинг криптовалюты.
Михаил Черешнев поделился примером атаки через системы с машинным обучением. Злоумышленники скомпрометировали ML-модели и реестр образов, распространив заражение на клиентские среды.
Александр Маникайнен описал сценарий компрометации через системы CI / CD с запуском вредоносных контейнеров со встроенными реверс-шеллами.
Александр Титов привёл пример уязвимости в настройках Kubernetes у облачного провайдера, позволившей через чтение конфигураций получить доступ к управлению всей инфраструктурой.
Дмитрий Евдокимов рассказал об атаке на российскую финансовую организацию через Kubernetes, приведшей к компрометации корпоративной сети.
Алексей Рыбалко поделился свежим инцидентом заражения публичных демонов Docker с попыткой запуска майнинга криптовалют на скомпрометированных ресурсах.
Артём Чернов, «К2 Кибербезопасность»
Артём Чернов описал атаку через ML-инфраструктуру крупного облачного провайдера. Несмотря на политики и сегментацию, через уязвимости в Helm v2 удалось скомпрометировать не только среду провайдера, но и клиентов.
Эти примеры наглядно показывают многообразие векторов атак на контейнерные среды, включая доступные извне интерфейсы управления, цепочки поставок образов, уязвимости в инструментах CI / CD и платформенных сервисах провайдеров. Во многих случаях успешная компрометация Kubernetes становилась плацдармом для распространения атаки на всю инфраструктуру.
Безопасность контейнеров и стандарты
Никита Ладошкин отметил, что клиенты могут ориентироваться на международные стандарты и лучшие практики по безопасности контейнеров, такие как CIS Kubernetes Benchmark, NIST 800-190 и PCI DSS. В то же время их сложно и дорого внедрять в полном объёме.
Эксперт подчеркнул, что 118-й приказ ФСТЭК России описывает требования к самим средам контейнеризации, а не к дополнительным средствам защиты, чего явно недостаточно. Также он выразил надежду на скорое появление отечественных стандартов, учитывающих локальную специфику: преобладание платформ оркестровки с открытым кодом, требования регуляторов по импортозамещению. Такая работа уже ведётся на уровне ТК 26 при участии вендоров.
Михаил Черешнев считает, что для крупных компаний не менее важны собственные внутренние стандарты и политики ИБ, основанные на их специфике и опыте. Однако таких зрелых организаций, способных сформировать полноценные базовые требования к Kubernetes, в России пока единицы.
Таким образом, индустрия остро нуждается в адаптированных к локальной специфике, практически применимых стандартах безопасности контейнеризации. Их разработка уже началась при активном участии регуляторов и отраслевого сообщества. В то же время крупным компаниям нельзя забывать и о своевременной выработке внутренних политик и требований.
Контроль в процессе исполнения (runtime)
Алексей Рыбалко отметил рост интереса заказчиков к выявлению угроз в работающих контейнерах (runtime security), а не только к сканированию образов. Эксперт выделил здесь три ключевых аспекта:
- Анализ сетевого трафика контейнеров на предмет аномальной активности (сканирование сети, C&C, эксфильтрация данных).
- Контроль файловой активности, включая создание / изменение исполняемых файлов.
- Отслеживание запускаемых процессов на предмет отклонения от ожидаемого поведения образа.
При этом оптимальным подходом Алексей считает перенос логики детектирования на уровень ядра Linux с помощью eBPF вместо использования агентов внутри контейнеров.
Михаил Черешнев рассказал об опыте профилирования поведения рабочих нагрузок в контейнерах на основе сбора системных вызовов. Построенные профили позволяют выявлять отклонения от нормального поведения микросервисов. Эксперт отметил нетривиальность выявления недекларированных возможностей (как случайных, так и специально внесённых) в образах, особенно при использовании компонентов с открытым кодом. Помочь здесь может комплексный анализ исходного кода.
Дмитрий Евдокимов, Luntry
Дмитрий Евдокимов дополнил: несмотря на рост технической сложности атак, вряд ли стоит ждать прорывов в используемых техниках эксплойтов. В конце концов, если есть то, что уже работает, зачем придумывать ещё что-то? В то же время Дмитрий допускает рост количества случаев применения ИИ и автоматизированных инструментов со стороны хакеров, что может дать им количественное преимущество в создании новых векторов атак.
Управление обновлениями и патч-менеджмент
Говоря о проблемах управления обновлениями контейнеров, эксперты выделили три аспекта:
- Своевременное обновление компонентов оркестратора и узлов кластера, поддержание их на актуальном уровне.
- Управление обновлением сторонних библиотек и компонентов в самих контейнерах.
- Контроль обновлений хостовых ОС с фокусом на ядре Linux как наиболее критически важном компоненте.
Дмитрий Евдокимов заметил, что обновление пакетов на хостах по большей части теряет смысл в контексте контейнеризации: ведь если атакующий сумел выйти из контейнера на хост, то он уже получил полный контроль, вне зависимости от версий ПО.
Никита Ладошкин добавил, что усилия вендоров контейнерных платформ во многом направлены на упрощение выявления и приоритизации необходимых обновлений. Это достигается благодаря взаимодействию с базами уязвимостей, комплексами безопасной разработки и системами управления рисками.
Рисунок 3. Что вы используете для защиты контейнерных сред?
Результаты опроса зрителей показали, что в сравнении с прошлым годом увеличилась доля тех, кто полагается только на встроенные механизмы защиты.
SOC и сложности в работе с контейнерными средами
Центры мониторинга ИБ традиционно ориентированы на работу с событиями через SIEM. В контейнерных средах это сопряжено с рядом сложностей. Никита Ладошкин поделился опытом взаимодействия их продукта с SOC клиентов:
«По их словам, главная проблема — контекст события. Узел, пространство имён, контейнер — всё это покрыто “туманом войны” для SOC. Был упомянут статичный условный IP-адрес, по которому принято ориентироваться — здесь это неактуально, поэтому тяжело, соответственно, точечно попасть в цель: что произошло и где именно. Детали события, того же самого мониторинга в ходе исполнения, для SOC тоже не очень понятны. Это набор каких-то функций, аргументов; о чём они говорят и зачем нужны, неясно».
Эксперт видит два пути решения:
- Интегрировать системы защиты контейнеров с SIEM (привычно, но менее информативно).
- Учить SOC работать со специализированными инструментами контейнерной безопасности (более точечно, но требует обучения).
В идеале системы защиты должны предоставлять SOC-аналитикам информацию о событиях в привычном формате CEF / LEEF, но со всем необходимым контекстом (метками Kubernetes).
Также интересна идея Михаила Черешнева по выявлению подозрительной активности через поведенческий анализ. Обнаружение аномалий в сравнении с профилем позволяет абстрагироваться от технических деталей реализации атаки.
По мнению Дмитрия Евдокимова, такой подход не требует от аналитиков глубокого знания контейнерной специфики:
«Мы показываем, как можно использовать различные поведенческие анализы, гибридные подходы. Например, из последнего, что мы сделали, — детектирование запуска исполняемых файлов, которых ранее не было в образах. Неважно, каким образом их внедрили: через пакетные менеджеры, реверс-шелл, переименование, чтобы обойти сигнатурные способы детектирования, — это будет найдено. Тем самым мы играем на специфике контейнерных сред. И когда SOC это видит, срабатывание для них — это стопроцентный детект, и там не нужно быть гением. Ты понимаешь, что тебе что-то докачали, снимаешь дамп файловой системы, снимаешь дамп оперативной памяти, при желании устанавливаешь контейнер, идёшь, берёшь артефакты и расследуешь».
Этот блок беседы подытожили опросом аудитории и также сравнили результаты с прошлым годом.
Рисунок 4. Какие функции безопасности контейнерных сред необходимы?
На вопрос модератора о том, соответствуют ли имеющиеся на российском рынке решения запросам заказчиков по контейнерной безопасности, Артём Чернов и Михаил Черешнев ответили положительно. При этом Михаил подчеркнул важность процессной составляющей. Инструменты инструментами, но без интеграции с общими практиками SSDLC и управления уязвимостями эффект будет ограничен.
Можно сказать, что российский рынок в целом готов к запросам заказчиков по контейнерной безопасности. Необходимая функциональность присутствует, вопрос — в качестве внедрения и процессах. Под конкретные задачи заказчика может потребоваться комбинировать функции разных решений.
Прогнозы и эволюция угроз
Эксперты предположили следующие тренды в контейнерной безопасности.
Артём Чернов:
«В первую очередь продолжат усложняться угрозы в целом, будет расширяться перечень векторов атак. Я глубоко убеждён, что атаки на цепочки поставок совершенно не потеряют своей актуальности. Если пофантазировать — атаки с использованием искусственного интеллекта будут получать более широкое применение».
Александр Титов:
«Снижение порога входа в хакерство за счёт открытости информации и развития ИИ-помощников в разработке эксплойтов. Как следствие — рост количества атак, но не обязательно их качества и изощрённости».
Дмитрий Евдокимов:
«Я бы поставил на атаки через прикладное ПО, которое разворачивается в Kubernetes. Тот же самый Ingress — пойдут через него. Kubernetes потихоньку обрастает функциями безопасности в базе, а в приложениях их ещё нескоро внедрят в полной мере».
Михаил Черешнев:
«Наш вычислительный ландшафт с каждым годом становится всё сложнее. Мы ещё не дошли до уровня пограничных вычислений с использованием Web Assembly и запуска практически одинакового бинарника на любой инфраструктуре, вплоть до браузера. Когда мы до этого дойдём, нам всем, и вендорам, и интеграторам, придётся готовиться к этому если не сегодня, то завтра».
Никита Ладошкин назвал одним из трендов переход в режим CNAPP (Cloud Native Application Protection Platform).
«Цель любого решения по контейнерной безопасности — это всегда превращение в CNAPP. По моему мнению — может быть, звучащему резко, — полноценных CNAPP на рынке нет, включая небезызвестные, самые опытные, старые решения. Поэтому неизбежно все идём туда, в эту сторону».
Беседу завершили финальным опросом зрителей.
Рисунок 5. Ваше мнение относительно защиты контейнерных сред?
Выводы
Подытожим ключевые моменты дискуссии:
- В России сейчас нет общепринятых стандартов по безопасности контейнеров. Международные стандарты вроде CIS Benchmark сложно и дорого внедрять в полном объёме. Есть инициативы по созданию отечественных рекомендаций с учётом местной специфики.
- Уязвимости и избыточные возможности в контейнерах нужно выявлять максимально рано, желательно — на этапе сборки образов.
- Своевременный патч-менеджмент в контейнерной среде затруднён из-за распределённости инфраструктур. Необходимо выделять критически важные обновления и контролировать ядро Linux на хостах.
- Взаимодействие контейнерной безопасности с SOC оптимально реализовывать через обогащение событий контекстом Kubernetes и корреляцию на уровне SIEM. Анализ аномалий поведения позволяет абстрагироваться от деталей атак.
- Отечественный рынок в целом закрывает базовые потребности по контейнерной безопасности. Развитие идёт в сторону облачных платформ класса CNAPP с упором на удобство использования.
- Среди угроз будущего — использование ИИ для генерации эксплойтов. Нужно регулярно пересматривать модель угроз.
- Интеграция безопасности в конвейер CI / CD контейнерных приложений — уже насущная необходимость. Лучшие вендоры будут стремиться стать частью общего процесса разработки.
В целом, сфера отечественной контейнерной безопасности активно развивается. Появляются сильные игроки, закрывающие базовые потребности рынка. Однако и угрозы не стоят на месте. Победа в гонке между защитой и нападением будет за теми, кто сможет оперативно адаптироваться к новым вызовам, сочетая технологичность с удобством и гибкостью.
