Runtime-защита контейнеров: зачем сканирования образов мало
Сканирование образов (shift-left) ловит известные уязвимости и проблемы конфигурации **до** запуска — это нужный, но не достаточный слой. В работающем контейнере появляются угрозы, которых не было в образе: эксплуатация уязвимости в рантайме, запуск постороннего процесса, обращения в неожиданные сети, drift (изменение файловой системы относительно образа), попытки выхода за пределы контейнера. Поймать это можно только наблюдая за поведением во время исполнения. **Если коротко:** образ — это снимок на момент сборки, а атака происходит вживую. Runtime-защита добавляет поведенческий контроль ядра (часто через eBPF), обнаружение отклонений от эталона, мониторинг сети и автоматическую реакцию (алерт, заморозка, остановка пода). Ниже — почему одного сканирования мало, что именно даёт runtime, как соотносятся shift-left и runtime и на что смотреть при выборе. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге Container и Kubernetes Security](/rating/container-kubernetes-security).
Контейнерная безопасность соединяет код, образ и runtime
Для Kubernetes важно контролировать зависимости, образы, политики запуска и поведение workload после деплоя.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
author
Антон Смирнов
Старший редактор исследований ИБ-рынка
Ведет исследования по категориям ИБ, публичным источникам и критериям выбора поставщиков.
- 7 лет в SEO-аналитике и редакционных B2B-исследованиях
- Специализация: ИБ-категории, entity-based SEO и факторы E-E-A-T
author
Полина Лебедева
Исследователь рынка ИБ-поставщиков
Собирает и сравнивает данные по подрядчикам, услугам, публичным кейсам, ценовым диапазонам и рыночным сегментам.
- 5 лет в market research, digital-аналитике и конкурентных обзорах
- Специализация: ИБ-поставщики, сервисные категории, прайс-анализ и case review
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Почему сканирования образов недостаточно
Сканер образа отвечает на вопрос «что внутри артефакта на момент сборки»: какие пакеты, какие у них CVE, нет ли секретов в слоях, соответствует ли конфигурация политикам. Это ценно и обязательно, но у такого подхода есть встроенные ограничения.
- **Снимок устаревает мгновенно.** Между сборкой и продакшеном публикуются новые CVE. Образ, «чистый» вчера, сегодня содержит уязвимость, о которой просто ещё не знали. - **Атака происходит в рантайме.** Эксплуатация уязвимости, реверс-шелл, майнер, загруженный после старта, — всё это не видно в статике образа, потому что появляется только при исполнении. - **Не каждая уязвимость достижима.** Сканер показывает CVE в пакете, но не знает, вызывается ли уязвимый код и доступен ли он извне. Без рантайма приоритизация слепая. - **Drift и «ручные правки».** Кто-то зашёл `kubectl exec` в под, доустановил пакет, подменил бинарь — файловая система разъехалась с образом, а сканер этого не увидит. - **Легитимные образы, нелегитимное поведение.** Доверенный образ может выполнять неожиданные действия из-за скомпрометированной зависимости или цепочки поставки.
Вывод не «сканирование не нужно», а «сканирование закрывает вход, но не закрывает жизнь контейнера». Нужен второй контур — наблюдение за поведением.
Где обнаруживается угроза: образ vs runtime
Редакционная оценка доли угроз, надёжно выявляемых на этапе сканирования образа против этапа исполнения. Это не вендорский бенчмарк; цифры иллюстративны и не заменяют пилот.
Что даёт runtime-защита
Runtime-защита наблюдает за тем, что контейнер реально делает: какие процессы запускает, к каким файлам и сетям обращается, какие системные вызовы выполняет. Современные решения собирают эти сигналы из ядра, чаще всего через **eBPF** — это даёт глубокую видимость без тяжёлых агентов и без модификации приложения.
- **Поведенческий контроль.** Строится эталон нормального поведения сервиса (профиль процессов, файлов, сетевых соединений), а отклонения помечаются как аномалии. - **eBPF-видимость на уровне ядра.** Перехват syscalls, сетевых событий и запусков процессов с низкими накладными расходами и без перекомпиляции ядра. - **Обнаружение drift.** Сравнение текущей файловой системы и поведения с исходным образом: новый бинарь, изменённый конфиг, неожиданный исполняемый файл — сигнал. - **Сетевой контроль (L3–L7).** Карта реальных коммуникаций между подами, выявление обращений к неизвестным адресам и enforcement сетевых политик. - **Автоматическая реакция.** От алерта до активного ответа: блокировка процесса, заморозка контейнера, его остановка или изоляция пода по политике.
Shift-left и runtime: не «или», а «и»
Зрелая защита контейнеров — это конвейер из двух взаимодополняющих контуров. Shift-left дешевле исправлять (баг чинится в коде и образе), runtime ловит то, что в принципе нельзя увидеть до запуска. Ниже — в чём они различаются и почему нужны вместе.
| Критерий | Shift-left (сканирование образов) | Runtime-защита |
|---|---|---|
| Когда работает | До запуска: сборка, реестр, CI/CD | Во время исполнения, в продакшене |
| Что видит | Состав образа, CVE, секреты, конфигурацию | Процессы, сеть, syscalls, файловую активность |
| Источник данных | Артефакт (статический снимок) | Поведение в ядре (часто eBPF) |
| Какие угрозы ловит | Известные уязвимости и мисконфиги до старта | Эксплуатацию, drift, реверс-шелл, побег, майнинг |
| Слабое место | Не видит происходящее после старта | Не предотвращает попадание уязвимости в образ |
| Реакция | Блок сборки/деплоя по политике | Алерт, заморозка, остановка, изоляция пода |
Угроза в runtime → как её обнаружить
Чтобы оценка решения не была абстрактной, полезно идти от конкретных сценариев атаки к тому, какой механизм runtime-защиты их закрывает. Эту таблицу удобно использовать как основу для сценариев пилота.
| Угроза в runtime | Как проявляется | Чем обнаруживается |
|---|---|---|
| Эксплуатация уязвимости в работающем сервисе | Нетипичный процесс/syscall от веб-сервера | Поведенческий профиль процессов, eBPF-перехват |
| Реверс-шелл / C2-канал | Исходящее соединение к неизвестному адресу | Сетевой мониторинг, обнаружение аномалий L3–L7 |
| Криптомайнер после старта | Новый процесс с высокой нагрузкой CPU | Drift процессов, аномалия поведения |
| Drift файловой системы | Новый бинарь, изменённый конфиг в поде | Сравнение с эталоном образа, контроль ФС |
| Побег из контейнера | Доступ к хосту, привилегированные syscalls | Перехват syscalls, контроль capabilities в ядре |
| Подозрительный `kubectl exec` | Интерактивная оболочка в продовом поде | Аудит exec-сессий, поведенческие политики |
| Компрометация цепочки поставки | Доверенный образ делает неожиданные вызовы | Поведенческий контроль вместо доверия к источнику |
Кто представлен на рынке: ориентир
Ниже — ориентир по типам поставщиков, а не рейтинг. Места, баллы и подтверждённые сигналы смотрите в [рейтинге категории](/rating/container-kubernetes-security). Цель — показать, что runtime-защита бывает разной по архитектуре и происхождению.
| Тип решения | Чем характерен | Чаще всего подходит для |
|---|---|---|
| Российские платформы (ориентир: Luntry и др.) | Видимость и runtime для Kubernetes, упор на реестр и комплаенс | КИИ, госсектор, импортозамещение |
| Зарубежные CNAPP (ориентир: Aqua, Sysdig, Prisma Cloud) | Зрелый runtime + сканирование в одной платформе | Компании без ограничений на иностранное ПО |
| Open-source ядро (ориентир: Falco, Tetragon) | eBPF-движок обнаружения, требует сборки процессов вокруг | Команды с сильным DevSecOps in-house |
Чек-лист выбора runtime-защиты контейнеров
Как внедрить runtime-защиту: 5 шагов
-
01
Инвентаризация
Опишите кластеры, namespace'ы и критичные сервисы, оцените текущее покрытие сканированием образов.
-
02
Базовая телеметрия
Разверните сбор поведенческих данных (eBPF) в режиме наблюдения, без enforcement, чтобы собрать эталон.
-
03
Профилирование и тюнинг
Постройте профили нормального поведения, разберите ложные срабатывания, настройте политики.
-
04
Сценарии атак
Прогоните реверс-шелл, drift, майнер и попытку побега на стенде — проверьте обнаружение и реакцию.
-
05
Enforcement и реакция
Включите активный ответ по критичным политикам, интегрируйте алерты в SOC/SIEM, переходите к продакшену.
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом Container и Kubernetes Security](/rating/container-kubernetes-security): здесь — суть и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались, зачем runtime поверх сканирования, — переходите к сравнению поставщиков: **[рейтинг Container и Kubernetes Security →](/rating/container-kubernetes-security)**. Полезно прочитать рядом: [безопасность контейнеров и Kubernetes — с чего начать](/research/bezopasnost-konteynerov-kubernetes), [рейтинг платформ Container & Kubernetes Security 2026](/research/rejting-container-kubernetes-security-2026) и [чем заменить Aqua, Sysdig и Prisma Cloud](/research/zamena-aqua-sysdig-prisma-cloud).
Частые вопросы
Если я уже сканирую образы, зачем мне runtime-защита?
Сканирование закрывает вход: известные CVE, секреты, мисконфиги до запуска. Но эксплуатация уязвимости, реверс-шелл, майнер, drift и побег из контейнера происходят уже в работающем поде и в статике образа не видны. Runtime — это второй контур, который наблюдает за поведением во время исполнения.
Что такое eBPF и почему его так часто упоминают?
eBPF — технология, позволяющая безопасно выполнять программы в ядре Linux и перехватывать системные вызовы, сетевые и процессные события с низкими накладными расходами и без модификации приложения. Для runtime-защиты это удобный источник глубокой видимости.
Что такое drift и чем он опасен?
Drift — расхождение работающего контейнера с исходным образом: доустановленный пакет, подменённый бинарь, изменённый конфиг. Это признак ручного вмешательства или компрометации. Контейнеры задумывались неизменяемыми, поэтому любой drift — повод для проверки.
Заменяет ли runtime-защита сетевые политики Kubernetes?
Нет, она их дополняет. Сетевые политики задают разрешённые коммуникации, а runtime-защита наблюдает за реальным трафиком, выявляет обращения к неожиданным адресам и помогает enforcement'у. Лучший результат — когда оба механизма работают вместе.
Где сравнить конкретных вендоров между собой?
В рейтинге Container и Kubernetes Security — там поставщики ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
Сканирование образов (shift-left) ловит известные уязвимости и проблемы конфигурации **до** запуска — это нужный, но не достаточный слой. В работающем контейнере появляются угрозы, которых не было в образе: эксплуатация уязвимости в рантайме, запуск постороннего процесса, обращения в неожиданные сети, drift (изменение файловой системы относительно образа), попытки выхода за пределы контейнера. Поймать это можно только наблюдая за поведением во время исполнения. **Если коротко:** образ — это снимок на момент сборки, а атака происходит вживую. Runtime-защита добавляет поведенческий контроль ядра (часто через eBPF), обнаружение отклонений от эталона, мониторинг сети и автоматическую реакцию (алерт, заморозка, остановка пода). Ниже — почему одного сканирования мало, что именно даёт runtime, как соотносятся shift-left и runtime и на что смотреть при выборе. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге Container и Kubernetes Security](/rating/container-kubernetes-security).