Google открыла Mantis — конвейер поиска и исправления уязвимостей с проверкой в sandbox

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

Google опубликовала Mantis — open-source harness для обнаружения, triage, воспроизведения и исправления программных уязвимостей. В отличие от одиночного запроса к модели, фреймворк организует несколько стадий и использует critic и review agents, а ключевые выводы проверяет воспроизведением в sandbox. Цель состоит не в том, чтобы получить как можно больше подозрительных мест, а в том, чтобы довести находку до подтверждаемого поведения и предлагаемого patch.

Такая постановка отвечает на главную слабость массового AI-сканирования: правдоподобное описание ошибки ещё не означает реальную уязвимость. Google отмечает, что небрежные конвейеры часто галлюцинируют проблемы и показывают true-positive rate ниже 7%. Это число относится к описанному классу слабых подходов, а не является универсальной оценкой всех инструментов. Mantis пытается повысить полезность за счёт контекста репозитория, независимой критики и изолированного доказательства.

История репозитория становится частью модели угроз

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

Автоматически построенная документация остаётся гипотезой инструмента, а не заменой знаний владельцев системы. История может быть неполной, причины изменения — не зафиксированными, а архитектурный компромисс — понятным только команде. Поэтому Google отдельно рекомендует добавлять human-curated context. Если, например, self-crash не считается значимой уязвимостью в конкретном продукте, это условие должно быть явно передано сканирующему конвейеру, чтобы он не расходовал ресурсы и внимание на нерелевантный класс находок.

Иерархическое резюме удерживает большой код в контексте

Для крупных codebases фреймворк строит hierarchical security summary tree. Сначала содержимое отдельных файлов сжимается в описания каталогов, затем эти уровни объединяются в резюме всего репозитория. Такой подход сохраняет структурные связи между компонентами и позволяет агентам обращаться к нужному уровню детализации, вместо того чтобы каждый раз загружать весь код или анализировать файлы изолированно.

По данным Google, иерархическая схема уменьшила token overhead более чем на 85%, сохранив критически важный структурный контекст в больших репозиториях. Это заявленный результат разработчика, а официальный материал не раскрывает набор проектов, базовую линию и распределение качества по языкам. Тем не менее архитектурная идея проверяема: стоимость и полноту можно измерить на собственной кодовой базе, сравнив число токенов, покрытие компонентов и обнаруженные подтверждённые уязвимости с плоским анализом.

Sandbox отделяет убедительный текст от доказательства

Mantis включает примеры вариантов sandboxing, но позволяет команде реализовать собственную изоляцию под рабочий процесс. В этом окружении потенциальная уязвимость должна быть воспроизведена по заранее определённым критериям. Только после наблюдаемого поведения находка получает надёжную опору для triage и исправления. Такой gate особенно важен для AI-анализа: модель умеет написать связное объяснение несуществующего пути атаки, а исполняемый тест вынуждает подтвердить причинную цепочку.

Изоляция должна соответствовать риску проекта. Недостаточно запустить неизвестный proof of concept рядом с рабочими credentials или production network. Команда определяет допустимые ресурсы, входы, таймауты, сетевой доступ и признаки успешного воспроизведения до того, как агент начнёт эксперимент. Google рекомендует совместить cyber sandbox с явными vulnerability acceptance criteria — так фильтрация и проверка patch опираются на техническое условие, а не на уверенность формулировки.

Запуск начинается с репозитория и coding agent

Базовый путь внедрения намеренно короткий: Mantis клонируют локально, затем просят coding agent помочь применить framework к выбранному code repository. Google сообщает, что такой подход использовался внутри компании для обнаружения реальных уязвимостей в её репозиториях. Публикация не приводит число проектов, severity найденных проблем или независимую выборку результатов, поэтому внутренний опыт подтверждает применимость, но не даёт универсальной оценки эффективности.

После освоения поиска разработчики могут подключить mantis-advise skill. Он использует накопленное знание, чтобы coding agents учитывали безопасные практики уже при написании кода. Получается обратная связь: сканирование обнаруживает повторяющиеся классы дефектов, а советующий слой переносит эти сведения на этап создания. Эффект такой петли зависит от качества подтверждённых находок — если база заполнена ложными сигналами или локальными исключениями без контекста, рекомендации будут воспроизводить шум.

Critic и review agents не отменяют независимую приёмку

Распределение ролей внутри harness снижает вероятность, что первая гипотеза модели сразу попадёт в отчёт или patch. Critic может оспорить предпосылки, review — проверить аргументацию, а sandbox — показать фактическое поведение. Но все эти участники могут разделять одни и те же ограничения модели, контекста и инструментов. Поэтому окончательную приёмку исправления нельзя сводить к согласию нескольких агентов.

Для production-проекта остаются обязательными обычные security controls: review ответственным инженером, regression tests, проверка влияния patch на совместимость и отдельный анализ того, закрывает ли изменение исходную границу доверия. Mantis автоматизирует тяжёлую часть расследования, однако официальная статья не заявляет, что framework заменяет security team. Напротив, совет добавлять экспертный контекст показывает, что качество результата прямо зависит от сформулированных людьми критериев.

Open source позволяет проверить не только результат, но и процесс

Публикация кода на GitHub делает доступным сам harness, а не только облачный отчёт. Команда может изучить последовательность агентов, способы подготовки контекста, варианты sandboxing и точки, где принимается решение о находке. Это особенно важно в безопасности: доверять следует не ярлыку AI scanner, а наблюдаемой цепочке от исходного кода через гипотезу и воспроизведение к минимальному исправлению.

Открытость не гарантирует безопасную конфигурацию по умолчанию. Пользователю всё равно нужно проверить permissions, обработку секретов, команды, доступные агенту, и границы анализируемого репозитория. Кроме того, статья не приводит лицензионный анализ зависимостей или результаты внешнего аудита самого фреймворка. Перед применением к чувствительному коду Mantis следует оценивать как новый security tool с собственным attack surface.

Ценность Mantis измеряется подтверждёнными исправлениями

Главная метрика такого конвейера — не количество предупреждений. Полезный результат состоит из воспроизводимой уязвимости, понятной severity, patch и теста, который сначала демонстрирует проблему, а после изменения перестаёт её воспроизводить. Дополнительно стоит измерять время инженера на triage, долю ложных находок и повторное появление того же класса ошибок. Только эти показатели покажут, снижает ли автоматизация реальную нагрузку.

Mantis предлагает зрелую архитектурную рамку: собрать исторический и структурный контекст, разделить генерацию и критику, воспроизвести риск в sandbox и вернуть подтверждённое знание в разработку. Заявленные менее 7% true positives у слабых сканеров и сокращение token overhead более чем на 85% подчёркивают обе стороны задачи — качество сигнала и стоимость контекста. Но окончательное доказательство для каждой команды появится только на её коде, угрозах и критериях приёмки.