Загрузка 0
ПОДЕЛИТЬСЯ

Мой блог

Листай вниз

Анализ воронки уязвимостей Anthropic: отчёты ИИ и реальные исправления

Анализ воронки уязвимостей Anthropic: отчёты ИИ и реальные исправления

Анализ данных координированного раскрытия уязвимостей показывает, что из тысяч отчётов, переданных мейнтейнерам открытого ПО, исправлена лишь часть. Публикации в СМИ часто суммируют разные этапы процесса, из-за чего статистика находок и исправлений требует точного разделения по знаменателям.

Компания Anthropic подвела итоги полугодовой работы моделей по поиску ошибок в проектах с открытым исходным кодом. Полученные данные позволяют оценить эффективность автоматизированного аудита и реальную нагрузку на разработчиков.

Запуск OSS Scanner и особенности процесса

Восьмого октября был запущен OSS Scanner — добровольный сервис, сканирующий открытые проекты с помощью передовых моделей (в анонсе упоминается Claude Mythos) и отправляющий отчёты мейнтейнерам. Идея аналогична проекту OSS-Fuzz от Google, однако ключевое отличие заключается в том, что отчёты генерируются искусственным интеллектом полностью автономно, без предварительного ручного просмотра сотрудниками.

Реклама

Сервис предоставляется бесплатно, но доступен не для всех репозиториев. Заявка подается через pull request в официальный репозиторий проекта, а критерием отбора выступает критическое влияние на инфраструктуру и безопасность пользователей. Сканирование выполняется в изолированной виртуальной среде без выхода в сеть.

Причины запуска автоматизированного сканирования

Необходимость создания автоматического инструмента обусловлена нехваткой человеческих ресурсов. За шесть месяцев модели зафиксировали более 29 000 потенциальных уязвимостей, тогда как вручную специалисты смогли разобрать лишь около 6 000 случаев. Получая проверенные материалы, мейнтейнеры нередко запрашивали весь массив данных, включая необработанные результаты, что и привело к появлению нового быстрого канала связи.

Анализ воронки уязвимостей и статистика дашборда

На дашборде координированного раскрытия уязвимостей (CVD) представлена подробная воронка прежнего процесса. В первую очередь рассматривается этап первичного выявления и проверки независимыми фирмами, которых насчитывается шесть.

Из 29 439 кандидатов, найденных моделями, внешние организации проверили 6 123 случая (20,8%). Из них 5 674 подтвердились как реальные ошибки, что составляет 92,7% от проверенного объема. Оставшиеся 23 316 кандидатов (79,2%) на момент среза еще не проходили внешнюю верификацию.

Распределение переданных отчётов и результаты исправлений

Вторая часть воронки описывает передачу информации разработчикам ПО. Всего мейнтейнерам направили 6 157 отчётов. Около 21,6% из них (1 333 отчёта) прошли через триаж и проверку сторонними фирмами, а 78,4% (4 824 отчёта) были отправлены напрямую без аналогичной независимой экспертизы.

Направленные уведомления привели к тому, что разработчики ответили на 5 103 отчёта (82,9%). При этом исправления в апстриме были выпущены для 516 уязвимостей, что составляет 8,4% от общего числа переданных сообщений. Также было выдано 584 идентификатора, включающих 219 CVE и 365 GHSA.

Реклама

Особенности расчёта долей

Корректный расчет доли исправлений требует деления числа патчей (516) именно на количество переданных отчётов (6 157), что дает 8,4%. Использование общего числа кандидатов (29 439) в качестве знаменателя некорректно, так как оно включает непроверенные данные и смешивает разные этапы воронки.

Канал прямой отправки (78% отчётов) не проходил предварительную ручную оценку критичности или воспроизводимости, из-за чего компания предупреждает о вероятности ложных срабатываний в этой части потока.

Почему исправления отстают от находок

Расхождения между количеством выявленных ошибок и выпущенных патчей объясняются несколькими факторами. Прежде всего, исправления требуют времени: патч может готовиться месяцами, поэтому оперативный срез данных не отражает конечный результат работы разработчиков.

Кроме того, счетчик ответов мейнтейнеров и счетчик выпущенных исправлений работают независимо друг от друга. Подтвержденные находки могут относиться к категории «won’t fix», когда ошибка известна, но проект не планирует ее исправлять в силу особенностей модели угроз или недостижимости кода.

Обратная связь от мейнтейнеров

В официальном анонсе приведены мнения представителей нескольких крупных проектов. Так, разработчики PostgreSQL отмечают поступление отчётов с готовыми исправлениями, которые потребовали минимальных правок. В OpenSSL Corporation указывают на высокое качество сырого вывода моделей по сравнению с ранними генерациями полуторагодичной давности. Представители wolfSSL, HotCRP и curl также подтвердили обнаружение реальных проблем с помощью автоматизированных инструментов.

Тем не менее, часть проектов указывает на завышенную оценку критичности со стороны ИИ или непонимание специфической модели угроз конкретного ПО. Статистика дашборда показывает, что оценки Claude и внешних фирм совпадали точно в 83,0% случаев.

Рекомендации по проверке моделей отчётов

При получении сгенерированного ИИ отчёта разработчикам рекомендуется опираться на практический чек-лист:

  • Воспроизводимость: проверка кода на чистой сборке и актуальной версии проекта.
  • Достижимость: анализ того, может ли реальный пользовательский ввод дойти до уязвимого участка без нарушения контракта API.
  • Модель угроз: сопоставление векторов атаки с политикой безопасности репозитория.
  • Критичность: самостоятельный пересчет уровня опасности с учетом внутренней специфики ПО.
  • Дубликаты: сверка с трекером задач и прошлыми CVE.
  • Патч: оценка того, устраняет ли предложенный код причину проблемы или только симптом.

Использование таких инструментов в качестве вспомогательного средства позволяет ускорить обнаружение дефектов, однако окончательное решение о внедрении исправлений всегда остается за человеком.

01.