Заметки команды безопасности протокола Фонда Ethereum о запуске скоординированных ИИ-агентов для проверки реального кода протокола, включая то, как мы организуем работу, что выдерживает тщательную проверку, и что команды разработчиков клиентов и исследователи безопасности могут из этого извлечь. Эта статья является самостоятельной; в последующих публикациях мы более подробно рассмотрим отдельные клиенты.
Что мы запускали и что нас удивило
В команде безопасности протокола Фонда Ethereum мы запускали скоординированных ИИ-агентов для проверки систем, от которых зависит сеть, таких как системное программное обеспечение, криптографический код и смарт-контракты, которые должны работать безошибочно. Агенты нашли реальные ошибки. Одна из них теперь публична: удаленно вызываемая паника в gossipsub библиотеки libp2p, ключевой части однорангового уровня, на котором работают клиенты консенсуса Эфириума. Она была исправлена и раскрыта как CVE-2026-34219 с упоминанием заслуг команды.
То, что агенты находят ошибки, не стало сюрпризом. Сюрпризом стало то, как мало усилий ушло на их поиск, и как много — на то, чтобы отличить реальные ошибки от тех, которые лишь казались таковыми.
Эта статья предназначена для команд разработчиков клиентов и исследователей безопасности, которые хотят сделать то же самое. В ней рассказывается о том, как мы организуем работу агентов, какой порог должен преодолеть кандидат, прежде чем он будет считаться уязвимостью, и о привычках, которые помогают сохранять доверие к результатам.
Другие команды приходят к тому же рецепту. Команда Frontier Red Team от Anthropic создала агента, который пишет тесты на основе свойств и нашел реальные ошибки во всей экосистеме Python. Cloudflare прогнала передовую модель через среду для исследований безопасности для проверки собственных систем. Все приходят к одному и тому же циклу: направить мощную модель на кодовую базу, позволить ей искать и проводить триаж (сортировку) того, что она возвращает. Поэтому главный вопрос заключается в том, как делать это, не утонув в уверенно звучащем шуме.
Одно предупреждение сразу: инструментарий для аудитов с помощью агентов развивается быстро, и любая конкретная конфигурация устаревает за несколько недель. Поэтому эта статья намеренно посвящена методам, которые остаются неизменными, а не инструментам. Раскрытие информации — это отдельная тема, и, вероятно, ей будет посвящена отдельная публикация.
Агент — это инструмент поиска, а не оракул
Агент, направленный на кодовую базу, — это инструмент поиска, во многом похожий на фаззер. Разница заключается в том, что вы получаете в ответ. Фаззер выдает вам сбой и трассировку стека. Агент предоставляет гораздо больше, включая отчет (цепочку вызовов, заявление о последствиях, предполагаемую серьезность) и артефакты для его подтверждения, такие как proof-of-concept (доказательство концепции), которое можно запустить на реальном коде.
Все это делает результат легко читаемым и вызывающим доверие, особенно работающее доказательство концепции. Поэтому не считайте, сколько кандидатов выдает агент. Считайте, сколько из них оказываются реальными.
Как организована работа
Мы запускаем множество агентов параллельно против одной цели. Они координируются через сам репозиторий, с общим состоянием в системе контроля версий и без центрального процесса, распределяющего работу. Агент записывает свое утверждение там, где его могут видеть другие, выполняет работу и делает коммит.
Мы позаимствовали этот подход из статьи Anthropic о создании компилятора C с помощью парка агентов, которые координируются таким же образом. Нет центрального координатора, который нужно создавать или поддерживать, и меньше шансов, что что-то пойдет не так.
Роли формируются исходя из обнаруженной работы:
- Разведка (Recon) превращает поверхность атаки в конкретные, проверяемые гипотезы. Не «провести аудит декодера», а «этому полю доверяют после этой точки; вот свойство, которое оно должно сохранять, способ, которым оно может быть нарушено, и доказательство, которое это подтвердит».
- Охота (Hunting) берет одну гипотезу, отслеживает путь выполнения кода и пытается создать воспроизводящий сценарий (репродьюсер).
- Заполнение пробелов (Gap-filling) анализирует, что было принято, а что отклонено, пишет следующую партию гипотез и отслеживает покрытие, чтобы агенты не топтались на одном месте.
- Валидация (Validation) независимо перепроверяет каждого кандидата, удаляет дубликаты и принимает решение.
Мы не изобрели этот конвейер. Cloudflare описывает те же этапы: разведка, параллельная охота, независимая валидация, дедупликация, отчетность, и их статья помогла сформировать наш подход.
Вот как выглядит кандидат до того, как он будет признан уязвимостью:
цель: компонент и точка входа, до которых злоумышленник действительно может добраться инвариант: свойство, которое должно сохраняться механизм: конкретный способ, которым можно вызвать сбой успех: наблюдаемое доказательство: паника, зависание, принятый недействительный ввод репродьюсер: самодостаточный артефакт, который запускается на реальном коде дедупликация: ключ, чтобы два агента не гонялись за одним и тем же
Эта схема существует не просто так. Она требует конкретного, проверяемого утверждения и четкого определения готовности. Агент, который должен записать наблюдаемое доказательство, не может отделаться фразой «это выглядит рискованно».
Воспроизводимо, или этого не было
Одно правило важнее любого другого. Кандидат не является уязвимостью до тех пор, пока не появится самодостаточный артефакт, который воспроизводит сбой на реальном коде и который может запустить тот, кто его не писал.
Репродьюсер не читает отчет, и ему все равно, насколько уверенно звучала модель. Он либо работает, либо нет.
Большая часть его ценности заключается в ложных срабатываниях, которые он отлавливает. Три из них возникают снова и снова, и в каждом случае агент получает одобрение по неверной причине:
- Паника, которая происходит только в отладочной сборке. Скомпилируйте и запустите код так, как программное обеспечение поставляется на самом деле, и значение просто переполняется по кругу. Ничего не падает. Это выглядит как сбой, но таковым не является.
- Репродьюсер, который вручную создает некое внутреннее значение, которое никогда не могло бы возникнуть при реальном вводе, потому что любой путь, контролируемый злоумышленником, отклоняет его раньше. Ошибка «воспроизводится» только в функции, которую ничто из доступного извне не вызывает таким образом.
- В работе по формальной верификации — доказательство, которое проходит, но означает не то, что вы хотели. Утверждение тривиально истинно независимо от того, что делает код, или оно слабее свойства, которое вы хотели зафиксировать. Верификатор удовлетворен, но теорема не ограничивает поведение, которое вас на самом деле интересовало.
В этом нет ничего нового. Это то же самое, что и тест, который проходит, потому что на самом деле ничего не проверяет. Что ново, так это объем. Агент пишет бесполезную версию так же быстро, как и реальную, и с такой же уверенностью. Поэтому проверка должна быть автоматической. Нельзя рассчитывать на то, что агент сам себя поймает.
Соотношение сигнал/шум — это большая часть работы
Большинство кандидатов ошибочны, являются дубликатами или выходят за рамки области видимости. Это не проблема метода; так он работает. Цель состоит в том, чтобы быстро отклонять неверные варианты и подкреплять реальные доказательствами, с которыми трудно спорить.
Каждый выживший кандидат проходит две независимые проверки. Может ли реальный злоумышленник действительно добраться до него в обычной конфигурации? И во сколько обойдется злоумышленнику реализация атаки по сравнению с тем, во сколько она обойдется сети в случае успеха? Ошибка, которую может вызвать любой одиночный пир, сильно отличается от той, которая требует специального доступа или огромного количества ресурсов.
Все проверяется по текущему списку того, что уже известно, исправлено или отклонено. Без этого агенты будут продолжать заново обнаруживать одну и ту же закрытую проблему и сообщать о ней снова и снова.
Процент принятия сильно варьируется от цели к цели, и эта вариативность полезна сама по себе. Запустите это на зрелом, тщательно проверенном коде, и почти ничего не выживет, что тоже стоит знать. «Мы усердно искали и ничего не нашли» — это реальный результат. Запустите это на менее изученном коде или на формально верифицированном коде, где проверенное машиной доказательство покрывает модель, а развернутый байт-код лишь предположительно ей соответствует, и пройдет больше кандидатов.
Мы не единственные, кто обнаружил, что триаж — это самая сложная часть. Главный вывод Cloudflare заключался в том, что узкая область видимости лучше широкого сканирования. Агент для тестирования на основе свойств от Anthropic сгенерировал около тысячи отчетов-кандидатов, а затем использовал ранжирование и экспертную оценку, чтобы выделить высший уровень, который подтверждался примерно в 86 процентах случаев. Генерация была легкой частью. Я не собираюсь публиковать здесь наши собственные цифры; привязанные к конкретной цели, они сказали бы больше о цели, чем о методе.
В чем агенты хороши, а где они вводят в заблуждение
Вокруг этой темы много шумихи в обоих направлениях, поэтому вот простой список того, что агенты делают хорошо, а где они вводят в заблуждение.
| В чем хороши | В чем вводят в заблуждение |
|---|---|
| Совместное чтение спецификации и кода | Цепочки вызовов, которые кажутся достижимыми, но таковыми не являются |
| Формулирование и проверка реального инварианта | Обход проверки успешности (прохождение по неверной причине) |
| Создание черновика репродьюсера из идеи в одну строку | Завышение серьезности в соответствии с тем, насколько драматично звучит отчет |
| Предложение первопричины до того, как вы сами посмотрели | Ошибки, охватывающие последовательность допустимых шагов |
Это разделение даже не является стабильным от одной задачи к другой. Станислав Форт, тестируя ряд моделей на реальных уязвимостях, называет это зубчатым фронтиром (jagged frontier): модель, которая восстанавливает полную цепочку эксплойтов на одной кодовой базе, может не справиться с базовой трассировкой потока данных на другой. Нельзя предполагать, что один хороший результат означает, что следующий будет таким же, и это еще одна причина, по которой каждый кандидат проверяется отдельно.
Последняя строка — самая важная. Одиночная сессия агента хороша для одномоментных рассуждений и плоха для ошибок, охватывающих последовательность шагов, где каждый шаг допустим, и только порядок неверен. Для таких случаев агент не является инструментом поиска. Его задача — предложить, какие последовательности стоит прогнать через среду тестирования с сохранением состояния. При таком использовании он работает хорошо. Если же использовать его как замену среде тестирования, он упускает самые дорогостоящие ошибки — те, которые проявляются только в последовательности действий.
Поддержание достоверности
Несколько привычек делают большую часть работы по обеспечению достоверности находок агентов, и ни одна из них не является сложной.
- Происхождение каждого артефакта: что его создало, в каком контексте, для какой ревизии. Находка должна быть такой, чтобы ее можно было запустить повторно спустя месяцы.
- Детерминизм там, где это важно: одна среда, один способ сборки и запуска, чтобы слово «воспроизводится» означало одно и то же на каждой машине, а не только на той, где была найдена ошибка.
- Нормы, а не скрипты: говорите агентам, что действительно важно — инварианты и планку для реальной находки, вместо пронумерованной процедуры. Чрезмерно заскриптованные агенты ломаются так же, как и чрезмерно специфицированные тесты: они продолжают следовать шагам даже после того, как эти шаги перестают иметь смысл. Исследование файлов контекста репозитория показало то же самое: дополнительные требования снижали успешность выполнения задач и повышали затраты более чем на 20%, поэтому авторы рекомендуют сводить контекст к минимальным требованиям.
- Окончательное решение принимает человек: агенты лишь предлагают. Они не решают, что реально, что является дубликатом известной проблемы, или что и когда подлежит раскрытию.
Узкое место сместилось
ИИ не заменил исследователя безопасности. Он сместил фокус работы. Время, которое раньше уходило на придумывание и проверку гипотез, теперь тратится на их масштабную оценку, включая создание оракула, проведение триажа, ведение списка известных проблем и управление раскрытием информации.
Узкое место никуда не делось. Оно сместилось от поиска ошибок к доверию результатам, что является лучшим местом для него, потому что именно здесь человеческое суждение действительно имеет значение. Но это все еще узкое место, и если его игнорировать, вы в конечном итоге выпустите ошибочное «все в порядке».
Практики, которые заставляют это работать, не новы. Воспроизводимые сбои, реальные оракулы и тщательный триаж — это те же самые практики, которые за последние пятнадцать лет превратили фаззинг из темы для исследований в стандартную практику. Инструменты новые. Практики — нет.
Насколько быстро будут меняться инструменты — вопрос открытый. Николас Карлини, осторожный человек и в прошлом скептик, утверждает, что к экспоненциальному сценарию стоит относиться серьезно, даже несмотря на то, что он оставляет широкие пределы погрешности. Если сторона генерации будет расти так быстро, сторона оценки должна расти вместе с ней, иначе разрыв между тем, что производится, и тем, что фактически проверяется, будет только увеличиваться.
Для систем, от которых зависит Эфириум, это именно та часть, которая имеет значение. Агенты позволяют нам охватить гораздо больше материала, чем мы могли бы сделать вручную. Взамен они требуют более тщательной оценки гораздо большей кучи уверенно звучащих утверждений. Это обмен, на который стоит пойти, если вы помните, что реальным продуктом является именно оценка.