В 66% компаний с оценкой свыше $1 млрд критические уязвимости остаются неисправленными. На этом фоне Chainguard представила ИИ-харнесс безопасности — систему, которая использует передовые языковые модели для поиска уязвимостей, но делает ставку не на эффектные отчёты об обнаружении бага, а на проверяемый результат, сообщает The New Stack. Для российских команд это знакомый сюжет: найти проблему в CI относительно легко, а вот довести её до исправления без остановки разработки — совсем другая дисциплина.
В основе подхода Chainguard — применение ИИ-агентов и frontier-моделей, включая Claude Mythos 5.1 от Anthropic, доступ к которой ограничен. Компания пытается автоматизировать работу, для которой мало одного сканера: исследование кода, воспроизведение условий, оценку достижимости уязвимости и подготовку доказательств того, что проблема действительно существует. Само наличие CVE в зависимости ещё не означает инцидент; но и отсутствие удобного эксплойта не означает, что тикет можно бессрочно отправлять в бэклог.
Название harness здесь важнее, чем очередная модель в составе продукта. Речь идёт о контуре, который задаёт агенту задачи, ограничения и способы проверки результата. Генеративная модель умеет правдоподобно объяснить найденный дефект, написать патч и даже предложить тест. Но безопасность требует воспроизводимости: можно ли подтвердить уязвимость, не сломал ли патч бизнес-логику, действительно ли изменение закрывает путь атаки? Без такого контура ИИ-поиск багов легко превращается в дорогой генератор гипотез и ложных срабатываний.
Рынок уже переполнен обещаниями «автономного» поиска уязвимостей. Они звучат убедительно, особенно когда демонстрация заканчивается готовым proof of concept. Однако у служб разработки и безопасности другой KPI: сократить окно между обнаружением критической проблемы и её устранением. Если разработчик получает ещё сотню алертов без контекста, команда не становится безопаснее — она просто быстрее выгорает. Цифра в 66% компаний с незакрытыми критическими багами показывает, что узкое место находится не только в детектировании.
Почему поиск не равен устранению
Уязвимость может зависеть от версии библиотеки, конкретной конфигурации, прав процесса, сетевой доступности и того, используется ли проблемный участок кода вообще. В большой компании добавляются владельцы сервисов, регрессионные тесты, окна релизов и необходимость объяснить приоритет продуктовой команде. Поэтому зрелый процесс начинается не с вопроса «нашёл ли ИИ CVE?», а с вопросов «достижима ли она?», «какой ущерб возможен?» и «кто может безопасно внести исправление?».
Именно здесь ИИ-харнесс безопасности может оказаться полезнее одиночного чат-бота для AppSec-инженера. Агенту можно поручить собрать контекст репозитория, проследить поток данных, предложить минимальный патч и прогнать предусмотренные проверки. Финальное решение всё равно остаётся за инженером: модель не знает договорённостей команды, особенностей клиентов и цены неудачного релиза. Зато она способна снять часть рутинной работы — при условии, что её выводы можно перепроверить в пайплайне.
Для DevSecOps-команд практический вывод довольно приземлённый. При выборе ИИ-инструмента стоит смотреть не на число «найденных» дефектов в презентации, а на долю подтверждённых проблем, качество приоритизации, возможность воспроизведения результатов и интеграцию с существующими CI/CD-процессами. Не менее важна трассируемость: специалист должен понимать, какие файлы, зависимости и предположения привели агента к выводу. Иначе аудит и разбор инцидента станут упражнением в археологии ответов модели.
Ограниченный доступ к Claude Mythos 5.1 также подчёркивает неудобную сторону новой гонки: самые мощные модели для кибербезопасности могут быть недоступны части рынка или требовать особого режима использования. Для команд с жёсткими требованиями к данным это означает, что архитектуру придётся оценивать отдельно: какие исходники и логи уходят модели, где хранятся результаты и можно ли заменить поставщика модели без переписывания процесса.
Главный тест — закрытые уязвимости
Chainguard предлагает измерять успех не количеством найденных багов, а тем, сколько опасных путей атаки команда сумела закрыть. Это менее эффектная метрика для маркетинга, но гораздо полезнее для CISO, руководителя разработки и владельца продукта. ИИ может расширить возможности небольших security-команд, однако не отменит владение сервисами, качественные тесты и дисциплину обновления зависимостей.
Следующий этап рынка ИИ для безопасности будет зависеть от того, смогут ли такие системы доказывать ценность в production: снижать очередь критических исправлений, а не просто увеличивать поток алертов. Если харнесс действительно связывает поиск, верификацию и безопасное исправление, он меняет экономику AppSec. Если нет — индустрия получит ещё одного очень убедительного охотника за багами, который оставляет разработчикам самую дорогую часть работы.