Что случилось
Исследователи представили FuzzingBrain-Bench V1, тест, предназначенный для измерения открытого обнаружения ошибок с помощью больших языковых моделей. Вместо того, чтобы просить модель воспроизвести известную уязвимость, тест предоставляет ей проект с открытым исходным кодом и инструментарий для тестирования с дезинфицирующим средством внутри автономного образа Docker. Модель должна генерировать входные данные, которые вызывают как можно больше различных сигнатур сбоев.
Авторы описывают FuzzingBrain-Bench V1 как оценку способности моделей ИИ обнаруживать ошибки в программном обеспечении с открытым исходным кодом без заранее определенной цели. Каждая задача предоставляет проект и средства дезинфекции в автономном образе Docker. Задача модели — создать входные данные, вызывающие сбои в работе этой системы. Это меняет вопрос оценки с «Может ли модель воспроизвести известную ошибку?» на «Сколько различных ошибок модель может обнаружить в незнакомой среде тестирования?»
Тест оценивает каждую проблему в соответствии с количеством отдельных сигнатур сбоев. Оценка ограничена заранее определенным максимумом и взвешивается по коэффициенту сложности. Первая версия содержит 77 задач, взятых из 43 проектов с открытым исходным кодом: 36 задач C, 32 задачи C++ и девять задач Java/JVM. Статья представляет собой 21-страничный препринт arXiv, представленный 25 августа 2026 года, и авторы утверждают, что корпус тестов и программные средства общедоступны.
Исследователи оценили Claude Haiku 4.5, Claude Sonnet 4.6 и Claude Opus 4.8 в полном тесте. По данным источника, Opus 4.8 показал себя лучше всего, вызвав сбои в 60 из 77 испытаний и получив оценку 196 из 579. Ни одна из трех моделей не вызвала сбой в 13 испытаниях. Источник не предоставляет полные оценки двух других моделей и не объясняет, какие отдельные проекты обеспечили такие результаты.
Подробности об источнике: arxiv.org ↗
Почему это важно
Этот тест устраняет ограничение во многих существующих оценках: модель может обнаружить действительный сбой, который не соответствует уязвимости, выбранной разработчиком теста, но не получить при этом оценки. Более открытый тест мог бы дать полезную оценку того, как системы ИИ работают во время обнаружения уязвимостей и тестирования программного обеспечения, а также показать, где их очевидные возможности остаются неполными.
Открытая оценка имеет значение, поскольку заранее определенные цели могут ограничить то, что считается успехом. Если модель генерирует действительный сбой, который отличается от целевого сбоя, целевой тест может рассматривать результат как неправильный или нерелевантный. FuzzingBrain-Bench пытается реализовать более широкие возможности обнаружения, подсчитывая отдельные сигнатуры сбоев, а не требуя одного конкретного ввода для проверки концепции. Такой дизайн может сделать сравнения более информативными для разработчиков, оценивающих инструменты тестирования с помощью ИИ.
Результаты также накладывают ограничения на заявления о текущих возможностях ИИ-кодирования и безопасности. Opus 4.8 вызвал как минимум один сбой в большинстве испытаний, но его общий балл составил 196 из 579, и все три протестированные модели не смогли вызвать сбой в 13 испытаниях. Сбой является свидетельством того, что ввод привел к сбою инструментированной программы; само по себе это не является доказательством удаленной уязвимости безопасности, серьезного дефекта или полезного исправления. Таким образом, эталонный тест измеряет один важный этап обнаружения, а не полное исследование уязвимостей.
Публичный корпус и набор инструментов могут дать исследователям безопасности программного обеспечения общий испытательный стенд для изучения поведения моделей. Это может помочь выяснить, обнаруживают ли системы только очевидные сбои, могут ли они исследовать незнакомые пути кода и как их производительность меняется в зависимости от возможностей модели или конструкции задачи. Но источник представляет собой единый эталонный отчет и не устанавливает, будут ли его рейтинги сохраняться в других репозиториях, языках, программах, версиях моделей или операционных средах.
Интерактивный механизм: как он на самом деле работает
Изучите технологию, лежащую в основе этой разработки, в интерактивном режиме.
Which component of an AI application is the machine-learning model itself?
Что посмотреть дальше
Основные вопросы заключаются в том, дает ли тест повторяемые результаты в разных моделях и исследовательских группах, насколько хорошо сигнатуры сбоев соответствуют подлинным ошибкам программного обеспечения или уязвимостям безопасности, а также распространяется ли производительность за пределы выбранных проектов с открытым исходным кодом. Источник сообщает о результатах тестов, но не указывает возможности использования, серьезность, исправления, реальные инциденты или независимую проверку.
Ключевым продолжением является независимая репликация. Источник сообщает, что корпус и комплектация общедоступны, но не сообщает о результатах сторонних команд. Повторное выполнение задач с фиксированными версиями модели, бюджетами и разрешениями на инструменты поможет определить, является ли сообщаемый рейтинг надежным или чувствительным к подсказкам, времени поиска, инфраструктуре и другим вариантам реализации.
Исследователям и практикам необходимо будет изучить, как сбои в тестах превращаются в выводы, имеющие отношение к безопасности. Источник не сообщает, были ли сбои отсортированы людьми, сопоставлены с известными проблемами, присвоены уровни серьезности или преобразованы в исправления. В нем также не указано, как обрабатывается дублированное поведение, помимо использования в тесте отдельных сигнатур сбоев. Эти детали будут определять, насколько точно оценка соответствует практической ценности поиска ошибок.
Охват эталонного теста является еще одним ограничением для мониторинга. Его 77 задач основаны на 43 проектах с открытым исходным кодом и сосредоточены на программном обеспечении C, C++ и Java/JVM. Источник не устанавливает производительность на других языках, проприетарных системах, более крупных базах кода, безопасном для памяти программном обеспечении или производственных сервисах. Он также не сообщает о стоимости, времени, доступе к инструментам, частоте ложноположительных результатов или о том, могут ли сгенерированные входные данные повредить системы за пределами изолированной среды Docker.
Поэтому результат авторов следует рассматривать как раннее измерение, а не как доказательство того, что ИИ может независимо защищать программное обеспечение. Наиболее полезные следующие шаги будут включать более широкий набор задач, прозрачные результаты для каждой модели, проверку обнаруженных дефектов людьми, сравнения с признанными инструментами фаззинга и людьми-исследователями, а также тестирование того, могут ли модели объяснить, воспроизвести и помочь исправить обнаруженные ими ошибки. Пока эти результаты не будут доступны, практическая ценность теста будет наиболее очевидна как способ сделать требования к тестированию безопасности ИИ более требовательными и сопоставимыми.