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

Спонсорский контент

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

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

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

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

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

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

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

Сложная упаковка затрудняет отслеживание контактов.

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

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

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

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

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

Для исправлений, сгенерированных ИИ, по-прежнему необходим контекст программного обеспечения.

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

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

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

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

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

Обнаружение недостатка, возможно, больше не является самым медленным этапом.

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

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

Источник: www.artificialintelligence-news.com