Поиск уязвимостей с помощью ИИ: методы и инструменты

Что значит «искать уязвимости с помощью ИИ»

Уязвимость — это ошибка в коде, конфигурации или архитектуре, которой может воспользоваться злоумышленник. Раньше такие ошибки искали двумя способами: вручную (аудит кода, тест на проникновение) и с помощью автоматических сканеров, работающих по заранее заданным правилам и сигнатурам.

Первый способ глубокий, но медленный и дорогой. Второй быстрый, но поверхностный: сканер не понимает, что именно делает код, поэтому он либо сыплет ложными срабатываниями, либо пропускает всё, что не вписывается в шаблон.

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

Основные направления применения ИИ

Под «поиском уязвимостей с ИИ» обычно понимают несколько разных задач, и важно не смешивать их между собой.

Статический анализ кода (SAST) с машинным обучением. Инструмент читает исходники, не запуская программу, и оценивает, какие участки опасны. ИИ помогает отсеивать ложные срабатывания и ранжировать находки по реальной критичности.

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

Умный фаззинг. Фаззинг — это подача программе огромного количества случайных и «кривых» данных, чтобы вызвать сбой. Нейросеть может генерировать более осмысленные входные данные и даже писать сами тестовые обвязки (fuzz targets), что раньше требовало ручной работы.

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

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

Что уже получилось на практике

Тема не ограничивается маркетингом: есть публичные результаты. В ноябре 2024 года Google сообщила, что её ИИ-агент Big Sleep нашёл в базе данных SQLite ранее неизвестную уязвимость, которую можно эксплуатировать. Ошибку исправили до выхода релиза, так что пользователи не пострадали. По заявлению компании, это один из первых публичных примеров, когда ИИ нашёл такую проблему в широко используемом ПО.

Тогда же Google рассказала об ИИ-фаззинге в проекте OSS-Fuzz. Языковые модели помогали автоматически писать фаззинг-обвязки для открытых библиотек, и этот подход выявил десятки новых ошибок. Среди них уязвимость в OpenSSL, которая, вероятно, существовала около двадцати лет и не обнаруживалась прежними инструментами.

Показателен и интерес государства к теме: конкурс DARPA AI Cyber Challenge в США был посвящён системам, которые автоматически находят и исправляют уязвимости в коде. Это говорит о том, что направление вышло за рамки экспериментов.

Где у ИИ слабые места

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

Вторая проблема — контекст. Модель видит ограниченный объём кода за один запрос и может не заметить, что опасное значение где-то в другом модуле уже проверено. В результате часть срабатываний оказывается ложной, а часть реальных проблем, наоборот, остаётся незамеченной.

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

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

Как подойти к внедрению

Лучше всего ИИ-анализ работает как часть процесса разработки, а не как разовая проверка перед релизом. Идея DevSecOps в том, чтобы безопасность проверялась на каждом изменении кода: автоматически и до того, как уязвимость попадёт в продакшен.

На рынке уже есть как зарубежные решения (GitHub Advanced Security с CodeQL и автоматическими подсказками по исправлению, Semgrep, Snyk), так и российские платформы анализа защищённости, например PT Application Inspector и Solar appScreener. Выбор зависит от языков программирования, требований к размещению данных и сертификации.

Ниже — последовательность, которая помогает внедрить технологию без хаоса и лишних сбоев в разработке.

А если это сайт, а не собственное ПО

Не у каждого бизнеса есть свой код для анализа, но почти у каждого есть сайт на готовой CMS с плагинами. Основные риски здесь — устаревшие версии, уязвимые расширения, слабые пароли и заражение вредоносным кодом.

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

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