Как ИИ меняет сроки реагирования на уязвимости

Искусственный интеллект предоставляет исследователям в области безопасности новые способы анализировать код, отслеживать необычное поведение и выявлять недостатки, которые могут оставаться незамеченными для традиционных инструментов. Особенно заметно это в случае уязвимостей нулевого дня: в недавнем анализе Minimus рассматривается, как состав контейнеров, записи о зависимостях и скорость пересборки влияют на реагирование после обнаружения неизвестной уязвимости. Более быстрый анализ помогает только тогда, когда организации также могут установить, где запущено уязвимое программное обеспечение.

ИИ выявляет недостатки, которые могут пропустить традиционные инструменты

В мае 2026 года Google Threat Intelligence Group сообщила о первом случае, когда, по её мнению, злоумышленник использовал ИИ для помощи в разработке эксплойта нулевого дня. Эксплойт содержался в скрипте на Python и позволял обойти двухфакторную аутентификацию в широко используемом инструменте администрирования систем с открытым исходным кодом, если действительные учётные данные уже имелись.

Исследователи заявили, что с высокой степенью уверенности считают: модель ИИ помогла как обнаружить уязвимость, так и превратить её в оружие. Их оценка основывалась на необычно подробных поясняющих комментариях в скрипте, вымышленной оценке уязвимости и высокоструктурированном стиле программирования, характерном для сгенерированного кода. Google не утверждала, что более широкая операция была автономной, и не приписывала код конкретной модели.

Именно сама уязвимость делает этот случай значимым. Она была связана с жёстко заданным допущением о доверии, а не со сбоем, ошибкой памяти или небезопасным вводом. Фаззеры и инструменты статического анализа хорошо подходят для выявления многих традиционных проблем реализации. Языковая модель также может анализировать взаимодействие разрешений, функций и ожидаемого поведения в разных частях кодовой базы. Это создаёт ещё один способ находить логические противоречия, не оставляющие очевидных технических следов.

Более широкие данные Google свидетельствуют о том, что это не единичная проблема. Согласно анализу Google Threat Intelligence Group за 2025 год, исследователи отслеживали 90 уязвимостей нулевого дня, эксплуатировавшихся в реальных атаках в течение 2025 года, по сравнению с 78 в 2024 году. На корпоративное программное обеспечение и устройства пришлось 43 случая, или 48% от общего числа. Оба показателя стали рекордными в наборе данных Google.

Сложные контейнеры затрудняют отслеживание уязвимых компонентов

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

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

Уязвимость Log4Shell в 2021 году продемонстрировала масштаб этой проблемы. Затронутая библиотека Log4j была включена в широкий спектр продуктов и сервисов. Для многих организаций получение исправления стало лишь началом. Им всё ещё требовалось найти каждый сервер, приложение и контейнер с уязвимой версией, прежде чем завершить устранение проблемы.

Перечни компонентов программного обеспечения предоставляют более ясную информацию о содержимом каждого образа. Небольшие образы также могут сузить область поиска, исключая пакеты, которые не нужны рабочей нагрузке. Minimus рассматривает эту проблему через сокращение числа пакетов, прозрачность зависимостей и пересборку образов после раскрытия информации о затронутом компоненте.

Преимущество заключается не в том, что минимальный образ полностью предотвращает уязвимости нулевого дня. В нём всё ещё может содержаться неизвестная уязвимость. Однако командам приходится исследовать меньше пакетов, проверять меньше потенциальных точек воздействия и заменять или повторно тестировать меньше программного обеспечения после того, как проблема становится известна.

Сгенерированные ИИ исправления по-прежнему требуют контекста программного обеспечения

ИИ также используется для сокращения времени между раскрытием информации об уязвимости и разработкой исправления. Модели могут анализировать исходный код, сопоставлять отчёты об уязвимостях с записями о пакетах и предлагать изменения для затронутых версий. Всё это не особенно полезно, если записи о пакетах устарели или никто не знает, в каких образах содержится уязвимый компонент.

В более раннем материале об ИИ-агенте, предназначенном для автоматизации исправления уязвимостей подробно рассказывалось, как CodeMender от Google DeepMind за первые шесть месяцев работы внёс 72 исправления безопасности в известные проекты с открытым исходным кодом. Система объединяет рассуждения модели со статическим анализом, тестированием во время выполнения и фаззингом для создания и оценки предлагаемых исправлений.

Эти исправления не принимались автоматически. Исследователи вручную проверяли каждое изменение перед отправкой, выявляя регрессии и подтверждая, что оно устраняет первопричину, а не только видимый симптом.

Даже одобренное изменение кода не завершает работу. Команды должны определить затронутые образы, пересобрать их с исправленной зависимостью и протестировать результат перед развёртыванием. В среде с плохо документированной инфраструктурой поиск каждого экземпляра может занять больше времени, чем создание самого исправления.

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

Поиск уязвимости больше не обязательно является самым медленным этапом

ИИ ускоряет анализ кода как для злоумышленников, так и для защитников, однако многие задержки по-прежнему возникают после обнаружения уязвимости. Одна команда может потратить несколько часов, открывая образы и вручную проверяя списки пакетов. Другая может выполнить поиск в актуальном реестре и почти сразу увидеть, какие рабочие нагрузки содержат затронутую версию.

Эта разница почти не связана с совершенством инструмента обнаружения. Она обусловлена решениями, принятыми ранее в отношении инвентаризации программного обеспечения, состава образов и способов сборки и замены контейнеров. По мере ускорения исследований уязвимостей практическое преимущество получают организации, способные установить масштаб воздействия и развернуть протестированное исправление, не пытаясь сначала восстановить представление о содержимом своих систем.