Trail of Bits выпустила ИИ-плагины для автоматической разработки и проверки исправлений уязвимостей

Плагины patching-bugs и regression-hunt автоматизируют разработку исправлений

Trail of Bits выпустила два плагина: patching-bugs и regression-hunt. Они автоматизируют разработку исправлений для уязвимостей и проверку регрессий. Плагин patching-bugs воспроизводит ошибки, разрабатывает исправления и тестирует их. Плагин regression-hunt проверяет, не нарушают ли изменения ранее работавшее поведение. Инженеры могут управлять процессом и просматривать результаты. Мейнтейнеры могут задавать собственные предположения о безопасности и требования к исправлениям, чтобы агенты работали в рамках правил проекта. Разработка плагинов стала возможна благодаря инициативе Patch the Planet, совместному проекту Trail of Bits и OpenAI. В рамках этой инициативы были совместно подготовлены сотни исправлений безопасности для популярных проектов с открытым исходным кодом. Плагины основаны на анализе принятых исправлений и опыте инженеров, использовавших Codex. Плагины предоставляют мейнтейнерам структурированный рабочий процесс, доказательства, независимые проверки и лучшие практики для улучшения процесса исправления ошибок. Предварительные оценки показали, что regression-hunt выдает на 25% меньше ложноположительных срабатываний по сравнению с базовым агентом Codex, которому была поставлена задача «проверить PR на регрессии».

Стандартизация процесса исправления ошибок

В сентябре Trail of Bits сообщала о регрессиях, внесенных некоторыми исправлениями в рамках Patch the Planet. С тех пор компания пересмотрела каждое исправление, написанное инженерами Trail of Bits и принятое мейнтейнерами. Обзор подтвердил 21 регрессию из более чем 130 принятых запросов на слияние (pull requests). Из них 16 были функциональными, одна касалась производительности и четыре — сборки или тестирования. Ни одна из них не нарушила защиту безопасности. Регрессия определяется как новый дефект, вызванный изменением, которое нарушает ранее корректное и поддерживаемое поведение на пути, достижимом реальным пользователем или злоумышленником. Для каждого исправления агент искал потенциальные регрессии, подтверждал каждую с помощью запуска доказательства концепции (Proof of Concept, PoC) до и после изменения, а затем передавал результаты инженеру для проверки. Проверка была «шумной»: современные отчеты об уязвимостях поступают с беспрецедентной скоростью и в больших объемах. Для того чтобы исправления успевали за скоростью обнаружения уязвимостей, отрасли необходимо повысить соотношение сигнал/шум. 21 подтвержденная регрессия была выявлена среди 58 кандидатов за один запуск, что составляет примерно 36% точности. Однако, поскольку агенты используют разные подходы и получают разные результаты, каждый запуск генерирует больше кандидатов для ручной сортировки. Это привело к двум выводам: для внесения меньшего количества регрессий необходим стандартный способ написания исправлений с применением одних и тех же проверок каждый раз. Для отлова регрессий, которые все же вносятся, нужен стандартный способ их проверки с письменными правилами, определяющими, что считается регрессией. Стандартизация обоих этапов также делает каждый запуск повторяемым и сопоставимым. Никакой фиксированный контрольный список не сможет выявить все регрессии, поэтому собираются траектории агентов из сеансов исправления ошибок инженеров, а задачи, с которыми ранее не справилась версия, используются для тестирования следующей. Разработка плагинов основывалась на двух основных источниках: обзоре каждого принятого исправления и тысячах сеансов Codex, которые инженеры использовали для написания этих исправлений. Это привело к четырем принципам, которые легли в основу плагинов patching-bugs и regression-hunt: предоставление четких указаний минимальным количеством слов; модульные шаги, которые можно использовать по отдельности; строгие схемы ввода и вывода для уменьшения вариативности между запусками; и живое доказательство концепции для каждого утверждения.

Плагин regression-hunt снижает количество ложных срабатываний

Плагин regression-hunt перечисляет потенциальные регрессии, отслеживая измененный код через его вызывающие стороны до реальных интерфейсов. Он воспроизводит каждую потенциальную регрессию на работающем экземпляре системы. Затем он повторяет PoC на работающем экземпляре в среде с чистым контекстом. Плагин оценивает результаты всех предыдущих шагов, чтобы подтвердить, что доказательство соответствует требованиям регрессии. Помимо четырех основных принципов, критически важны два аспекта: определение регрессии и учет модели угроз. Плагин имеет четкие представления о том, что является регрессией, а что нет. Бремя доказательства возлагается на агента, чтобы доказать, что есть достаточные основания считать подозреваемую регрессию не ложным срабатыванием, не неполным исправлением, не скрытой ошибкой и т. д. Плагин сообщает о регрессии только в том случае, если все эти этапы пройдены. Если доступна модель угроз, оркестратор намеренно передает этот документ в качестве глобального контекста для каждого отдельного шага агента. Это попытка обязать каждый шаг/агента ссылаться на модель угроз перед тем, как прийти к заключению. Обзор принятых запросов на слияние выявил набор из 21 подтвержденной регрессии, которые использовались для оценки regression-hunt. Плагин показал на 25% меньше ложноположительных срабатываний по сравнению с базовым агентом, с 95% доверительным интервалом от 14% до 38%. Его строгие требования к доказательствам также привели к тому, что некоторые известные регрессии были классифицированы как пограничные: плагин выявил возможную регрессию, но не собрал достаточно доказательств для ее подтверждения. Меньшее количество ложных срабатываний пришло с компромиссом в виде меньшего количества уверенно сообщаемых известных регрессий. В дальнейшем планируется исследовать причины пограничных случаев и улучшить стратегии сбора доказательств плагином. Цель состоит в том, чтобы подтверждать больше реальных регрессий, предоставляя мейнтейнерам более четкую информацию, когда доказательства остаются неубедительными.

Плагин patching-bugs оптимизирует лучшие практики

Плагин patching-bugs является результатом анализа тысяч сеансов Codex, проведенных инженерами Trail of Bits. Помимо традиционных возможностей, таких как воспроизведение на работающих экземплярах и независимая проверка на наличие уязвимостей, плагин подчеркивает трехэтапное доказательство: оно запускает воспроизведение на трех спецификациях: исходный код должен не работать, исправленный код должен работать, а полное возвращение к предыдущей версии снова не должно работать. Возвращение ошибки путем удаления исправления предоставляет более веские доказательства того, что именно исправление, а не постороннее изменение среды или теста, фактически устранило ошибку. Ремонт, управляемый инвариантами: исправление пытается устранить нарушенный инвариант безопасности, а не конкретную ошибку. Это помогает обобщить исправление для возможных вариантов того же класса ошибок. Интеграция анализа регрессий: плагин требует запуска regression-hunt, чтобы гарантировать, что любое исправление проходит через тот же стандартный конвейер для проверки ошибок. Плагины будут развиваться: инженеры Trail of Bits уже используют их в своей работе по Patch the Planet. Собираются данные об использовании, эффективности и проблемах. Эти данные, наряду с лучшими оценками, определят возможности следующей версии. Планируется оценка patching-bugs для измерения того, исправляет ли плагин заявленную ошибку и ее варианты без внесения регрессий. Анализ трассировок агентов покажет, следует ли Codex правилам и определениям на каждом этапе, какие этапы он пропускает и где его доказательства наиболее слабы. Плагины станут более настраиваемыми: patching-bugs уже считывает собственные рекомендации проекта по исправлению ошибок. В дальнейшем мейнтейнеры смогут выбирать, минимизировать ли наборы исправлений или, когда более широкое покрытие оправдывает больше ложных срабатываний, ослабить правила regression-hunt для выявления большего числа кандидатов. Плагины кодируют лучшие практики, найденные для агента при правильном исправлении ошибки, и улучшаются, когда им сообщают о специфике проекта. Плагины лучше всего работают при вводе двух типов информации о проекте: THREAT_MODEL.md, который сообщает агентам, что считается уязвимостью или регрессией, и PATCHING_GUIDELINES.md (или AGENTS.md), который сообщает агентам и patching-bugs, как проект хочет, чтобы исправления были написаны. Чем более полными и конкретными будут эти файлы для вашего проекта, соглашений по кодированию и стиля работы, тем лучше будет результат. Индустрии необходимо сосредоточиться на исправлении ошибок: поскольку ИИ ускоряет обнаружение ошибок, необходимо так же быстро преобразовывать эти находки в надежные исправления. Решения должны сбалансировать скорость и качество: агент должен понимать отчет, решать, что нужно изменить, и проверять, что исправление устраняет проблему, не внося регрессий. Плагины patching-bugs и regression-hunt переносят полученный опыт в рабочий процесс, помогая мейнтейнерам перейти от отчета об ошибке к исправлению, которое они могут уверенно проверить и выпустить. Рекомендуется установить patching-bugs и regression-hunt, добавить THREAT_MODEL.md и PATCHING_GUIDELINES.md в репозиторий и использовать их для следующего отчета об ошибке. Предоставление инструментам контекста проекта позволит им помочь сосредоточиться на правильном исправлении и быстрее его проверить. Затем следует поделиться отзывами, включая комментарии о том, где стандартные настройки не соответствуют проекту. Эти реальные случаи помогут в создании следующей версии.