← Все статьи

Михаил Поляков

Anthropic бесплатно сканирует открытый код на уязвимости: что объявлено и что из этого следует для вашей компании

Уровень: ПростойВремя чтения: 11 мин

Темы: ИИ, Безопасность, Малый бизнес

Полупрозрачный щит из светящихся линий и узлов, сквозь него идёт луч сканирования, несколько узлов подсвечены оранжевым, позади размытые серверные стойки

Короткий ответ: 8 октября 2026 года Anthropic объявила сервис OSS Scanner. Проект с открытым исходным кодом может подать заявку, и если его примут в программу, его код начнут периодически проверять сильнейшие модели компании, а отчёты об уязвимостях будут приходить бесплатно тем, кто этот проект ведёт (их называют мейнтейнерами). Решение о приёме, как пишет Anthropic, принимается по каждому проекту отдельно. Главная оговорка в самом объявлении: отчёты полностью машинные, без проверки и разбора человеком, поэтому часть из них может оказаться неверной. Для компании, которая открытые библиотеки не ведёт, а просто использует, важна одна фраза из объявления: по словам Anthropic, эксплойты теперь могут разрабатываться за минуты. Эксплойт это готовый способ воспользоваться уязвимостью, то есть не описание дырки, а работающая отмычка. Значит, цену имеет скорость: сколько проходит времени от выхода исправления до его установки у вас. Ниже что именно объявлено, какие цифры привела компания и с какими оговорками, что сказали мейнтейнеры и что из этого делать.

Что объявлено

Anthropic запустила OSS Scanner, добровольный сканер уязвимостей для мира открытого кода. В посте сказано так: проекты, которые присоединятся, будут получать подробные периодические проверки безопасности сильнейшими моделями компании без оплаты. Опыт, по словам компании, взят из её работы под названием Project Glasswing, подробности которой в посте не раскрываются.

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

Уязвимость это ошибка, которой может воспользоваться нападающий: например, подсунуть данные, после которых программа выполнит чужую команду. Отчёт сканера, по описанию Anthropic, содержит самодостаточный воспроизводящий пример (то есть готовый способ повторить сбой), объяснение уязвимости и, где это возможно, определение момента, когда ошибка попала в код, а также заготовку исправления, когда она есть.

Цифры из первоисточника

Все числа ниже привела сама Anthropic в своём посте от 8 октября 2026 года.

Что Сколько
Предполагаемые уязвимости, найденные моделями компании за последние шесть месяцев более 29 000
Из них разобрано вручную примерно 6 000
Отчёты, отправленные мейнтейнерам напрямую по их просьбе, включая непроверенные почти 5 000
Находки критичной и высокой важности, отданные экспертам на выборочную проверку 97 по 48 проектам
Из них прошли планку порядка согласованного раскрытия 85, то есть 88%

Про остальные 12 находок в посте сказано отдельно: 11 были настоящими, но повторяли уже известные проблемы или другие находки той же проверки, и только одна оказалась ложным срабатыванием. Проверяли эксперты, которые и так разбирают находки компании, а в выборку попали только находки критичной и высокой важности, так что эти 88% описывают именно такую выборку, а не все отчёты сканера.

Отдельно Anthropic ссылается на академический замер CyberGym: по её словам, языковые модели перешли от менее 20% найденных уязвимостей в начале прошлого года к более 85% в этом году. Это один замер, и ссылку на него даёт сама заинтересованная сторона.

Почему проверки человеком в этом потоке нет

Компания прямо описывает узкое место: находок намного больше, чем людей, способных их проверить. Из более 29 000 предполагаемых уязвимостей вручную разобрали примерно 6 000, и дальше, по её словам, упор идёт в человеческие силы.

При этом, пишет Anthropic, мейнтейнеры сами просят отдать им всё, включая непроверенное: таких отчётов на сегодня отправлено почти 5 000. Отсюда и устройство нового сервиса. Проверенные человеком раскрытия продолжаются по прежнему порядку согласованного раскрытия уязвимостей, особенно для проектов, у которых нет сил разбирать отчёты самим. OSS Scanner это необязательный быстрый путь для тех, кто хочет получать находки сразу.

Плата за скорость названа в том же абзаце: вывод полностью машинный, без проверки и разбора человеком, значит отчёты могут быть неверными или недействительными. Делают их, по словам компании, её сильнейшие модели, включая Claude Mythos.

Что говорят мейнтейнеры

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

  • wolfSSL: из 74 полученных отчётов недействительными оказались два, пять превратились в CVE, то есть в записи публичного каталога уязвимостей. Исправления, приложенные к отчётам, по его словам, встали в существующий процесс проверки и починки.
  • OpenSSL: ранние отчёты от ИИ около 18 месяцев назад он называет ужасными, а отчёты Anthropic, включая сырой вывод модели, оценивает как не хуже, а иногда лучше того, что приходит от людей.
  • PostgreSQL: необычно высокая доля находок сканера указала на дефекты PostgreSQL, часть отчётов пришла с исправлениями, которые можно использовать почти как есть.
  • HotCRP: отчёты в отзыве описаны как подробные и понятные, с хорошим пониманием сложной модели прав доступа в его системе.

Там же Anthropic приводит и обратную сторону: некоторые мейнтейнеры говорили, что оценка важности бывает завышена или что сканер неверно понял модель угроз проекта. Компания пишет, что не может обещать безупречной работы сканера и будет его дорабатывать.

Кто может подключиться

Подать заявку могут основные мейнтейнеры подходящих проектов, то есть те, кто ведёт проект и отвечает за его код. Делается это через pull request в репозиторий на GitHub по стандартному шаблону. Репозиторий это хранилище кода проекта, а pull request это предложенное изменение в него, которое владельцы хранилища принимают или отклоняют. Критерии похожи на критерии OSS-Fuzz: проект должен иметь, как сказано в посте, критическое значение для инфраструктуры и безопасности пользователей, а решение принимается в каждом случае отдельно.

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

Рядом Anthropic объявила ещё два направления: Cyber Verification Program, которая даёт подходящим специалистам по безопасности расширенные возможности и ослабленные ограничители моделей, и Claude for OSS с бесплатными подписками Claude Max 20x на устранение уязвимостей в открытых проектах.

Что из этого следует для компании, которая библиотеки только использует

Если ваш сайт, приложение или внутренний сервис собраны с использованием открытых библиотек (веб-сервер, база данных, библиотека шифрования и другие готовые части), дальше речь про вас. Какие именно библиотеки у вас в деле и сколько их, нужно выяснить у разработчика, а если такого перечня нет, составить его. Прямого участия в новом сервисе у вас при этом нет. Но из объявления следует вещь, которая вас касается: по словам Anthropic, эксплойты теперь могут разрабатываться за минуты, а значит ценность имеет скорость установки исправлений. Станет ли самих исправлений в библиотеках выходить больше, объявление не говорит, и я этого не утверждаю: это можно только предполагать, глядя на числа найденных и отправленных отчётов.

Четыре шага, которые из этого следуют. Каждый проверяемый, и у каждого есть ответственный.

  1. Знать, из чего собран ваш продукт. Нужен список библиотек и их версий, а не память разработчика.
    • Кто делает: разработчик или подрядчик, который собирает ваш продукт.
    • Чем проверить: попросите список библиотек с версиями в виде файла и дату, на которую он собран. Как именно его получают, зависит от того, на чём собран ваш продукт, это вопрос к разработчику. Если списка нет, это первая задача.
  2. Получать уведомления об уязвимостях в своих библиотеках. У части площадок, где хранится код, такие предупреждения есть во встроенных возможностях, и тогда их нужно просто включить. Если у вашей площадки их нет или код лежит не на площадке, остаётся второй путь: подписаться на рассылки об уязвимостях у самих библиотек, которые вы используете.
    • Кто делает: тот, кто администрирует хранилище кода, вместе с тем, кто отвечает за обновления.
    • Чем проверить: назовите человека, на чей адрес приходят такие письма, и покажите последнее пришедшее предупреждение с датой. Отсутствие писем за месяц само по себе ничего не доказывает, а обычное тестовое письмо не доказывает, что дойдёт именно предупреждение об уязвимости: надёжный признак это настоящее предупреждение, которое кто-то в компании уже получил и разобрал. Если у вас нет ни встроенных предупреждений, ни рассылки библиотеки, остаётся временная мера: по своему списку библиотек раз в месяц смотреть сообщения об уязвимостях в открытых базах, где такие сообщения собирают, и записывать дату проверки. Предел этой меры понятен: между проверками критичная находка останется незамеченной, поэтому её держат до появления уведомлений, а не вместо них. Для критичной находки порядок такой: сначала оценить, затронута ли ваша версия; затем, если исправление вышло, проверить его на тестовой копии и ставить вне очереди. Если исправления ещё нет или проверка не прошла, решение принимает тот, кто отвечает у вас за работу сервиса: обычно это временная мера, например отключение затронутой возможности или закрытие доступа к ней извне, пока исправление не появится.
  3. Договориться о сроке на критичные обновления. Польза от быстрого исправления есть только тогда, когда оно доезжает до вашего сервера.
    • Кто делает: вы вместе с разработчиком, письменно, в договоре или в регламенте.
    • Чем проверить: возьмите последнее критичное обновление библиотеки и посмотрите по истории изменений, сколько дней прошло от его выхода до установки у вас.
  4. Проверять обновления на копии, а не на живом сервисе. Обновление библиотеки безопасности иногда ломает работу приложения.
    • Кто делает: разработчик.
    • Чем проверить: есть тестовая копия, недоступная из интернета, на ней обновление ставится первым, и только после этого выходит на живой сервис.

Отдельно про отчёты: если вы ведёте открытый проект и получили машинный отчёт об уязвимости, относиться к нему стоит как к заявке, а не как к приговору. В самом объявлении сказано, что отчёт может быть неверным, а оценка важности завышенной. Воспроизводящий пример из отчёта запускают на тестовой копии, отключённой от интернета и от рабочих данных. Если ошибка повторилась, это подтверждение воспроизводимости. Насколько она опасна именно в вашей обстановке, это отдельный вопрос: сканер, как пишет Anthropic, может неверно понять модель угроз проекта, поэтому последствия находки оценивает специалист по безопасности. Если ошибка не повторилась, отчёт тоже не закрывают: условия на копии могут отличаться от рабочих, и такой отчёт отдают тому же специалисту.

Что нейросети вообще умеют во взломах и где спотыкаются, я разбирал в статье Может ли ИИ взломать сервер или сайт. Про случаи, когда ИИ-агент обходит поставленные ему правила, есть отдельный разбор: Когда ИИ-агент обходит правила.

Чего из этой новости ждать нельзя

  • Что открытый код станет безопасным. Сервис ищет уязвимости в отдельных проектах, подавших заявку. Про общий уровень защищённости открытого кода в объявлении ничего не сказано.
  • Что все отчёты верны. Компания сама пишет, что проверки человеком в этом потоке нет и отчёты могут быть неверными или недействительными.
  • Что ваш проект возьмут. Критерий отбора в объявлении это критическое значение для инфраструктуры и безопасности пользователей, решение принимается в каждом случае отдельно.
  • Что это заменяет вашу защиту. Проверка чужой библиотеки ничего не говорит про ваш собственный код, настройки сервера и пароли сотрудников.

Итог

8 октября 2026 года Anthropic запустила OSS Scanner: добровольные бесплатные проверки открытых проектов её сильнейшими моделями, с отчётами, в которых есть воспроизводящий пример и иногда заготовка исправления. Цена скорости названа прямо: человек эти отчёты не проверяет, часть может оказаться неверной. По цифрам компании за полгода её модели нашли более 29 000 предполагаемых уязвимостей, разобрать вручную удалось около 6 000, а в выборочной проверке 85 из 97 находок критичной и высокой важности прошли планку её порядка раскрытия. Для компании, которая библиотеки только использует, практический вывод один: при скорости, о которой говорит сама компания, выигрывает тот, у кого короче путь от выхода исправления до установки на свой сервер.

Я занимаюсь ИИ-агентами и автоматизацией. Если хотите посмотреть мои проекты или обсудить свою задачу, загляните в портфолио.

Источники