Разработчик, который отвечает за JavaScript-движок V8, может не узнать о проблеме, пока баг не всплывёт в автоматическом тесте. В Google Project Zero за полгода посмотрели, что лучше ищет свежие уязвимости: генеративный фаззер Fuzzilli или агент на базе большой языковой модели BigSleep. Итог вышел не в пользу старых схем, но и без разгрома: 45 уязвимостей против 37.

Какую проблему решаем

Задача здесь простая и важная: понять, заменяет ли ИИ-агент классический фаззинг или пока только дополняет его. Для браузерного движка V8 это особенно заметно, потому что код сложный, а баги часто прячутся глубоко в логике исполнения.

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

Что подготовить

Если говорить не о внутренней кухне Project Zero, а о том, что из этого следует для обычной команды разработки, нужен минимум три вещи. Во-первых, автоматический поиск уязвимостей на уровне кода и тестов. Во-вторых, нормальная сортировка ложных срабатываний и дублей. В-третьих, привычка смотреть на проблему с двух сторон: старые методы и новые ИИ-инструменты.

Это ровно тот случай, когда один инструмент закрывает не все сценарии. В похожих историях уже видно, как важна комбинация методов — например, в разборе критической RCE-уязвимости GitLab или в материале про серверные логи и подозрительные запросы на Linux.

Пошаговые действия

Сначала исследователи посчитали все баг-репорты за апрель–сентябрь 2026 года. По сырым цифрам BigSleep выглядел лучше, но сюда попали и проблемы конфигурации, и интеграционные сбои, которые мало влияют на безопасность.

Затем из выборки оставили только уязвимости типа Type-Vuln. Тут картина стала честнее, но всё равно неидеальной: в данных остались дубликаты и репорты, которые фактически ничего не меняли. Поэтому следующим фильтром стали так называемые actionable-баги — те, что не закрыли как дубликат или „works as intended“ и по которым есть хотя бы один исправляющий коммит.

После этого сравнение выровнялось: у BigSleep оказалось 45 уязвимостей, у Fuzzilli — 37. Разница есть, но не такая, чтобы списывать фаззинг со счетов.

Как оценили пересечение результатов

Дальше Project Zero посмотрела, насколько два подхода ловят одни и те же баги. По данным баг-трекера пересечение оказалось заметным, но не полным: примерно четверть найденного совпала напрямую. Дополнительный эксперимент с попыткой заново найти старые баги Fuzzilli дал более высокую оценку — около 60 % пересечения на более длинной дистанции.

Смысл тут не в точной цифре до второго знака. Главный вывод в другом: у ИИ-агента и фаззера есть собственные зоны эффективности. Один находит то, что пропускает другой, и наоборот.

Что это значит на практике

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

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

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

Что делать, если у вас нет ни фаззера, ни ИИ-агента

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

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

Как проверить себя

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

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

Что делать прямо сейчас

  • Проверить, есть ли у вас отдельный процесс для поиска уязвимостей, а не только для обычных багов.
  • Отметить критичные модули, где нужен и динамический поиск, и анализ кода.
  • Настроить фильтр дублей и пустых репортов, чтобы не тратить время команды.
  • Сравнить, какие типы багов ловит ваш текущий инструмент, а какие он пропускает.
  • Добавить второй подход к проверке — не вместо первого, а вместе с ним.
  • Пересмотреть правила работы с публичными сетями для удалённой команды и командировок.
Поделиться: