Когда возникает активная уязвимость нулевого дня, подобная недавней PHP2Shell, инструменты безопасности активируются в течение нескольких минут, фиксируя критические производственные риски, требующие немедленного устранения. И хотя ИИ ускорил обнаружение уязвимостей, их исправление по-прежнему зависит от координации действий людей.
Однако внедрение такого исправления выходит далеко за рамки команды безопасности и становится общекорпоративной задачей. Команды безопасности обнаруживают риск, но они не владеют кодом, инфраструктурой или конвейерами развертывания. Устранение проблемы требует координации между тремя различными командами, у каждой из которых свои приоритеты:
- Безопасность: Стремится немедленно устранить эксплуатируемый риск.
Безопасность: Стремится немедленно устранить эксплуатируемый риск.
- Разработка: Стремится поддерживать скорость поставки без нарушения зависимостей и траты времени на поиск правильного исправления.
Разработка: Стремится поддерживать скорость поставки без нарушения зависимостей и траты времени на поиск правильного исправления.
- Облачные / платформенные операции: Стремятся сохранить время безотказной работы и стабильность инфраструктуры.
Облачные / платформенные операции: Стремятся сохранить время безотказной работы и стабильность инфраструктуры.
Поскольку каждая команда работает в рамках собственных рабочих процессов и согласно собственной дорожной карте, устранение уязвимостей превращается в дорогостоящую игру в межотраслевой пинг-понг. Заявки пересылаются между командами, разработчики тратят часы на определение специфичного для среды исправления, а среднее время устранения (MTTR) растет.
Чтобы сократить этот разрыв, организациям необходим мост между контекстом среды выполнения и действиями разработчиков, благодаря которому исправление станет автоматизированным и непрерывным. Вот как ведущие команды используют Wiz Green Agent для преодоления трех основных узких мест при устранении уязвимостей, какого ROI они достигают и как эта работа приближает создание самовосстанавливающегося облака.
Три узких места, усложняющих устранение уязвимостей
Поиск ответственного за проблему
Прежде чем команда сможет исследовать или устранить риск, она сталкивается с первой преградой: кто на самом деле владеет уязвимым ресурсом? В динамичных мультиоблачных, гибридных средах или средах ИИ этот ответ найти непросто. Производственный контейнер мог быть развернут через общий конвейер, создан инженером, сменившим команду несколько месяцев назад, или запущен в разных аккаунтах с отсутствующими тегами и устаревшей CMDB. Когда ответственность не ясна, проблемы зависают без назначения в очередчах бэклога или пересылаются между командами Platform, DevOps и AppSec в попытках выяснить, какому именно репозиторию или сервису принадлежит проблема.
Эта задержка с поиском владельца увеличивает циклы устранения еще до того, как работа успевает начаться.
Как Green Agent решает эту проблему
Green Agent исключает угадывание владельца, связывая сигналы из всей вашей среды. Анализируя историю коммитов репозитория, назначения в Wiz Project, каталоги сервисов, интеграции с CMDB и облачные логи, Green Agent автоматически определяет предполагаемого исполнителя (Suggested Assignee): конкретного разработчика или специалиста, лучше всего подготовленного к действиям.
Команды безопасности могут назначить проблему правильному владельцу в один клик прямо внутри панели проблемы, гарантируя, что она попадет к человеку, который действительно сможет объединить исправление (merge).
Именно благодаря такому анализу такие команды, как Rogo (корпоративная ИИ-платформа для финансовых учреждений), избавляются от ручной межфункциональной детективной работы, сохраняя при этом высокую скорость разработки в AWS и GCP:
С Green Agent это отображается автоматически в Wiz Issue и невероятно ценно для поиска нужного человека, чтобы наши разработчики могли быстро устранить проблему.Эрик Ту (Eric Tu), инженер по безопасности продуктов, Rogo
С Green Agent это отображается автоматически в Wiz Issue и невероятно ценно для поиска нужного человека, чтобы наши разработчики могли быстро устранить проблему.
Эрик Ту (Eric Tu), инженер по безопасности продуктов, Rogo
Понимание рисков на уровне первопричины
Когда критическая проблема безопасности попадает в очередь разработчика, ему нужны четкие, действенные ответы о том, что именно нужно исправить, где это находится в коде и как это исправить, чтобы можно было вернуться к выпуску новых функций. Получение этих ответов начинается с прослеживания пути от среды выполнения к коду для понимания первопричины.
Это означает подтверждение того, что рабочая нагрузка действительно подвержена риску, проверку доступности уязвимого пакета, а также определение исходного репозитория, Dockerfile или коммита, который привел к проблеме. Выполнение этой работы по установлению фактов вручную для каждого оповещения происходит медленно и монотонно. В масштабах облака, когда ИИ каждую неделю отправляет в производство все больше кода, это отнимает основную часть времени на триаж до того, как можно будет приступить к исправлению.
Как Green Agent решает эту проблему
Green Agent автоматизирует все это расследование «под капотом». Для каждой проблемы он анализирует граф безопасности Wiz Security Graph, чтобы оценить воздействие в среде выполнения, управление доступом и сопоставление кода с облаком для понимания первопричины. Он подтверждает, действительно ли риск является эксплуатируемым, и рекомендует, устранить ли проблему или скорректировать степень ее серьезности, чтобы разработчики сосредоточились на высокоприоритетных рисках, а затем точно указывает файл и строку в исходном коде, ответственные за уязвимость.
В результате работы механизма расследований на основе ИИ от Green Agent компания Fireblocks, поставщик инфраструктуры цифровых активов и блокчейна, сократила время ежедневного операционного триажа более чем на 70% и теперь добивается устранения критических рисков в тот же день.
Green Agent объясняет весь контекст; он показывает все наши рабочие нагрузки и точный путь устранения для любой проблемы. Все пути устранения действительно понятны... До Red Agent, Green Agent и интеграции с Cloudflare у нас были ручные процессы триажа. Теперь мы получаем более четкие результаты и более быстрое устранение, что сокращает объем необходимых ручных операционных часов.Рой Вайс (Roy Weiss), ведущий специалист по DevSecOps, Fireblocks
Green Agent объясняет весь контекст; он показывает все наши рабочие нагрузки и точный путь устранения для любой проблемы. Все пути устранения действительно понятны... До Red Agent, Green Agent и интеграции с Cloudflare у нас были ручные процессы триажа. Теперь мы получаем более четкие результаты и более быстрое устранение, что сокращает объем необходимых ручных операционных часов.
Рой Вайс (Roy Weiss), ведущий специалист по DevSecOps, Fireblocks
Превращение оповещений в готовые исправления для разработчиков
Даже когда назначен правильный владелец и определена первопричина, последней точкой трения остается исполнение: превращение этой проблемы в объединенный код (merged code).
Предоставление инженеру оповещения со ссылкой на общий бюллетень CVE заставляет его переключать контекст со своего спринта, искать потенциальные патчи и выяснять, как написать исправление без нарушения существующих зависимостей. Разработчики сосредоточены на создании и выпуске продуктовых функций; чтобы устранение уязвимостей двигалось со скоростью ИИ-инжиниринга, специфичное для среды исправление должно предлагаться разработчикам непосредственно в их повседневных рабочих процессах.
Как Green Agent решает эту проблему
Green Agent закрывает этот пробел, генерируя предписанные, зависящие от окружения варианты устранения. Он предоставляет код или изменения Terraform вплоть до конкретной строки и предлагает Pull Requests в 1 клик или передачу задач агентам по программированию, чтобы разработчики могли просто проверить, подтвердить и выполнить слияние. Для команд, создающих продукты с использованием ИИ, Green Agent также предоставляет свой контекст устранения через API и сервер Wiz Model Context Protocol (MCP), позволяя разработчикам получать рекомендации Green Agent по устранению неполадок прямо в своих агентских средах разработки для ускорения исправления.
Встречая разработчиков там, где они работают, и избавляя их от необходимости ручного поиска, project44, глобальная платформа видимости цепочек поставок, ускорила скорость устранения в 10 раз, сохранив при этом внимание инженеров на приоритетах дорожной карты:
ИИ повысил скорость написания кода для инженеров; Green Agent от Wiz предлагает аналогичное увеличение скорости для работы по обеспечению безопасности. Мэтью Блакерт (Matthew Blackert), менеджер по операционной безопасности, project44
ИИ повысил скорость написания кода для инженеров; Green Agent от Wiz предлагает аналогичное увеличение скорости для работы по обеспечению безопасности.
Мэтью Блакерт (Matthew Blackert), менеджер по операционной безопасности, project44
Внедрение Wiz совместно с инженерным отделом показало нам, чего можно достичь, когда убираешь лишний шум: инженеры исправляют реальные риски, а не проверяют ложные срабатывания. Михайло Янкович (Mihajlo Jankovic), аналитик по операционной безопасности II, project44
Внедрение Wiz совместно с инженерным отделом показало нам, чего можно достичь, когда убираешь лишний шум: инженеры исправляют реальные риски, а не проверяют ложные срабатывания.
Михайло Янкович (Mihajlo Jankovic), аналитик по операционной безопасности II, project44
Устранение разрыва в исправлении
Скорость устранения больше не ограничивается тем, как быстро служба безопасности может обнаружить риски, она определяется тем, насколько плавно контекст безопасности преобразуется в действия разработчика.
Устраняя пробелы в контексте, автоматизируя распределение ответственности и предоставляя исправления кода в 1 клик, Wiz Green Agent превращает устранение уязвимостей из обременительной межфункциональной задачи в автоматизированный замкнутый рабочий процесс.
Узнайте больше о Green Agent в нашей документации (требуется вход в систему) или посмотрите демоверсию, чтобы оценить окупаемость (ROI), которую Green Agent может обеспечить для вашей среды.
