Поскольку многие разработчики используют агентские инструменты для создания большего объема кода быстрее, чем когда-либо прежде, сам код стал сложнее, а на поиск и устранение программных уязвимостей уходит больше времени.
Помощь в решении этой проблемы является одной из главных задач Google. Мы знаем, что скорость разработки ПО растет — вплоть до 2x for some teams, а среднее время устранения уязвимостей разработчиком увеличилось примерно с 59 дней десятилетие назад до более чем 170 дней в 2025 году, согласно отчету Mandiant M-Trends 2026.
Чтобы помочь вам защитить больший объем кода и сделать это быстрее, мы создали CodeMender — нашего автономного агента безопасности кода, способного находить и исправлять программные уязвимости со скоростью машины.
Мы также понимаем, что инструменты для разработчиков эффективны только тогда, когда они вписываются в привычные процессы. Именно поэтому CodeMender, входящий в состав нашей платформы AI Threat Defense, переносит автоматизированные исправления кода прямо в рабочий процесс разработчика. Сегодня мы публикуем эту справочную архитектуру, которая встраивает автоматизированное исправление с помощью CodeMender прямо в pull-запросы Git через Google Cloud Run.
Что видит разработчик
Все происходит в хронике (timeline). Сканирование публикует один комментарий: таблицу найденных проблем, где у каждой проблемы есть ID, а также две команды, которые можно ввести следующим сообщением.
Рисунок 1: Pull-запрос запускает сканирование в Cloud Run. Результаты проверки, следы эксплойта и предлагаемые патчи возвращаются в ту же хронику.
Ответьте /verify 612424da, и в ветке появится попытка эксплойта, скрытая в сворачиваемом блоке View Exploit Steps & Response Trace, чтобы не захламлять обсуждение.
Ответьте /fix 612424da, и патч придет тем же способом под кнопкой Preview Proposed Code Diff, а черновик pull-запроса уже готов к /approve. Обе команды принимают all вместо конкретного ID.
Рисунок 2: Первоначальный комментарий сканирования содержит таблицу найденных проблем и доступные слеш-команды, позволяя разработчику не покидать хронику pull-запроса.
Ничто не заставляет разработчика покидать pull-запрос или разбираться с консолью.
Предоставляйте доказательства, а не просто степень критичности
Результаты выполнения команды cm find CodeMender включают оценку достоверности уязвимости, полученную во время анализа кода. Если оценка достоверности ниже 100%, вы можете использовать команду cm verify, чтобы заставить CodeMender собрать и смоделировать эксплойт в изолированной среде (песочнице) и определить, действительно ли уязвимость эксплуатируема.
Результаты симуляции могут изменить уровень критичности. Поскольку песочница проверки существует недолго, конвейер автоматически передает эти артефакты в Google Cloud Storage для сохранения контрольного журнала (audit trail) в целях соответствия требованиям и проверок безопасности.
Рисунок 3: Команда /verify возвращает трассировку попытки эксплойта в песочнице, предоставляя проверяющим конкретные доказательства вместо абстрактных предупреждений.
Учитывайте возможные сбои в конвейере проверки. Если ваш тестовый шаблон ищет только строку успешного эксплойта, то любой сбой теста — например, падение макетного сервера (mock server) или превышение времени ожидания выполнения — может привести к тому, что конвейер пропустит уязвимость и ошибочно назовет реальную проблему безопасной.
Убедитесь, что ваш парсер отделяет истинно отрицательные результаты от сбоев тестов. Если эксплойт не удается выполнить корректно, пометьте статус как неопределенный, вместо того чтобы выдавать ему свидетельство о безопасности.
Предложите патч, просмотрите diff
Когда эксплойт доказывает реальность проблемы, следующим шагом становится не тикет, а патч: команда cm fix a1b2c3d4 дает указание CodeMender создать его.
Рисунок 4: Команда /fix возвращает унифицированный diff кода, предоставляя проверяющим содержательный контекст для оценки патча.
Если diff выглядит хорошо, для его применения требуется всего один шаг. Разработчик отвечает /approve. Агент фиксирует патч в ветке, отправляет его в репозиторий и устанавливает статус проверки commit status security/codemender-gate в положение «зеленый». Именно защита веток превращает этот статус в блокировку слияния; без нее этот допуск носит лишь рекомендательный характер.
Никаких сохраненных ключей между GitHub и Cloud Run
Ничего из этого не произойдет, пока GitHub и Google Cloud не начнут доверять друг другу. Этому агенту нужен доступ на запись к вашему исходному коду — именно те учетные данные, которые вы меньше всего хотите хранить в хранилище секретов в ожидании утечки. Вместо этого GitHub Actions может создавать недолговечный токен OIDC, а Google может быть настроен на его прием, благодаря чему в системе не останется долгоживущих данных, которые можно было бы украсть.
Практически вся безопасность здесь держится на одной строке:
Каждый рабочий процесс GitHub Actions использует этот URL издателя, поэтому простая проверка издателя ничего вам не дает. Всю работу выполняет условие.
Обратите внимание, по какому признаку идет сопоставление. assertion.repository здесь тоже сработал бы, но он сопоставляется с именем, а имена меняются или могут быть захвачены кем-то другим после того, как вы их освободите. repository_id и repository_owner_id неизменяемы, поэтому Google рекомендует сопоставлять именно их.
Предоставьте эксплойту безопасное место для запуска
Проверки запускают атакующий код, который никто не рецензировал, написанный по требованию, направленный на макетную цель и делающий то, что подразумевает класс уязвимости. Как недавно напомнили всем заголовки новостей, последнее, чего вы хотите — это чтобы автономный агент решил, что самый быстрый способ выполнить задачу — это вырваться из контейнера и просканировать порты вашей внутренней сети.
Прежде чем доверять вердикту, нужно ответить на два важных вопроса: где выполняется этот код и к чему он может получить доступ во время выполнения? Ответ заключается в том, чтобы запустить его как задание Cloud Run.
Каждый экземпляр Cloud Run изолирован, а задания всегда выполняются в среде выполнения второго поколения — microVM с полной совместимостью с Linux. Выполнение начинается, выполняется одно действие и завершается.
Рисунок 5: Эксплойт запускается в экземпляре, который ничего не хранит и существует ради одной уязвимости. Наружу передается только вердик.
Затем очистите пространство. Предоставьте заданию собственную учетную службу и не давайте ей ничего, кроме API, который записывает эксплойт. Ему не нужен доступ к реестру, поскольку Cloud Run импортирует образ контейнера при развертывании, а не подтягивает его при запуске экземпляра.
Откажитесь от учетной записи Compute Engine по умолчанию, которая в зависимости от политики вашей организации может содержать роли/редактор. Лишите его и сети: прямой выход через VPC в подмаршрут без выхода наружу означает, что код, не имеющий доступа ни к какому внешнему ресурсу, не сможет ни выгрузить то, что он найдет, ни загрузить второй этап атаки.
Запускайте одно задание на каждую найденную уязвимость. Выполнение заканчивается, экземпляр уничтожается вместе с ним, и только вердикт переживает их оба.
Изоляция Cloud Run или изоляция агентов закрывают последнюю брешь. Внутри экземпляра выполнение процессов изолировано от родительской рабочей нагрузки, ее переменных среды, ее секретов и сервера метаданных Google Cloud, поэтому учетные данные, выдаваемые платформой по умолчанию, также недоступны. Все это создано специально для агентов, выполняющих только что написанный ими код.
Начните работу уже сегодня
Вы можете создать автономного агента безопасности GitOps уже сегодня. Начните с эталонной реализации на codemender-gitops.
- Безопасность и идентификация
