Google Mantis: поиск и проверка уязвимостей AI-агентами
2 сентября 2026 года Google опубликовала практическое руководство по Mantis — открытому набору навыков для AI-агентов, который автоматизирует поиск, отбор, воспроизведение и исправление уязвимостей в программном коде. Инструмент доступен в GitHub и не привязан к одному стеку разработки.
Это не обычный сканер с единственной моделью. Mantis строит последовательный процесс из специализированных этапов: изучает архитектуру и историю репозитория, формирует модель угроз, ищет подозрительные участки, удаляет дубли, критикует находки, пытается воспроизвести проблему в изолированной среде и только затем готовит исправление и отчёт.
Для команд в Узбекистане такой подход интересен как основа внутреннего эксперимента по AppSec. Однако Mantis прямо предупреждает: автоматически найденные уязвимости и патчи должны проверяться специалистом, а запуск сгенерированного кода допустим только в изолированной среде без доступа к production, секретам и внутренней сети.
Как устроен конвейер Mantis
Репозиторий содержит модульные Skills, которые можно подключить к совместимому кодовому агенту. Отдельные роли отвечают за архитектурный обзор, моделирование угроз, план проверки, поиск дефектов, дедупликацию, валидацию, воспроизведение, построение цепочек эксплуатации, патчинг, оценку риска и итоговый отчёт.
Главная идея — не доверять первой гипотезе модели. Потенциальная проблема проходит через агентов-рецензентов и критиков, а затем проверяется воспроизводимым тестом. Это должно уменьшить число ложных срабатываний, характерных для прямого запроса к LLM в стиле «найди все уязвимости».
Mantis также анализирует историю коммитов, чтобы учитывать прежние исправления, и строит иерархическое описание репозитория. По данным Google, такое свёртывание контекста снизило расход токенов более чем на 85% при сохранении важных сведений о структуре больших проектов. Это результат разработчика инструмента, а не независимый бенчмарк, поэтому его следует проверять на собственном коде и выбранной модели.
Чем Mantis отличается от SAST и одиночного AI-ревью
Традиционный SAST применяет заранее заданные правила и анализ потоков данных. Он предсказуем, интегрируется в CI/CD и хорошо обнаруживает известные классы ошибок, но может пропускать бизнес-логику и сложные межмодульные связи. AI-агент способен рассуждать о контексте, однако склонен придумывать несуществующие пути эксплуатации.
Mantis пытается соединить преимущества подходов: статический анализ можно использовать как источник кандидатов, а агентный конвейер — для контекстной проверки, дедупликации и воспроизведения. В репозитории описан промежуточный JSONL-формат для импорта находок из CodeQL, Semgrep, Bandit и других инструментов.
Поэтому Mantis разумнее рассматривать не как замену SAST, ручного pentest или code review, а как дополнительный слой исследования. Сам факт успешного воспроизведения ещё не доказывает эксплуатацию во всех конфигурациях, а неудача теста не делает находку автоматически ложной.
Как запустить безопасный пилот Google Mantis
Google предлагает клонировать репозиторий Mantis и попросить кодового агента помочь с настройкой проверки нужного проекта. В репозитории также указана установка набора навыков через команду npx skills add google/mantis.
Для корпоративного пилота лучше не начинать с основного продукта. Подойдёт небольшой открытый или синтетический сервис, содержащий заранее известные дефекты. Команда сможет измерить качество без риска для клиентов и данных.
Минимальный безопасный контур включает:
- отдельную виртуальную машину или одноразовый контейнер без доступа к production;
- копию репозитория без секретов, персональных данных и рабочих ключей;
- запрет исходящих соединений, кроме явно необходимых зависимостей;
- ограничение процессора, памяти, диска и времени выполнения;
- неизменяемый снимок проверяемого коммита;
- ручное подтверждение перед применением любого патча;
- повторный запуск тестов и SAST после исправления.
На первом этапе стоит разрешить Mantis только создавать отчёты и воспроизводящие тесты в песочнице. Автоматическое изменение основной ветки или отправку отчётов внешним сопровождающим лучше отключить.
Какие метрики важны бизнесу
Оценивать Mantis по количеству найденных проблем опасно: большой список может означать низкую точность. Полезнее измерять долю подтверждённых находок, время специалиста на проверку, число воспроизводимых дефектов, качество минимальных патчей и отсутствие регрессий.
Отдельно следует учитывать стоимость моделей и инфраструктуры. Многоэтапный процесс использует несколько агентных проходов, поэтому экономия токенов на представлении репозитория не гарантирует низкую итоговую цену. Для небольших команд выгоднее ограничить область проверки критичными компонентами: аутентификацией, обработкой файлов, платёжной логикой, API-шлюзом и участками, работающими с пользовательским вводом.
Результаты должны попадать в существующий процесс управления уязвимостями: с владельцем, приоритетом, сроком исправления и доказательством повторной проверки. AI-отчёт без ответственного исполнителя не снижает риск.
Ограничения, о которых предупреждает сам проект
Mantis генерирует и запускает потенциально нестабильный код. Разработчики требуют использовать только ограниченные среды и не подключать комплекс к системам с чувствительными данными или внутренним сетям. Они также подчёркивают недетерминированность моделей и необходимость ручной проверки специалистом по безопасности.
Не следует массово отправлять автоматически сформированные отчёты в чужие open-source проекты. До раскрытия уязвимости нужно подтвердить её влияние, исключить ошибку среды, подготовить минимальное доказательство и соблюдать политику ответственного раскрытия конкретного проекта.
Вывод
Mantis показывает зрелый сценарий применения AI в AppSec: модель не просто предлагает исправление, а работает внутри процесса с критикой, воспроизведением и повторной проверкой. Открытая архитектура позволяет изучить этапы и встроить их в существующие инструменты команды.
Но ценность комплекса зависит от дисциплины внедрения. Изолированная среда, фиксированный снимок кода, ручная верификация и измеримые критерии точности важнее количества агентов. При таких условиях Mantis может стать полезным исследовательским помощником, а не источником новых рисков.
