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

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

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

Увеличение числа нулевых уязвимостей

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

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

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

Программные счета материалов как решение

Программные счета материалов (SBOM) предоставляют более четкую запись того, что содержится в каждом образе. Более мелкие образы также могут сократить поиск, исключив пакеты, которые рабочая нагрузка не требует. Minimus рассматривает эту проблему через призму уменьшения пакетов, видимости зависимостей и пересборки образов после раскрытия затронутого компонента. Преимущество здесь заключается не в предотвращении нулевых уязвимостей вообще. Минимальный образ все еще может содержать неизвестный недостаток. Он предоставляет командам меньше пакетов для расследования, меньше возможных точек воздействия и меньше программного обеспечения для замены или повторного тестирования после того, как проблема становится известной.

ИИ для ускорения разработки патчей

ИИ также используется для сокращения времени между раскрытием и разработкой патча. Модели могут проверять исходный код, сравнивать отчеты о уязвимостях с записями пакетов и предлагать изменения для затронутых версий. Однако это не особенно полезно, когда записи пакетов устарели или никто не знает, какие образы содержат уязвимый компонент. Ранее сообщалось о агенте ИИ, предназначенном для автоматизации исправлений уязвимостей, который, согласно данным Google DeepMind, внес 72 исправления безопасности в устоявшиеся проекты с открытым исходным кодом за первые шесть месяцев. Система сочетает в себе моделирование рассуждений с статическим анализом, тестированием в реальном времени и фуззингом для создания и оценки предложенных патчей. Эти патчи не принимались автоматически. Человеческие исследователи проверяли каждое изменение перед его отправкой, проверяя на наличие регрессий и подтверждая, что оно устраняет основную причину, а не только видимый симптом. Даже утвержденное изменение кода не завершает работу. Команды должны идентифицировать затронутые образы, пересобрать их с исправленной зависимостью и протестировать результат перед развертыванием. В плохо документированной среде нахождение каждого экземпляра может занять больше времени, чем создание самого патча.

Важность точных инвентаризаций

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