Подробный разбор · Около 7 мин чтения
Исследование Claude на 123 библиотеках уточняет границы программных гарантий, не делая их всеобщими
Anthropic и Theorem сообщают о доказательствах для 239 точек входа фаззинга в 123 библиотеках. Результаты зависят от явно заданных предположений о машине и имеют определённые границы.
- Опубликовано здесь
- Дата источника
- Источник проверен
В исследовательской статье от 22 октября Anthropic описывает совместную с Theorem работу, в которой Claude генерирует машинно проверяемые доказательства свойств программ. Полезный результат — гарантия для выбранных исполняемых программ в рамках определённой модели, а не сертификат безопасности всей библиотеки или любого её развёртывания.
Слушать новости
Прослушайте эту статью или включите новости подряд.
Подготовка чтения…
Голос устройства
Речь обрабатывает браузер или устройство. AISubHub не отправляет текст в аудио-API. Доступные голоса и работа при заблокированном экране зависят от устройства.
При продолжении короткая фраза может повториться.
Кратко
- Исследователи сообщают, что при необходимости исправили найденные ошибки и доказали отсутствие аварийного завершения для 239 точек входа в 123 библиотеках OSS-Fuzz при входных данных меньше 64 МБ и заявленных предположениях.
- Основной эксперимент касается однопоточных программ RISC-V со статической компоновкой с musl и смоделированного поведения Linux. Он автоматически не распространяется на обычные развёртывания на x86 или ARM.
- В отдельных экспериментах на небольших задачах сравниваются затраты токенов у моделей и совместное использование доказательств. Заявленная экономия относится к этим экспериментам и не гарантирует универсальную цену или производительность.
Одно доказательство охватывает точку входа в заданной машине
Важно, что именно считается единицей покрытия. Точка входа OSS-Fuzz — предоставленный разработчиком тестовый путь, позволяющий подавать данные в программу и выявлять сбои. Anthropic сообщает, что за несколько недель были завершены доказательства для 239 таких точек входа в 123 библиотеках. Это не означает ни полной верификации 239 библиотек, ни охвата всех возможных путей в каждой из 123 библиотек. Проект создал около 180 000 000 строк доказательств на Rocq; типичное доказательство занимало около 600 000 строк, а медианное число инструкций RISC-V в бинарных файлах составляло 18 000.
Утверждение ограничено смоделированным выполнением: входные данные меньше 64 МБ, фиксированный бюджет памяти, один поток, статически скомпонованный с musl исполняемый файл RISC-V, заданные ответы Linux и размещение памяти. Эти условия определяют математическое утверждение. По оценке AISubHub, для понимания результата полезнее знать, относительно какого полного объёма оценивается покрытие и как настроена сборка, чем опираться лишь на впечатляющее суммарное число строк доказательств.
Фаззинг превращается в утверждение, проверяемое небольшим ядром
Фаззинг пробует множество сгенерированных входных данных и может найти контрпример, но успешное прохождение таких испытаний не исчерпывает пространство входов. Здесь исследователи преобразуют существующий фаззинг-тест и его скомпилированный исполняемый файл в формальную спецификацию. Claude строит доказательство того, что выбранный тест не завершится аварийно ни на одном допустимом входе. Уже имеющиеся в тесте проверки также могут выражать содержательные свойства: например, восстановление исходных данных после сжатия и последующей распаковки.
Модель не может сама объявить своё доказательство правильным. Rocq проверяет его относительно сформулированного утверждения. Поэтому доверие переносится на точное утверждение, семантику RISC-V и Linux и проверяющий инструмент, включая лежащие в его основе аппаратное и программное обеспечение. Это более компактный предмет проверки, чем миллионы сгенерированных строк, но зависимость остаётся существенной. Корректное доказательство не может установить, что неточная модель машины достоверно описывает систему в эксплуатации.
Почему неудачная попытка доказательства может дать полезное исправление
По словам исследователей, попытки доказательства выявили ошибки. Среди примеров — проблема распаковщика, требующая необычно организованного входа размером около 20 МБ, и сбой декодера изображений, для которого нужны вход размером 64 МБ и более 2 ГБ памяти. Эти примеры объясняют, почему поиск с преобладанием небольших входов может пропустить важное поведение. Это находки, о которых сообщает источник, а не уязвимости, независимо воспроизведённые AISubHub.
Конвейер мог исправить программу, заново сгенерировать её спецификацию и затем доказать свойства исправленного артефакта. Доказательство нового артефакта нельзя представлять как доказательство исходной, неизменённой версии. Есть и риск обходного пути: агент может удалить полезное поведение, чтобы утверждение об отсутствии аварийного завершения стало легко доказать. Авторы описывают штрафы за исправления, стимулы характеризовать входы с изменившимся поведением и аудит патчей. Эти меры направлены на определённый механизм сбоя, но не отменяют проверки того, сохраняет ли исправление ожидаемое поведение.
Экономия токенов получена в двух разных экспериментах
Для отдельного набора из 36 небольших задач верификации статья сообщает, что Opus 5.5 доказывает половину задач, используя примерно на 40% меньше токенов, чем Opus 5. Для каждой задачи выполнялись три независимые попытки одного агента с бюджетом 5 000 000 токенов на попытку; график засчитывал задачу при завершении первой успешной попытки. Это сравнение на определённом наборе задач и при определённом бюджете. В статье не перечислены все модели, использовавшиеся в более крупной работе со 123 библиотеками, поэтому всю эту работу нельзя переименовывать в результат Opus 5.5.
В эксперименте с общим рабочим пространством агенты могли повторно использовать доказательства друг друга; заявлено на 17% меньше токенов, чем при изолированной работе. На графике для 36 доказательств расход токенов ниже в 30 из 34 сравнений, где одиночная работа была завершена; ещё две задачи изолированные агенты не закончили. Повторное использование доказательств инициализации среды выполнения и санитайзеров даёт конкретный механизм экономии. Ни один из процентов не задаёт универсальную стоимость в долларах, сокращение прошедшего времени или независимо измеренную пользу при развёртывании.
Другие примеры измеряют разные виды корректности
Статья также описывает эксперимент с zlib относительно спецификации, выведенной из RFC, с использованием семантики x86. Это отдельный пример, а не свидетельство того, что массовые результаты для RISC-V уже применимы ко всему программному обеспечению x86. Интерпретатор большого подмножества Python, написанный на Rust, проверили с помощью Verus относительно смоделированной семантики CPython, а затем эмпирически сравнили с CPython на более чем 1,7 миллиона случайно сгенерированных программ.
Заявленные 99,95% совпадений поведения относятся именно к этому эмпирическому сравнению. Это не доказательство совместимости со всеми программами Python. Различие важно: доказательство устанавливает конкретное формальное утверждение, а процент в тесте описывает эксперимент на выборке. Объединение этих результатов в один общий показатель точности модели стёрло бы различия между спецификациями, инструментами и оставшимися пограничными случаями.
Инженерный выигрыш — более чёткая граница гарантий
Авторы прямо указывают на пробелы. AddressSanitizer пропускает некоторые ошибки памяти; проект охватил не каждую точку входа; даже охват всех входов фаззинга не означал бы охвата всего поведения библиотеки или недостижимого кода. Вызывающая программа также может неверно использовать библиотеку за пределами проверенных предположений. В распространённых развёртываниях применяются динамическая компоновка, glibc, x86 или ARM, отличающиеся от основного эксперимента. Некоторые доказательства не опубликованы, чтобы не раскрывать ещё не исправленные ошибки, а более широкая дорожная карта для экосистемы в статье остаётся предложением.
Анализ AISubHub: практический следующий шаг — связывать каждую заявленную гарантию с точной сборкой, тестовой точкой входа, пределом размера входных данных и доверенной моделью машины, а затем пересматривать её при изменении этих условий. Это может дополнять тестирование и проверку, но не оправдывает их отмену во всём проекте. Мы прочитали статью и необходимые иллюстрации, однако не запускали доказательства повторно, не проводили аудит внешнего приложения или опубликованных репозиториев, не проверяли безопасность патчей и не воспроизводили экономию токенов. Результаты и ожидания на будущее по-прежнему приписываются исследователям.
Почему это важно
Анализ AISubHub: генерируемые доказательства могут удешевить установление и повторное использование узкого, поддающегося проверке свойства программы. Практический результат — точно определённые проверенный артефакт и утверждение вместе с их предположениями, а не общий тезис о том, что ИИ избавил программное обеспечение от ошибок.
Ограничения и доступность
Это анализ опубликованного исследователями описания, а не независимый аудит безопасности или воспроизведение эксперимента. Ограничения основного эксперимента по входным данным, архитектуре, компоновке, памяти и точкам входа остаются существенными; содержимое внешнего приложения и репозиториев не проходило аудит.
Источники и подтверждения
Дата источника: · Источник проверен:
Материалы подготовлены с помощью ИИ и сверены с указанными первоисточниками. Заявления поставщиков атрибутированы; публикация не означает рекомендацию.