Google Mantis: AI-фреймворк для поиска и исправления уязвимостей в коде

Google Mantis: что представила Google и зачем нужен этот фреймворк

Google Mantis в заявленном описании, это open-source-фреймворк для автоматизации поиска, проверки, воспроизведения и исправления уязвимостей в программном коде. Его идея строится вокруг AI-агентов, которые изучают структуру репозитория, формируют гипотезу о проблеме, запускают проверки в изолированной среде и готовят вариант исправления.

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

На 2 сентября 2026 года в доступных материалах нет подтверждённой документации Mantis с командами запуска, перечнем языков, лицензией и точной схемой архитектуры. Поэтому ниже факты о заявленном назначении фреймворка отделены от общей модели AI-анализа безопасности. Перед практическим использованием нужно сверить детали с репозиторием и документацией Google.

Коротко: потенциальная ценность Mantis связана с переходом от списка подозрительных мест к проверяемому security-workflow, где AI ищет проблему, пытается доказать её наличие и помогает подготовить патч. Автоматический результат всё равно требует проверки инженером.

Чем Mantis отличается от обычного сканера кода

Статический анализатор ищет известные опасные конструкции в исходниках. Он работает быстро и может проверять каждый pull request, однако часто не видит полный контекст приложения. Один и тот же вызов может быть безопасным после предварительной фильтрации данных и опасным, если такой фильтрации нет.

Динамический анализ запускает программу или тестовый сценарий и проверяет её поведение. Такой подход даёт более наглядное подтверждение, но зависит от качества тестов, настроек окружения и покрытия кода.

Агентный security-workflow соединяет несколько действий в одну задачу. AI может прочитать конфигурацию, проследить связи между модулями, изучить зависимости, запустить тесты и сопоставить вывод терминала с исходной гипотезой.

Подход	Что проверяет	Типичный результат	Основное ограничение
Статический анализ	Шаблоны и связи в коде	Список предупреждений с указанием файла и строки	Много находок требуют ручного подтверждения
Динамическая проверка	Поведение программы во время запуска	Ошибка, трассировка или успешный тестовый сценарий	Покрытие зависит от тестов и окружения
AI-агентный анализ	Код, зависимости, историю, тесты и результаты команд	Гипотеза, доказательство, оценка риска и патч	Агенту нужны права, вычислительные ресурсы и контроль действий

Похожий тренд заметен в других инструментах для безопасности кода. В статье о Google CodeMender разобран сценарий, где AI-агент ищет уязвимость, проверяет её симуляцией атаки и готовит патч. Mantis в таком сравнении интересен как фреймворк, то есть набор компонентов и подходов для построения подобного процесса, а точные границы его возможностей требуют отдельной проверки.

Что означает open source в случае Mantis

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

Статус open source не означает автоматическую готовность к промышленному применению. Перед запуском нужно проверить пять параметров:

• лицензию и правила использования кода;
• активность разработки и частоту обновлений;
• список поддерживаемых языков, фреймворков и систем сборки;
• способ хранения исходников, логов и артефактов;
• наличие тестов, документации и известных ограничений.

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

Как AI-агенты проходят путь от подозрения до исправления

Условный сценарий работы Mantis можно представить как цепочку из шести шагов: изучение репозитория, поиск подозрительного участка, построение гипотезы, проверка, воспроизведение и подготовка исправления. Такая схема описывает общий агентный security-workflow. Точные действия Mantis следует подтвердить по исходникам.

Сначала агент изучает структуру проекта и зависимости

Одна строка кода редко объясняет риск целиком. Агенту нужно увидеть точки входа приложения, обработчики запросов, конфигурацию, зависимости, тесты, документацию и связи между модулями.

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

Для такого анализа полезны:

• файлы конфигурации и настройки окружения;
• граф зависимостей и версии пакетов;
• маршруты, API-методы и точки обработки пользовательского ввода;
• тесты, которые описывают ожидаемое поведение;
• документация с правилами доступа и бизнес-логикой.

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

Затем формируется и проверяется гипотеза об уязвимости

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

Последовательность выглядит так:

1. найти источник пользовательских или внешних данных;
2. проследить путь до операции, которая может привести к ошибке;
3. определить условия эксплуатации и необходимые права;
4. запустить тест или другой безопасный сценарий проверки;
5. сопоставить результат с исходной гипотезой;
6. оценить влияние на конфиденциальность, целостность и доступность системы.

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

Финальный этап - воспроизведение, отчёт и патч

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

Предложенный патч нужно воспринимать как рабочую гипотезу. Он должен:

• устранять исходный сценарий эксплуатации;
• сохранять ожидаемое поведение приложения;
• проходить существующие тесты;
• получать отдельный тест на найденную проблему;
• проходить повторное сканирование и review владельца компонента.

Автоматический merge без контроля разработчика создаёт новый риск. AI может исправить конкретный путь данных и одновременно нарушить совместимость API, обработку ошибок или производительность.

Зачем Mantis запускает проверки в sandbox-окружении

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

Какие действия агента нужно изолировать

AI-агент в ходе проверки может выполнять действия, которые нельзя бездумно разрешать на рабочем ноутбуке или сервере:

• устанавливать пакеты и собирать проект;
• запускать непроверенные скрипты и тесты;
• обращаться к тестовой базе данных;
• отправлять сетевые запросы;
• работать с proof-of-concept для воспроизведения проблемы;
• читать файлы, переменные окружения и секреты.

Минимальный набор ограничений включает отдельную файловую систему, запрет доступа к production-секретам, контроль сети, ограничение CPU и памяти, короткое время жизни окружения и отдельного пользователя без административных прав.

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

Почему логи и артефакты важнее одного вывода AI

Фраза модели о найденной уязвимости сама по себе не доказывает результат. Инженеру нужны следы действий, которые можно проверить вручную.

Полезный набор артефактов включает:

• команды, которые запускал агент;
• вывод терминала и сообщения об ошибках;
• трассировку теста или proof-of-concept;
• список изменённых файлов;
• версию исходного кода и зависимостей;
• сравнение состояния до и после патча.

Такой формат связывает finding с реально выполненными действиями. Руководитель видит основание для приоритета, а разработчик получает материал для повторной проверки. Наличие именно такого набора функций у Mantis нужно подтвердить до запуска в рабочем процессе.

Как sandbox помогает уменьшить ложные срабатывания

Изолированное окружение позволяет проверить, воспроизводится ли проблема в условиях, близких к запуску приложения. Теоретически опасный фрагмент может оказаться недоступным извне, защищённым другим модулем или неработающим из-за конкретной версии зависимости.

Sandbox помогает проверить эти условия без риска для основной системы. Он не гарантирует полноту анализа. Уязвимость может зависеть от реальной инфраструктуры, внешнего сервиса, редкой последовательности действий или данных, которых нет в тестовой среде.

История репозитория и security-summary tree: как AI получает контекст без перегрузки

Текущий снимок кода показывает состояние проекта, но не всегда объясняет происхождение проблемы. История Git добавляет временную линию, а иерархическое резюме помогает передавать модели крупные репозитории частями.

Что история Git может рассказать об уязвимости

Коммиты, pull request и blame помогают выяснить, когда изменился участок, кто его редактировал и какой замысел стоял за правкой. История похожих исправлений показывает, повторялась ли проблема раньше.

Пример: после рефакторинга из обработчика исчезла проверка входных данных. Анализ текущего файла покажет отсутствие проверки. История Git может указать коммит, где она пропала, связанный pull request и предыдущий вариант функции. Это ускоряет поиск причины регрессии и помогает подготовить тест, который не даст ошибке вернуться.

Для security-анализа полезны:

• изменения в коде перед появлением дефекта;
• обновления библиотек и системных компонентов;
• предыдущие патчи безопасности;
• обсуждения pull request, если они доступны агенту;
• связь коммита с тестами и задачами.

Как работает идея security-summary tree

Security-summary tree можно объяснить как многоуровневую карту репозитория. На верхнем уровне модель получает сжатое описание назначения проекта и крупных рисков. Ниже раскрываются сервисы, каталоги, модули, функции и конкретные строки.

Уровень дерева	Что может содержать	Когда нужен
Репозиторий	Назначение системы, основные технологии, зоны риска	Для первичного выбора направления анализа
Сервис или компонент	Точки входа, зависимости, права доступа	Для оценки архитектурного контекста
Модуль и функция	Потоки данных, проверки, вызовы API	Для проверки гипотезы
Строки кода	Конкретная операция и предложенное изменение	Для воспроизведения и review патча

Верхушка дерева сжимает общий смысл, детализация растёт вниз по нужной ветви. Такая структура напоминает карту с разным масштабом: сначала виден район, затем улица и конкретный дом.

Название, формат узлов и алгоритм построения security-summary tree для Mantis требуют подтверждения по исходникам проекта. Философские или метафорические описания иерархических структур не доказывают наличие конкретного компонента в Mantis.

Почему иерархия лучше полного снимка репозитория

Большой репозиторий нельзя без ограничений передать AI-модели целиком. Полный снимок увеличивает расход токенов, замедляет анализ и повышает риск, что важная деталь потеряется среди второстепенных файлов.

Дерево задаёт последовательность: сначала агент выбирает релевантный компонент, затем раскрывает его зависимости и функции, после этого переходит к строкам и тестам. Объём контекста сокращается, а структура проекта сохраняется.

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

Кому Mantis может быть полезен на практике

Mantis может пригодиться там, где безопасность кода требует регулярных проверок, а у команды нет времени вручную разбирать каждый сигнал. Фреймворк стоит воспринимать как помощника для ускорения анализа, а не как замену разработчикам и специалистам AppSec.

Для разработчиков: проверка pull request и регрессий

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

В рабочем процессе полезны четыре результата:

1. ссылка на конкретный файл, функцию и строки;
2. описание пути эксплуатации;
3. тест, который воспроизводит проблему;
4. патч с повторной проверкой после изменения.

Поддержку GitHub, CI/CD, систем задач и pull request нужно проверять по документации Mantis. Само позиционирование open-source-фреймворка ещё не подтверждает наличие готовых интеграций.

Для DevSecOps и AppSec-команд: triage вместо потока алертов

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

Ценность появляется при наличии доказательств: команд, логов, тестового сценария и версии окружения. Без них AI-отчёт остаётся предположением, даже если он написан убедительно.

Похожую многоагентную логику применяет Claude Security, о которой мы писали отдельно в разборе инструмента Anthropic. При сравнении продуктов нужно смотреть на подтверждаемость находок, процесс review и контроль доступа, а не на число упомянутых агентов.

Для руководителей: что оценивать кроме демонстрации AI

Эффектное демо не показывает, насколько инструмент пригоден для регулярной работы. Перед выбором фреймворка полезно измерить:

• долю подтверждённых находок среди всех предупреждений;
• время от запуска до воспроизводимого результата;
• долю патчей, которые проходят тесты без ручной переработки;
• стоимость анализа одного pull request или репозитория;
• поддерживаемые языки, сборщики и зависимости;
• условия хранения исходного кода и логов;
• удобство подключения к текущему CI/CD-процессу.

Такой список помогает сравнить Mantis с традиционным SAST, DAST, ручным аудитом и другими AI-инструментами на одинаковых примерах.

Как запустить Mantis: требования и безопасный сценарий проверки

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

Что проверить перед установкой

Найдите официальный GitHub-репозиторий Google и документацию проекта, затем сверяйте каждый параметр с выбранной версией. Проверьте:

• поддерживаемую операционную систему;
• версию Python или другого необходимого рантайма;
• требования к Docker, виртуальной машине или sandbox;
• модель, способ её подключения и необходимость API-ключа;
• лимиты запросов, вычислительные ресурсы и ориентировочную стоимость;
• правила сетевого доступа для агента;
• способ передачи секретов и срок хранения логов;
• объём репозитория и поддерживаемые языки;
• лицензию и правила обработки конфиденциального кода.

Первый запуск лучше проводить на учебном или обезличенном репозитории. Production-код, боевые ключи и доступ к рабочим базам данных не должны появляться в экспериментальном окружении.

Первый запуск на небольшом тестовом репозитории

Выберите проект, в котором есть известная учебная уязвимость или заранее подготовленный тестовый пример. Зафиксируйте commit, версии зависимостей и ожидаемый результат ручной проверки.

Перед запуском ограничьте права процесса, отключите доступ к production-секретам и настройте сетевые правила. Включите сохранение команд и вывода, если такая функция предусмотрена документацией. Затем сравните четыре результата:

1. нашёл ли Mantis заранее известную проблему;
2. описал ли конкретный путь эксплуатации;
3. смог ли воспроизвести сценарий в sandbox;
4. подготовил ли изменение, которое проходит тесты.

После исправления запустите повторную проверку. Уязвимость должна исчезнуть из отчёта, а функциональные тесты должны сохранить ожидаемый результат.

Как оценить результат после запуска

Полезный security finding содержит конкретные признаки, а не общую фразу о потенциальной опасности. Проверьте наличие:

• файла, функции и строк, связанных с проблемой;
• описания источника и пути данных;
• минимального сценария воспроизведения;
• логов и артефактов выполненной проверки;
• оценки влияния и необходимых прав атакующего;
• патча с тестом на исходную уязвимость;
• результата повторного сканирования после исправления.

Для объективной оценки сравните Mantis с ручным аудитом на одном и том же наборе из пяти или десяти тестовых проблем. Отдельно посчитайте пропущенные уязвимости, ложные срабатывания и время инженера на проверку каждого результата.

Ограничения Mantis: почему AI-поиск уязвимостей не отменяет эксперта

AI хорошо работает с повторяющимися шаблонами и большими объёмами кода. Сложнее ему даются правила, которые нигде явно не записаны: бизнес-логика, договорённости между сервисами, особые права пользователей и реальные настройки инфраструктуры.

Какие уязвимости AI может не заметить

Даже глубокий анализ может пропустить:

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

Галлюцинации AI тоже остаются риском. Модель может сослаться на несуществующую функцию, неверно описать поведение библиотеки или заявить об успешном тесте, который не запускался. Логи и повторяемые команды помогают обнаружить такую ошибку.

Как проверять предложенный патч

Патч нужно оценивать по исходной проблеме и по побочным последствиям. Минимальная процедура включает тест на уязвимость, регрессионные тесты, анализ diff, повторное сканирование и review владельца компонента.

Автоматическое исправление не должно сразу попадать в production. Сначала разработчик проверяет читаемость изменения, совместимость интерфейсов, обработку ошибок и влияние на производительность. Для критичных систем полезно требовать двух независимых подтверждений: результат теста и ручное одобрение.

Что делать с конфиденциальным исходным кодом

Перед запуском проверьте, где работает агентный цикл и какая часть кода отправляется модели. Уточните, сохраняются ли логи и артефакты, кто получает к ним доступ, можно ли удалить данные и работает ли инструмент локально.

Отдельно настройте секреты. Агенту не нужны production-ключи, постоянные токены и широкие права на файловую систему. Для тестов используйте временные учётные данные с минимальным набором разрешений.

Sandbox снижает риск повреждения локальной машины и случайного запуска опасной команды. Он не защищает от утечки данных, неверной настройки сети или передачи чувствительного кода внешней модели. Эти вопросы нужно сопоставить с политиками компании и лицензией проекта.

Итог: Mantis как помощник для проверяемого security-workflow

Google Mantis в заявленном позиционировании отражает переход к агентному анализу безопасности. AI получает контекст проекта, ищет подозрительные пути данных, запускает проверки, пытается воспроизвести проблему и готовит исправление.

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

Короткий чек-лист перед использованием

1. Найдите официальный репозиторий, документацию и лицензию Mantis.
2. Проверьте поддерживаемый стек, модель, рантайм и требования к ресурсам.
3. Запускайте анализ в sandbox с ограниченными правами и без production-секретов.
4. Требуйте воспроизводимые доказательства: команды, логи, тесты и артефакты.
5. Проверяйте каждый патч вручную, запускайте регрессионные тесты и повторное сканирование.

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