Claude Security доступна в публичной бете: что обещает «Scan to Fix» и чего она не делает

Продукт безопасности Anthropic теперь находится в публичной бете для Claude Enterprise, и его однострочный питч — это последовательность, а не прилагательное: от сканирования до исправления, бесшовно. Механика, стоящая за этой фразой, прямо изложена на странице продукта: Claude сканирует вашу кодовую базу с помощью Claude Mythos, проверяет результаты и предлагает патчи, которые вы можете просмотреть и одобрить. Три глагола, одно название модели и ограничение охвата, которое легко пропустить при беглом просмотре: это бета-версия, и она предназначена для клиентов Enterprise, а не для всех, у кого есть репозиторий.

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

Что означает «публичная бета-версия для Claude Enterprise»

Строка о доступности необычно прямолинейна, и её стоит процитировать, а не пересказывать: доступно в публичной бете для Claude Enterprise. Под ней расположены две кнопки — связаться с отделом продаж и прочитать руководство. Ни одна из них не является формой регистрации. На практике это означает, что покупатель — компания, у которой уже есть соглашение Enterprise и служба безопасности с достаточным влиянием, чтобы запросить новый сканер, а не отдельный инженер, который хочет направить что-то на побочный проект.

Есть второй, более легкий способ войти. Плагин Claude Security для Claude Code находится в бета-версии. Это другое ПО с другой историей развертывания — сканирование, проверка и исправление внутри Claude Code при сохранении кода в вашей среде — и именно эта версия важна для команды, чья проблема не в бюджете, а в правиле о том, куда разрешено передавать исходный код.

Сканирование не останавливается

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

Непрерывное сканирование — это также та часть продукта, которую сложнее всего подделать. Оно требует, чтобы сканер понимал, какие изменения важны, а это навык, отличный от поиска уязвимости в статическом дереве. На странице не описано, как работает такая приоритизация, и эта статья не будет строить догадок на этот счёт.

Единственная ось, по которой утверждение конкретно

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

Сопоставление с образцом, как следует из названия, ищет известную небезопасную структуру: вызов функции с заражённым аргументом, строку, конкатенированную в запрос, известный небезопасный API. Это быстро, дёшево, и именно поэтому традиционные сканеры известны сразу двумя вещами — они ловят один и тот же класс ошибок везде, где он встречается, и при этом заваливают команду находками, которые оказываются недостижимыми. Альтернатива — отслеживать значение от точки входа в систему до места его использования, через границы между файлами и сервисами. Именно там скрываются настоящие ошибки, и именно там анализ становится дорогим, потому что инструменту приходится удерживать больше контекста, чем помещается в одну функцию.

Обратите внимание, однако, на осторожную формулировку в этом предложении. Может не обнаружить. Это правильное слово, которое следует использовать, когда у поставщика нет эталонного теста, на который можно сослаться, и это также причина, по которой данное утверждение следует проверить на собственной кодовой базе, а не принимать как свойство продукта.

Состязательная проверка и модель угроз, которую вы можете редактировать

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

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

Это также создаёт работу. Модель угроз, которую никто не поддерживает, превращается в фильтр, скрывающий то, о чём никто не подумал, — а это противоположность тому, для чего нужен сканер. Ценность из этого извлекут те команды, которые относятся к модели угроз как к живому документу с ответственным, так же как они относятся к runbook’ам.

Патч — это единица вывода

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

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

Второе утверждение касается закрытия находок. Claude помечает находку исправленной, как только исправление выпущено, поэтому находки закрываются, а не накапливаются. Накопленный список — это не провал обнаружения. Это провал учёта: одна и та же уязвимость обнаруживается семь раз в ходе семи сканирований, и очередь растёт быстрее, чем кто-либо успевает её разбирать. Отслеживание находки вплоть до коммита, который её устраняет, — это механизм, благодаря которому непрерывный сканер становится терпимым, а не деморализующим.

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

Два релиза, одно направление

Claude Security появился не сам по себе. Anthropic выпустила Code Review в статусе общедоступного продукта 15 октября 2026 года, а непрерывное сканирование и отслеживание исправлений в Claude Security появились 21 октября 2026 года в публичной бета-версии для Claude Enterprise. Если рассматривать эти события вместе, они кое-что говорят о направлении развития: ревью перестаёт быть шлюзом, который изменение проходит в конце, и превращается в процесс, идущий параллельно с написанием изменения. Промежуток между этими датами настолько мал, что продукты стоит оценивать как единую историю о том, куда движется работа по безопасности, а не как два не связанных между собой релиза.

Что не опубликовано — и число, которое решило бы вопрос

Список неизвестных здесь длиннее списка утверждений, и это нормально для публичной беты, а не скандал. Какую долю кодовой базы покрывает сканирование, не публикуется. Длительность сканирования не публикуется. Доля ложноположительных срабатываний не публикуется. Бенчмарки обнаружения не публикуются. Независимой оценки нет. Цена за место не публикуется, как и список поддерживаемых языков.

Из них именно отсутствующий бенчмарк обнаружения меняет решение о покупке. Без него “ловит то, что пропускают сканеры на основе сопоставления шаблонов” — это утверждение общего характера, которое нельзя сравнить со сканером, уже заложенным в бюджет. Второй — список поддерживаемых языков: мультиязычный репозиторий является обычным делом для компании любого размера, а сканер, отлично работающий с тремя языками и отсутствующий для остальных пяти, — это сканер, создающий вводящую в заблуждение картину поверхности рисков.

Ничто из этого не означает, что продукт не работает. Это означает, что оценку должен проводить сам покупатель, используя собственный код покупателя, и что демонстрационная версия для этого не подойдёт.

Как это вообще оценить?

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

Во-вторых, следите за моделью угроз. Если первое, что делает ваша команда, — это отключает большинство категорий, чтобы сократить очередь, вы узнали, что модель по умолчанию не соответствует риску, который на самом деле несёт ваша команда, и вам следует исправить модель, а не фильтр. В-третьих, измеряйте тот этап, который имеет значение: сколько времени проходит с момента появления обнаружения до слияния патча. Это число принадлежит вам, оно сопоставимо между инструментами, и именно его продукт на самом деле обещает сдвинуть.

Где находится роутер, а где — нет

Границу стоит обозначить прямо. Claude Security — это приложение Anthropic. Мы не размещаем его у себя, не продаём его и не можем сказать, что оно обнаружило или не обнаружило в вашем репозитории. Сканер работает на Claude Mythos, и мы не утверждаем, что хостим эту модель.

Мы запускаем модели. Одна конечная точка, совместимая с OpenAI, один ключ, более 200 моделей за ней, цена провайдера по прайс-листу передаётся без наценки, и автоматическое переключение между провайдерами при сбое одного из них. Claude Opus 5.5 есть в этом каталоге по цене $4.00 за миллион входных токенов и $20.00 за миллион выходных токенов, с контекстом на 1M токенов и чтением из кэша по $0.20 за миллион. Это факт о нашем каталоге, а не утверждение о сканере.

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

Чему бета на самом деле просит вас доверять

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

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