ИИ для поиска уязвимостей сайтов уже может участвовать не только в анализе исходного кода, но и в проверке найденных проблем и подготовке исправлений. Разбираем, как устроен такой подход на примере Gemini 4 Argon, какие задачи модели способны выполнять самостоятельно и почему результат всё равно должен проходить проверку специалистов.

Как работает ИИ для поиска уязвимостей сайтов

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

В описании Gemini 4 Argon указано, что модель последовательно изучает исходные файлы, составляет план, запускает инструменты, проверяет промежуточный результат и исправляет обнаруженные ошибки. Такой сценарий похож на работу ИИ-агента: система не выдаёт один ответ после анализа запроса, а выполняет цепочку действий и возвращается к предыдущим шагам, если результат оказался недостаточным.

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

Что умеют современные модели и ИИ-агенты

ИИ-анализ исходного кода полезен на нескольких этапах разработки и сопровождения веб-систем:

  • поиск подозрительных участков кода и потенциальных уязвимостей;
  • объяснение причины проблемы понятным для разработчика языком;
  • составление плана исправления и подготовка патча;
  • запуск тестов, линтеров и других инструментов проверки;
  • повторный анализ после внесения изменений;
  • поиск связанных ошибок в соседних модулях.

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

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

Что известно о Gemini 4 Argon

Google позиционирует Gemini 4 Argon как модель, способную самостоятельно искать, проверять и исправлять уязвимости в программном обеспечении. Доступ к ней на стартовом этапе предоставляют проверенным специалистам по кибербезопасности в рамках программы Fairwind. Позже Google планирует расширить круг пользователей до разработчиков, корпоративных клиентов и потребителей, но точные сроки полноценного публичного запуска в доступных материалах не указаны.

По данным Интерфакса, на начальном этапе использование модели заявлено по тарифу 2 доллара за 1 млн входных токенов и 10 долларов за 1 млн выходных. После вводного периода эти цены должны вырасти в два раза. Для агентных задач расходы могут зависеть не только от размера исходного кода, но и от числа повторных проверок, запуска инструментов и исправлений.

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

Где ИИ для устранения уязвимостей сайтов приносит пользу

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

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

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

Риски использования ИИ в кибербезопасности

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

Есть и другие ограничения:

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

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

Что это значит для бизнеса

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

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

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

Gemini 4 Argon показывает, к чему движется искусственный интеллект в кибербезопасности: от подсказок разработчику к многоэтапной работе с кодом и инструментами. Однако пока наиболее безопасная роль такой модели - ускорять анализ и подготовку решений, оставляя проверку, управление доступами и выпуск изменений под контролем специалистов.