Коротко: ИИ-агент для поиска уязвимостей полезен как часть конвейера, но его сообщение и даже патч нельзя принимать за доказательство исправления. Надёжный допуск требует воспроизвести атаку несколькими входами, подтвердить достижимость уязвимого пути, устранить корневую причину, сохранить корректное поведение на безопасных данных и только затем разрешить слияние человеку.
Статья предназначена для CTO, CISO, руководителей разработки, AppSec- и DevSecOps-команд. Она разбирает проверку исходного кода и автопатчей; не оценивает конкретный продукт, не обещает найти все уязвимости и не заменяет ручной анализ критичных компонентов.
Содержание
- Что показал контур Google
- Почему высокая точность не равна полноте защиты
- Где автопатч проходит тест, но оставляет риск
- ПАТЧ: четыре доказательства исправления
- Минимальный эксперимент: один PoC против корневой проверки
- Как встроить ИИ-сканер в CI/CD
- Метрики для решения о масштабировании
- Ограничения доказательств
- Частые вопросы
- Как AI Рассвет помогает построить проверяемый контур
- Вывод
Что показал контур Google
18 сентября 2026 года Google описала внутренний агентный конвейер защиты инфраструктурного кода. Он сканирует каждое изменение до слияния в кодовую базу объёмом в сотни миллионов строк, а ночью повторно ищет проблемы, возникающие на пересечении нескольких изменений. По заявлению Google, контур предотвращает попадание в код или production сотен уязвимостей в месяц.
Ключевая архитектурная деталь — не один универсальный агент, а разделённые роли:
- быстрый агент ищет потенциальную проблему в небольшом diff;
- специализированный triage-агент проверяет структуру программы через AST, граф вызовов и доменные правила;
- более глубокая ночная проверка ищет межкомпонентные эффекты;
- агент исправления предлагает патч и демонстрационный фрагмент;
- человек рассматривает изменение вместе с исходным code review.
Google сообщает о более 92% precision triage-агента и времени проверки менее одной минуты. Для отдельных конфигураций локальные threat models снизили false-positive rate до 3%. Эти цифры важны, но описывают только наблюдавшиеся условия и метрики Google. Они не раскрывают recall, распределение по типам уязвимостей, абсолютное число проверок или долю патчей, сохранивших всю бизнес-логику.
Публичный репозиторий Mantis подтверждает модульную схему: построение threat model, поиск гипотез, дедупликация, triage, воспроизведение, patching и adversarial verification. Одновременно README предупреждает, что модели недетерминированы, могут выдумывать находки и ошибочные патчи; результаты должен проверять специалист, а запускать harness следует только в изолированной среде без доступа к production и чувствительным данным.
| Этап | Что он подтверждает | Чего ещё не подтверждает |
|---|---|---|
| находка агента | код похож на опасный паттерн | путь достижим и эксплуатируем |
| структурный triage | существует путь по структуре программы | атака работает в реальной конфигурации |
| воспроизводящий пример | конкретный вход вызывает эффект | найдена корневая причина и все варианты |
| патч | исходный пример больше не срабатывает | соседние атаки закрыты, функция сохранена |
| тесты и human review | проверен заявленный набор свойств | устранены все неизвестные уязвимости |
Практический вывод: ИИ-сканер — генератор и проверяющий гипотез, а не автоматический сертификат безопасности.
Почему высокая точность не равна полноте защиты
Precision отвечает на вопрос: какая доля поднятых сигналов оказалась истинной. Recall отвечает на другой: какую долю всех существующих уязвимостей система нашла. Можно получить высокую precision, если сообщать лишь об очевидных проблемах, и пропустить редкие, но критичные классы.
Фраза «false-positive rate 3%» также требует знаменателя. Это может быть доля ложных сигналов среди всех предупреждений, среди безопасных изменений или внутри одного выбранного класса. Без определения метрики, выборки и порога значение нельзя переносить на другую кодовую базу.
NIST IR 8397 рекомендует не одну технику, а набор: threat modeling, автоматические тесты, статический анализ, проверки встроенных защит, black-box и структурные тесты, исторические кейсы, fuzzing, web scanners и анализ зависимостей. NIST SSDF 1.1 дополнительно связывает secure development с исправлением обнаруженных проблем и устранением причин их повторения.
Для закупки или пилота полезно запросить не общий accuracy, а матрицу:
| Вопрос | Минимальное доказательство |
|---|---|
| Что система находит? | CWE/классы риска, языки, фреймворки, версии |
| Сколько шума создаёт? | precision и нагрузка на reviewer по критичности |
| Что она пропускает? | recall на скрытом наборе и перечень blind spots |
| Работает ли атака? | воспроизводимый exploit/PoC в изоляции |
| Исправлен ли корень? | несколько независимых атакующих входов и анализ data/control flow |
| Не сломан ли продукт? | unit, integration, property и semantic regression tests |
Где автопатч проходит тест, но оставляет риск
Свежая работа PatchBench показывает, почему одного PoC недостаточно. Авторы собрали 213 задач по patching из 32 реальных проектов и 16 типов CWE, затем проверили 11 агентов. В среднем 83,1% сгенерированных патчей останавливали исходный PoC, но только 45,3% задач проходили одновременно security- и semantic-validation. Проверка одним PoC завышала solve rate в 1,83 раза.
Исследование выявило два разных shortcut:
- в среднем 25% агентных патчей были существенно похожи на исторические исправления разработчиков, поэтому высокий результат мог отражать запоминание публичного патча;
- агент часто ставил guard в месте падения, а не исправлял причину раньше по data flow, превращая crash в тихую ошибку.
В PatchBench лучшие агенты проходили более 97% исходных PoC, но после нескольких атакующих входов и семантической проверки решали примерно половину задач. У 67 задач не справился ни один из 11 агентов. Это предварительный arXiv-препринт по C/C++ и выбранным проектам, а не универсальная оценка любого коммерческого сканера, но он хорошо отделяет «перестало падать» от «исправлено безопасно».
ПАТЧ: четыре доказательства исправления
Предлагаем рамку ПАТЧ. Это оригинальная синтезация AI Рассвет на основе контура Google, PatchBench и рекомендаций NIST; это не официальный стандарт источников.
П — путь атаки
Зафиксируйте source, sink, условия достижимости, привилегии и конфигурацию. Статический сигнал без достижимого пути остаётся гипотезой. Но отсутствие автоматического воспроизведения тоже не доказывает ложное срабатывание: среда могла не смоделировать нужное состояние.
А — атакующие варианты
Проверяйте не один опубликованный PoC, а семейство входов: изменённое кодирование, границы, альтернативные протоколы, параллельность и соседние пути. Fuzzing и property-based tests уменьшают шанс, что патч просто распознал конкретную строку.
Т — точка причины
Сопоставьте место проявления с местом возникновения дефекта. Guard рядом с crash может скрыть симптом. В отчёте должны быть root cause, изменённый invariant и объяснение, почему исправление перекрывает весь класс входов.
Ч — человеческий допуск и целевая функция
Проверьте безопасные входы, unit/integration tests, output state и бизнес-инварианты. Security test доказывает отсутствие одного опасного эффекта; semantic test — что полезная функция не удалена. Финальный merge для критичного кода разрешает человек, который видит оба набора доказательств.
Карточка допуска патча может выглядеть так:
| Поле | Содержимое |
|---|---|
| target | репозиторий, commit, build, зависимости |
| threat | CWE, attacker capability, asset, impact |
| path | source → transforms → sink и условия достижимости |
| attacks | исходный PoC, варианты, fuzz corpus, negative cases |
| root cause | нарушенный invariant и место исправления |
| semantics | безопасные входы, unit/integration, output comparison |
| review | владелец, reviewer, решение, исключения, expiry |
Минимальный эксперимент: один PoC против корневой проверки
Мы провели детерминированную демонстрацию на функции чтения файлов. Уязвимая версия позволяла выйти из разрешённой директории. «Поверхностный» патч блокировал строку ../, а корневой патч разрешал доступ только после канонизации пути и проверки его принадлежности доверенному каталогу.
Набор содержал 5 случаев: исходный traversal-PoC, абсолютный путь, выход через symbolic link и два безопасных чтения. Поверхностный патч получил 3/5: остановил исходный PoC и сохранил два нормальных сценария, но пропустил абсолютный путь и symlink escape. Корневая проверка получила 5/5.
Это не benchmark ИИ-агента, не анализ production-кода и не доказательство превосходства конкретного алгоритма. Демонстрация показывает узкую вещь: положительный результат одного PoC совместим с сохранённой уязвимостью, а набор должен одновременно включать варианты атаки и разрешённое поведение. Воспроизводимый скрипт сохранён в исследовательских артефактах статьи.
Как встроить ИИ-сканер в CI/CD
1. Начните с ограниченного класса риска
Выберите один язык, сервис и 2–4 класса уязвимостей с понятным oracle: например, path traversal, command injection или SSRF. Не начинайте с обещания «сканировать всё».
2. Разведите генерацию, triage и допуск
Агент поиска не должен единолично подтверждать собственную находку. Используйте отдельные правила, структурный анализ или другой агент для triage; разрешение merge оставьте policy gate и reviewer.
3. Изолируйте воспроизведение
Запускайте с минимальными правами, без production credentials и внутренней сети. Ограничьте файловую систему, сеть, процессное дерево, время и бюджет. Сохраняйте все команды и tool calls.
4. Требуйте два набора тестов
Security-набор должен включать исходный PoC и варианты. Semantic-набор — безопасные входы и бизнес-инварианты. Патч не проходит gate, если закрывает атаку ценой отключения функции.
5. Сохраняйте доказательства, а не только комментарий
К issue приложите commit, threat model, воспроизводящий пример, root-cause note, журналы, версии инструментов, результаты до/после и решение человека. Тогда повторную проверку можно выполнить после смены модели или harness.
6. Вводите по уровням автономности
Первый режим — комментарий без изменения кода. Второй — draft patch без merge. Третий — автоматический PR с обязательным reviewer. Автослияние допустимо только для заранее ограниченного класса, где независимые проверки устойчиво подтверждены на скрытом наборе.
Метрики для решения о масштабировании
Не сводите пилот к числу найденных багов. Минимальная панель должна различать качество, труд и остаточный риск.
| Метрика | Формула или единица | Зачем |
|---|---|---|
| precision | подтверждённые / все поднятые сигналы | нагрузка на reviewer |
| recall на скрытом наборе | найденные / все известные уязвимости | пропуски |
| exploit reproduction rate | воспроизведённые / подтверждённые | сила evidence trail |
| robust patch rate | security + semantic pass / предложенные патчи | качество исправлений |
| reviewer minutes | минуты на находку и патч | операционная стоимость |
| escaped defects | уязвимости после gate на единицу изменений | остаточный риск |
| rollback/regression rate | откаты или дефекты после автопатча | цена неверного исправления |
Сравнивайте эти показатели с текущим процессом на одинаковом scope. «Сотни предотвращённых уязвимостей» без числа проверенных изменений, severity и baseline не дают переносимого ROI.
Ограничения доказательств
- Цифры Google — first-party описание внутренней инфраструктуры; метод выборки, recall и полные denominators не опубликованы.
- Значения «сотни миллионов строк» и «сотни уязвимостей в месяц» приблизительны и не доказывают причинный эффект только ИИ.
- 92% precision и 3% false-positive rate относятся к заявленным условиям Google; «в некоторых случаях» не означает среднее по всем языкам и классам риска.
- Публичный Mantis назван демонстрационным toolkit, не поддерживаемым production-продуктом Google; его README требует изоляции и ручной проверки.
- PatchBench — arXiv-препринт по C/C++, 213 задачам и 11 агентам; результаты не являются рейтингом всех моделей, языков или частных репозиториев.
- Локальная демонстрация 3/5 против 5/5 проверяет пять заранее объявленных файловых случаев, а не качество ИИ, сканера или production-патча.
- Российская производственная точность, recall, стоимость, время review, снижение инцидентов и ROI не наблюдались.
Search volume, keyword difficulty, позиции, traffic, CTR, backlinks и AI citations также Unknown. Статья описывает критерии допуска, а не прогноз поискового или коммерческого результата.
Частые вопросы
Может ли ИИ-сканер заменить AppSec-инженера?
Нет. Он может расширить охват и ускорить triage, но критичные находки требуют контекста архитектуры, оценки impact, проверки патча и принятия остаточного риска человеком.
Что важнее: precision или recall?
Обе метрики. Низкая precision перегружает команду ложными сигналами, низкий recall оставляет уязвимости незамеченными. Порог выбирают по severity и стоимости пропуска.
Достаточно ли, что исходный PoC больше не работает?
Нет. PoC подтверждает только один вход. Нужны варианты атаки, проверка корневой причины и тесты корректного поведения на безопасных данных.
Можно ли автоматически сливать патчи низкого риска?
Только в узко определённом scope после проверки на скрытом наборе, с независимыми security- и semantic-gates, журналированием, rollback и ограниченным blast radius.
Зачем разделять агентов поиска и triage?
Разделение снижает риск самоподтверждения: другой контур проверяет достижимость, структуру и правила, не повторяя тот же свободный вывод генератора.
С чего начать пилот небольшой команде?
Выберите один репозиторий и один класс риска, соберите 20–50 исторических и синтетических кейсов, замерьте текущий baseline, запустите режим «только комментарии» и считайте reviewer minutes вместе с precision и recall.
Как AI Рассвет помогает построить проверяемый контур
AI Рассвет может помочь связать ИИ-агента с существующим процессом разработки без неподтверждённых обещаний безопасности:
- описать scope, baseline, threat model и acceptance criterion для одного класса риска;
- интегрировать поиск, triage, sandbox и журналы в CI/CD;
- подготовить security- и semantic-наборы, policy gate и маршрут human review;
- провести ограниченный MVP, зафиксировать метрики и обучить команду разбирать доказательства.
Первый шаг — выбрать один репозиторий, класс уязвимости, текущий baseline и критерий допуска по рамке ПАТЧ. Обсудить задачу.
Вывод
Свежий опыт Google показывает, что ИИ может встроить поиск и исправление уязвимостей в каждое изменение кода. Но переносимая ценность создаётся не названием модели, а разделением ролей, локальным threat model, структурным triage, изоляцией, проверкой нескольких атак и человеческим решением.
Рабочая последовательность такова: найти гипотезу → доказать путь → воспроизвести семейство атак → исправить корень → проверить безопасное поведение → разрешить merge → наблюдать регрессии. Если патч прошёл только исходный PoC, он доказал, что научился отвечать на один тест, а не то, что устранил уязвимость.