AI-поиск уязвимостей уперся в неприятную арифметику: Claude Mythos сгенерировал 26 153 потенциальные проблемы в коде, но до раскрытия дошло чуть больше 10%, а исправлено меньше 0,8%. Для команд безопасности это не футуристический спор про умные модели, а вполне земной вопрос: кто будет разбирать этот поток, подтверждать баги и доводить их до патча.
По данным Dark Reading, исследователь VulnCheck Патрик Гаррити проанализировал публичный Vulnerability Disclosure Ledger Anthropic, связанный с Project Glasswing. Этот реестр отслеживает находки Claude Mythos на пути от обнаружения к раскрытию и исправлению. Project Glasswing был запущен в апреле 2026 года, и его смысл как раз в том, чтобы применять frontier-модель к поиску уязвимостей в большом числе программных проектов.
Картина получилась менее рекламной, чем любят презентации про ИИ в кибербезопасности. Из 26 153 находок только 2 736 попали в disclosure ledger: их уже передали сопровождающим проектов или готовят к передаче. Исправлено на момент анализа 202 проблемы. Еще 245 находок отозваны, а 191 находилась на стадии pre-disclosure, то есть до мейнтейнеров они пока не дошли.
Самая важная цифра здесь не 26 тысяч, а оставшиеся почти 90%, которые не попали в реестр. Это не обязательно значит, что все они ложные или бесполезные. Но это значит, что между автоматическим обнаружением и реальным исправлением лежит ручная работа: валидация, воспроизведение, оценка влияния, контакт с владельцем проекта, координация сроков раскрытия, проверка патча. И все это плохо масштабируется магической кнопкой «найти еще».
Гаррити указывает и на спор вокруг качества самих находок. Anthropic заявляла о 91,4% true positive rate для Mythos, но в реестре исправленных проблем пока меньше, чем отозванных: 202 против 245. Это не доказывает, что заявленная точность неверна, но требует аккуратности с метриками. В мире AppSec «модель нашла проблему» и «уязвимость подтверждена, оценена, принята мейнтейнером и закрыта» — разные состояния, хотя в маркетинговом слайде они часто сливаются в одну бодрую стрелку.
Отдельный конфликт возник вокруг severity. По анализу Гаррити, Claude оценил 91,5% находок из реестра как critical или high. Сами сопровождающие проектов отнесли к этим уровням 61,3%. Разница большая: если почти все красное, приоритизация перестает работать. Для разработчика это превращается в знакомую боль от шумного сканера, только с более убедительным голосом и потенциально куда большим объемом тикетов.
Похожую проблему описывает Contrast Security. Основатель компании Джефф Уильямс, один из создателей OWASP Top 10, рассказал о тестах трех AI-сканеров на кодовой базе примерно в 50 тысяч строк. Инструменты давали разные результаты при повторных прогонах, а между собой совпадали лишь по небольшой части находок. По его словам, Sonnet-based scan воспроизвел 17% собственных результатов в трех запусках, Opus — 25%, при этом число находок у Opus колебалось почти на 30% между лучшим и худшим прогоном.
Экономика тоже трезвит. Уильямс приводит пример: сканирование кодовой базы на 2 млн строк обошлось примерно в $315 API-затрат, а разбор результатов — примерно в $128 тысяч. То есть AI-поиск уязвимостей действительно может сделать обнаружение дешёвым. Но если после него появляется гора заявок, которые надо вручную проверить, стоимость просто переезжает из compute в рабочие часы инженеров безопасности и разработчиков.
Для бизнеса вывод довольно практичный. Нельзя просто подключить ИИ-сканер к репозиториям и ждать, что риск magically уйдет вниз. Нужны правила приема находок, SLA для triage, понятные критерии severity, связь с issue tracker, владельцы компонентов и дисциплина по coordinated disclosure. Иначе security backlog станет больше, отчеты — толще, а реальная поверхность атаки может почти не измениться.
Для русскоязычных команд, особенно в продуктовых компаниях и аутсорсе с плотными релизными циклами, это важный сигнал. AI-поиск уязвимостей надо внедрять не как замену AppSec-процесса, а как усилитель уже существующей системы. Если нет людей, которые умеют отличать эксплуатируемую дыру от шумной гипотезы модели, ИИ принесет не безопасность, а новую очередь в Jira.
Судя по этим данным, следующий этап гонки будет не в том, кто найдет больше потенциальных багов, а в том, кто быстрее построит конвейер подтверждения и исправления. Модели уже умеют открывать кран; индустрии теперь придется расширять трубу, через которую находки превращаются в закрытые уязвимости.