Критическая проблема была только что обнаружена в среде: доступный из интернета контейнер, запускающий образ с известной уязвимостью начального доступа, с привязанной ролью, которая может обращаться к конфиденциальным данным.
Поскольку скорость работы ИИ сокращает время от обнаружения до эксплуатации, давление с целью быстрого устранения проблемы велико. Тем не менее, исправление никогда не сводится только к скорости. Команды вынуждены балансировать между срочностью обеспечения безопасности и непрерывностью бизнеса, соревнуясь со временем, чтобы ответить на три критически важных вопроса: что затронуто, каково решение и кому это решение отправить.
Граф безопасности Wiz Security Graph помогает командам безопасности ответить на первый вопрос. Он представляет точный путь реализации угрозы, включая уязвимые эндпоинты, развертывание за ними, образ, в котором находится CVE, и путь латерального перемещения, который переносит злоумышленника от выполнения кода к бакетам, содержащим персональные данные (PII).
Однако поиск решения и ответственного лица требует более глубокого расследования, на которое команды безопасности не могут тратить часы. Им необходимо быстро связаться с разработчиком для развертывания исправления, если оно вообще существует, и тем временем применить митигации без нарушения времени безотказной работы продукции.
Именно для этого мы создали Green Agent. В этой статье мы рады приоткрыть завесу тайны и поделиться тем, как Green Agent исследует эту конкретную проблему за считанные минуты и определяет рекомендуемые им стратегии исправления.
Расследование
1. Понимание проблемы
Green Agent начал с поглощения контекста Графа безопасности для сопоставления полного пути атаки. Эта проблема представляла собой токсичную комбинацию, сосредоточенную вокруг одного развертывания Kubernetes в кластере AWS EKS.
Граф безопасности сопоставил пять различных типов рисков, сходящихся в этой единственной рабочей нагрузке:
- Внешнее воздействие: прямой сетевой путь из интернета в контейнер.
Внешнее воздействие: прямой сетевой путь из интернета в контейнер.
- Уязвимость: известная уязвимость CVE-2026-111497 начального доступа в образе контейнера.
Уязвимость: известная уязвимость CVE-2026-111497 начального доступа в образе контейнера.
- Небезопасный кластер Kubernetes: под, монтирующий токен учетной записи службы для перехода в облако.
Небезопасный кластер Kubernetes: под, монтирующий токен учетной записи службы для перехода в облако.
- Незащищенный субъект: роль IAM, предоставляющая рабочей нагрузке доступ к облачному хранилищу.
Незащищенный субъект: роль IAM, предоставляющая рабочей нагрузке доступ к облачному хранилищу.
- Незащищенные данные: конфиденциальные записи клиентов, находящиеся в этих доступных бакетах.
Незащищенные данные: конфиденциальные записи клиентов, находящиеся в этих доступных бакетах.
Пять типов рисков означали пять различных мест, где цепочка атак могла быть разорвана — будь то путем удаления публичного доступа, исправления образа контейнера, размонтирования токена учетной записи службы, ограничения роли IAM или очистки конфиденциальных данных.
Прежде чем рекомендовать, как разорвать цепочку без нарушения времени безотказной работы продукции, Green Agent должен был проверить фактическое положение дел (ground truth) для каждого фактора риска. Он начал пошаговое расследование пути атаки, начиная с периметра.
2. Проверка воздействия: действительно ли парадная дверь открыта?
Прежде чем рекомендовать исправление, Green Agent должен был определить, является ли сетевая изоляция вообще вариантом. Многие облачные рабочие нагрузки выглядят публичными в таблицах конфигурации, но на самом деле защищены внутренними подсетями, VPN или закрытыми группами безопасности.
Green Agent проследил полный входящий маршрут от 0.0.0.0/0:
- Маршрут входящего трафика (Ingress): трафик шел из публичного интернета через интернет-шлюз AWS Internet Gateway, маршрутизировался через сетевой балансировщик нагрузки AWS Network Load Balancer, проходил через контроллер Ingress Traefik и попадал напрямую в основной контейнер приложения.
Маршрут входящего трафика (Ingress): трафик шел из публичного интернета через интернет-шлюз AWS Internet Gateway, маршрутизировался через сетевой балансировщик нагрузки AWS Network Load Balancer, проходил через контроллер Ingress Traefik и попадал напрямую в основной контейнер приложения.
- Неаутентифицированный доступ: как HTTP (порт 80), так и HTTPS (порт 443) обслуживали публичные эндпоинты, возвращающие неаутентифицированные статусы 2XX.
Неаутентифицированный доступ: как HTTP (порт 80), так и HTTPS (порт 443) обслуживали публичные эндпоинты, возвращающие неаутентифицированные статусы 2XX.
- Отсутствие защиты периметра: Green Agent проверил хопы и подтвердил, что брандмауэр веб-приложений (WAF) или правила брандмауэра отсутствуют.
Отсутствие защиты периметра: Green Agent проверил хопы и подтвердил, что брандмауэр веб-приложений (WAF) или правила брандмауэра отсутствуют.
Это установило критическую оперативную границу для исправления. Поскольку этот фронтенд был намеренно публичным производственным сервисом, простое отключение сети — например, удаление Ingress или блокировка балансировщика нагрузки — привело бы к полному сбою производства. Любой план исправления на сетевом уровне от Green Agent должен был сохранять время безотказной работы, например, внедрение промежуточного ПО (middleware) аутентификации вместо полного прекращения трафика.
3. Оценка эксплуатируемости: запускается ли уязвимость в памяти?
Убедившись, что парадная дверь открыта, Green Agent перешел к следующему звену цепочки атак: фактору риска уязвимости, чтобы оценить, может ли путь атаки быть разорван на уровне приложения.
Он исследовал изъян в образе контейнера: CVE-2026-111497 («Broccoli2Shell»), критическую уязвимость RCE в декодере Brotli, встроенном в Node.js и зарегистрированном в каталоге известных эксплуатируемых уязвимостей (KEV) CISA.
Он подтвердил с помощью Wiz Sensor, что уязвимые библиотеки Brotli активно загружались в память запущенным процессом Node.js, подтвердив, что выполнение кода является реальной и жизнеспособной угрозой.
Green Agent также проверил вышестоящие бюллетени безопасности и подтвердил, что патчи от вендора (включая Node.js 22.23.4 и libbrotli 1.2.1) уже доступны, подтвердив жизнеспособность постоянного исправления кода.
Однако организационные процессы релизов означают, что развертывание нового образа контейнера через тестирование и CI/CD пайплайны требует времени. Поскольку путь атаки может быть разорван по любому из пяти типов рисков, Green Agent обратился к оставшимся звеньям — конфигурации Kubernetes, роли IAM и конфиденциальным данным — чтобы выяснить, можно ли немедленно разорвать токсичную комбинацию в облаке.
4. Оценка облачных идентификационных данных и данных: можно ли разорвать облачный путь?
Исследуя подключение рабочей нагрузки к облачному хранилищу, Green Agent оценил оставшиеся три типа рисков:
- Рычаг исправления кластера (IRSA): Green Agent изучил учетную запись службы Kubernetes и подтвердил, что она проецирует облачные учетные данные через IRSA в контейнер. Это выявило немедленный рычаг митигации: отключение автомонтирования токена в спецификации пода для перекрытия доступа к облаку.
Рычаг исправления кластера (IRSA): Green Agent изучил учетную запись службы Kubernetes и подтвердил, что она проецирует облачные учетные данные через IRSA в контейнер. Это выявило немедленный рычаг митигации: отключение автомонтирования токена в спецификации пода для перекрытия доступа к облаку.
- Рычаг исправления IAM: проверяя предполагаемую роль IAM, Green Agent обнаружил избыточные привилегии s3:GetObject и подстановочные знаки s3:* для трех бакетов S3. Это выявило второй рычаг: ограничение политики IAM до наименьших привилегий.
Рычаг исправления IAM: при проверке принятой роли IAM Green Agent обнаружил избыточные права s3:GetObject и подстановочные знаки s3:* в трех корзинах S3. Это выявило второй рычаг: ограничение политики IAM до минимально необходимых прав.
- Рычаг исправления данных: запрос к корзинам S3 выявил более 5000 незамаскированных записей (кредитные карты и PII) в файлах, что определило третий рычаг исправления: удаление или маскирование незащищенных данных в состоянии покоя.
Рычаг исправления данных: запрос к корзинам S3 выявил более 5000 незамаскированных записей (кредитные карты и PII) в файлах, что определило третий рычаг исправления: удаление или маскирование незащищенных данных в состоянии покоя.
Расследование этих уровней доказало, что Green Agent не нужно ждать развертывания кода, чтобы нейтрализовать риск. В облаке уже были доступны несколько рычагов, не требующих простоя.
5. Прослеживаемость от кода до облака: поиск источника и владельцев
Облачные меры по смягчению последствий могут немедленно разорвать путь атаки и выиграть критически важное время, но для постоянного исправления необходимо устранить проблему в источнике. Если изменения не зафиксированы в коде, следующая сборка CI/CD или применение Terraform просто перезапишут ваши облачные настройки и воссоздадут проблему. Green Agent вызвал свой под-агент кода (Code Subagent), чтобы связать ресурсы среды выполнения с системой контроля версий, отследив образ контейнера до исходного Dockerfile, избыточную роль IAM до определений Terraform, а рабочую нагрузку до манифестов развертывания GitOps.
Изучая историю коммитов и метаданные, Green Agent связал каждое исправление напрямую с инженерами, которые фактически поддерживают код: разработчиком приложения, владельцем сервиса и руководителем инфраструктуры, чтобы командам безопасности не приходилось искать нужного владельца.
6. Вынесение вердикта и создание планов исправления
В течение нескольких минут Green Agent проанализировал организационный контекст, чтобы прийти к выводу, что эту проблему необходимо устранить и она имеет критическую степень серьезности. Green Agent учел реальное влияние на бизнес: рабочая нагрузка принадлежала производственным проектам с высоким уровнем влияния на бизнес (HBI), формировала активный путь взлома к более чем 5000 конфиденциальных записей и соответствовала историческим данным об исправлении, показывающим, что 100% аналогичных проблем в подписке были успешно устранены с 0% уровнем отказов.
Чтобы разорвать эту опасную комбинацию, Green Agent определил, что планы по смягчению (Mitigate) и исправлению (Fix) являются наиболее подходящими для устранения выявленных типов рисков, балансируя между немедленной защитой и постоянным решением:
- Планы смягчения (Mitigate): немедленные действия, которые команды безопасности могут предпринять прямо сейчас, чтобы снизить риск, например, отключение автоматического монтирования токена сервисной учетной записи, чтобы мгновенно перекрыть доступ к облаку, пока разработчики работают над исправлением кода.
Планы смягчения (Mitigate): немедленные действия, которые команды безопасности могут предпринять прямо сейчас, чтобы снизить риск, например, отключение автоматического монтирования токена сервисной учетной записи, чтобы мгновенно перекрыть доступ к облаку, пока разработчики работают над исправлением кода.
- Планы исправления (Fix): постоянные решения первопричин, такие как обновление базового образа в Dockerfile или ограничение политик IAM в Terraform.
Планы исправления (Fix): постоянные решения первопричин, такие как обновление базового образа в Dockerfile или ограничение политик IAM в Terraform.
Не менее важно то, что Green Agent оценил операционные компромиссы, чтобы исключить нежизнеспособные стратегии: он явно отклонил удаление входящего трафика (ingress), поскольку отключение намеренно публичного фронтенда вызвало бы полный сбой производства, и пропустил долгосрочное ужесточение защиты там, где не были соблюдены предварительные условия среды.
Наконец, Green Agent превратил планирование в исполнение, назначив каждый план непосредственно его проверенному владельцу, готовому к разрешению через pull request в один клик или путем передачи инструкций напрямую агенту кодирования.
Почему это важно
Green Agent привнес в это исправление две вещи, которые, как известно, трудно сбалансировать в безопасности: решение срочных вопросов безопасности и поддержание контекста, необходимого для защиты непрерывности бизнеса.
Во-первых, скорость. Поскольку риски и угрозы растут быстрее, чем когда-либо, срочность безопасности требует немедленного реагирования. Команда людей, расследующая эту опасную комбинацию, потратила бы часы или дни на переключение контекста: аналитики безопасности проверяли бы публичную конечную точку, платформенные инженеры проверяли бы, находится ли библиотека Brotli в памяти, облачные администраторы проводили бы аудит политик IAM, а разработчики искали бы, какой репозиторий Git собрал образ. Green Agent провел это расследование за считанные минуты, устранив трения и догадки, которые обычно тормозят исправление.
Во-вторых, операционная аналитика. Исправление — это проблема не только команды безопасности, это организационное решение, требующее понимания реальных компромиссов. Green Agent знал, что не стоит предлагать удаление входящего трафика и отключение публичного сервиса, что повлияло бы на бизнес. Вместо этого он провел различие между немедленными облачными мерами по смягчению последствий без простоя и постоянными исправлениями кода, нашел точные файлы в системе контроля версий и назначил работу непосредственно инженерам, которые ими владеют.
Этот баланс — то, как организации могут двигаться к автономному исправлению. Доверие должно быть заслужено, прежде чем команды передадут ключи к автоматическому исполнению. Это доверие строится на контексте: когда инженеры видят, что агент действительно понимает бизнес-компромиссы и не нарушит работу производства, они могут безопасно перейти от проверки каждого действия (человек в цикле) к надзорному контролю (человек над циклом).
Этот прогресс — то, что наконец позволяет командам встать на путь самовосстановления, возвращая инженерам время для дальнейшей работы.
