AWS Continuum, сервис для поиска и исправления уязвимостей в коде, стал общедоступен 22 октября. AWS заявляет о 89% успешных исправлений в бенчмарке CyberGym-E2E, но в проверке на устранение именно той исторической уязвимости, ради которой создана задача, результат составил 37,8%. Для команд, которые рассматривают ИИ-агентов как замену части AppSec-процесса, это важнее красивого заголовочного процента.
Сервис сканирует репозитории, сопоставляет находки с контекстом AWS-инфраструктуры и создаёт pull request с предложенным патчем. По данным The New Stack, Continuum не ограничивается обычным списком срабатываний: он пытается подтвердить эксплуатируемость проблемы в изолированной среде, оценить путь атаки и потенциальный радиус последствий. Идея здравая: CVSS-оценка сама по себе плохо отвечает на вопрос, надо ли будить дежурного инженера среди ночи.
В AWS говорят, что система собирает контекст из топологии ресурсов, сетевой доступности, связей идентификационных политик и зависимостей приложений. Затем она должна отделить теоретическую ошибку в библиотеке от уязвимости, до которой злоумышленник действительно может добраться в конкретном окружении. Для подтверждённой проблемы Continuum предлагает не только изменения в коде, но и обновление зависимости либо конфигурационную правку. Патч отправляется в привычный разработчикам поток работы — как pull request для ревью и слияния.
Главная цифра появилась ещё 5 октября. В прогоне CyberGym-E2E сервис выполнил 819 из 920 задач, или 89%. AWS сопоставляет это с предыдущим публичным максимумом в 65,9%. Генеральный директор AWS Мэтт Гарман назвал результат подтверждением того, что ИИ становится практическим инструментом защитников. Но у бенчмарков, особенно агентных, всегда есть мелкий шрифт размером примерно с бюджет отдела безопасности.
CyberGym-E2E даёт агенту 90 минут на работу с одним из 139 open source-проектов. В задаче нет описания бага, готового proof of concept, crash log или ссылки на существующий фикс. Агент должен сам найти дефект, воспроизвести его и подготовить изменение, которое устраняет падение и не ломает набор тестов проекта. Все 920 задач посвящены ошибкам безопасности памяти в C и C++. Это полезная, но довольно узкая выборка: она ничего напрямую не говорит о типичном для корпоративной разработки наборе из Java, Python, JavaScript, инфраструктурного кода, уязвимостей доступа и неверных конфигураций.
Проверка состоит из нескольких ступеней. Continuum нашёл и воспроизвёл уязвимость в 92,5% задач, остановил падение в 89,6%, а в 89% случаев сохранил прохождение тестов. Именно последний показатель AWS использует как end-to-end успех. Однако финальная стадия спрашивает строже: исправил ли патч конкретную историческую уязвимость, заложенную в задачу бенчмарка? Здесь результат — 37,8%; предыдущий публичный максимум составлял 26,2%.
Это не значит, что остальные патчи бесполезны. В одном репозитории может жить несколько независимых дефектов, и агент, не знающий целевой CVE, мог найти и исправить другой настоящий баг. AWS справедливо указывает на эту особенность методики. Но практический смысл цифры меняется. «Нашли любую проблему, убрали падение и не сломали текущие тесты» — хороший результат для помощника по поиску дефектов. «Исправили инцидент, который принёс в работу security-команда» — другая задача, и по ней доступных данных заметно меньше.
Есть и ещё одно ограничение: испытания провела сама AWS. Компания утверждает, что соблюдала правила теста, в том числе ограничения на доступ к интернету, и проверяла, не подтягивает ли агент уже опубликованные исправления. При увеличении лимита времени результат, по её данным, растёт до 93,7%. Бенчмарк и инструменты тестирования открыты, но независимого воспроизведения именно этих результатов пока нет. Для рынка это не приговор, а нормальное состояние громкого vendor benchmark: сначала появляется цифра, потом несколько месяцев уходят на попытки понять, что именно она измеряет.
Для разработчиков ценность AWS Continuum может быть не в автоматическом мердже патчей, а в сокращении очереди из находок. Вместо тысячи предупреждений от сканеров команда получает кандидатов, для которых есть доказательство достижимости, описание пути атаки и готовое изменение. Но PR от агента всё равно требует обычной инженерной дисциплины: проверить логику, регрессию, зависимости, разрешения и то, не закрыл ли патч симптом вместо причины. Прохождение существующих тестов — не сертификат безопасности, особенно если тесты не покрывают атакующий сценарий.
Для российских команд, работающих с AWS или строящих похожий процесс на собственном облаке, вывод тоже прикладной: покупать здесь стоит не обещание «исправить 89% багов», а связку из валидации, приоритизации и контролируемого ревью. Следующий содержательный тест для таких агентов — результаты на заданных CVE, разных языках и реальных монорепозиториях, где цена неверного патча выше, чем одна красная сборка. Подробнее о методике и цифрах — в .
