BigSleep на LLM нашёл в V8 45 уязвимостей, Fuzzilli — 37, пересечение 25%

За шесть месяцев, с апреля по сентябрь 2026 года, LLM-агент BigSleep нашёл в V8 45 рабочих уязвимостей, а генеративный фаззер Fuzzilli — 37. Оба инструмента Google использует в продакшене для проверки свежего кода JavaScript-движка Chrome. Команда Project Zero сравнила их результаты и получила два вывода. Пересечение найденного небольшое: по баг-трекеру около 25% (20 из 81 рабочего репорта). В реконструированном эксперименте на исторических багах оно доходило примерно до 60%. Значительная часть уязвимостей при этом находится только одним из подходов.

Как из 441 репорта получилось 45 уязвимостей

Сырой подсчёт по хотлистам баг-трекера Chromium даёт BigSleep небольшой перевес: 441 репорт против 316 у Fuzzilli. Но BigSleep на старте находил много проблем конфигурации и интеграции, например не работавшую блокировку небезопасных флагов (crbug.com/503869331). Реального влияния на безопасность у таких багов почти нет.

Если оставить только type:vulnerability, картина переворачивается: 178 у Fuzzilli и 95 у BigSleep. Но и это число завышено. Часть репортов — дубликаты или закрыты как WAI («работает как задумано»). Простой фильтр по статусу fixed тоже не спасает. Например, баг Fuzzilli crbug.com/511935486 Clusterfuzz завёл и закрыл в один день, потому что тесткейс перестал воспроизводиться. Это почти наверняка дубликат crbug.com/511210507, но сигнатура падения по стектрейсу немного отличалась, и система их не склеила. Ни один инженер к такому багу не прикасался.

Поэтому считали только «рабочие» репорты: не дубликаты, не WAI и хотя бы с одним коммитом-исправлением. Для типа Type-Vuln получилось 45 против 37 в пользу BigSleep.

Пересечение: четверть в трекере, около 60% в эксперименте

Для подсчёта общих находок дедуплицировали баги в четыре шага:

• явные дубликаты, когда репорт одной системы помечен дубликатом репорта другой, как crbug.com/522410841 и crbug.com/522860268; • неявные дубликаты, когда у «нерабочих» репортов ищут исправляющий коммит и склеивают баги, привязанные к нему. Связь может быть многосторонней: баг BigSleep и баг Fuzzilli оба дублируют третий; • дубликаты из базы Clusterfuzz, которые не дошли до трекера; • разные баги, закрытые одним CL (например, четыре бага в crrev.com/c/7965120), тоже считаются дубликатами.

Итог: 20 общих багов из 81, причём чуть больше половины сначала нашёл Fuzzilli.

Такой подсчёт занижает пересечение, поэтому поставили эксперимент. Взяли около 1150 исторических багов Fuzzilli с 2023 года по середину 2026-го. Оставили около 600 уязвимостей, затем 132 бага, воспроизводимых в публичной debug+asan-сборке d8 на x64 без специальных флагов. После дедупликации осталось 112. Для каждого нашли вероятный вносящий коммит, в основном бисекцией, и 25 раз запустили агента с задачей найти баги по этому коммиту и подтвердить тесткейсом, который роняет сборку. Всего выходит 2800 запусков на конфигурации продакшен-BigSleep того времени с моделью Gemini 3.6 flash.

Результат: около 62% исходных багов найдены заново, ещё около 12% коммитов дали другой, уже исправленный баг, на 26% не нашлось ничего. Постановка заведомо невыгодна агенту: коммит мог определиться неверно, а в реальности баг можно поймать и по более позднему коммиту в том же коде.

Запоминание, сложность и что остаётся за фаззером

Отдельно проверили, не вспоминает ли модель баги из обучающих данных. Срез знаний Gemini 3.6 flash — март 2026 года. Баги Chrome тогда открывались примерно через три месяца, так что эффективный срез по багам Fuzzilli приходится на январь 2026-го. Статистически значимого запоминания на багах до 2026 года не нашли. Для других моделей проверку стоит повторять.

По «сложности» бага, то есть времени, за которое его нашёл Fuzzilli, зависимость статистически значима, хотя по величине невелика. Направление при этом обратное идеальному сценарию, где LLM легко берёт то, что даётся фаззеру с трудом, и бюджет фаззинга можно перераспределять.

Обратный эксперимент (искать фаззером прошлые баги BigSleep) не ставили. Фаззер нельзя так же просто направить на конкретный коммит. К тому же большинство старых багов BigSleep нашлись после месяцев или лет фаззинга уязвимых сборок. В продакшене у фаззера и так есть фора: BigSleep запускается раз в сутки и сообщает о падениях с задержкой в 1–2 дня.

Практика для команд безопасности

Сравнить стоимость находки пока нельзя. Clusterfuzz оптимизировали годами, а над BigSleep сопоставимой работы не было, и цена за баг ни у одной системы не настраивалась.

Выводы из методики:

• запускайте и фаззинг, и агентный анализ: у них заметно разные «слепые зоны»; • давайте агенту диф конкретного коммита и требуйте PoC. Остановка на первом падении ограничивает расход токенов; • проверяйте PoC на сборках до и после исправления, чтобы отличить искомый баг от другого; • ставьте sanitizer-сборки и режим «только безопасные флаги»; • считайте метрики только по рабочим репортам с исправляющими коммитами и дедуплицируйте их вместе с Clusterfuzz; • при оценке на исторических багах сравнивайте долю успехов до и после даты среза модели, чтобы отсечь запоминание.