В последние недели в сфере DevSecOps наметилась тревожная тенденция: сочетание AI-агентов и пост-установочных скриптов превращается из удобного инструмента в реальную угрозу. Случай с Gemini CLI — яркий тому пример. Ситуация, когда обновление до версии с доверительной моделью (trust model) вызвано критической уязвимостью CSS CVE уровня 10.0, заставляет задуматься о безопасности внедряемых решений.

Сразу оговоримся: использование AI для ревью пул-реквестов — это, безусловно, благо. Автоматизированный анализ изменений, оценка долга кода, рекомендации — такие инструменты снижают нагрузку на разработчиков. Но когда в этих же инструментах появляется брешь, вся конструкция рушится как карточный домик.

Возьмём для примера крупную организацию вроде Red Hat, которая активно использует Gemini для ревью PR. Хорошая практика? Безусловно. Но что произойдёт, если в самом Gemini обнаружится уязвимость? Чтобы выполнить ревью внутри CI, необходимо использовать Gemini CLI в так называемом «YOLO-режиме». Этот режим спроектирован специально для headless-запусков в CI/CD и по определению позволяет CLI выполнять произвольные команды в системе. Звучит уже не так безобидно, правда?

Механизм атаки: безобидный JSON-файл как троянский конь

Теперь посмотрим на settings.json. Это совершенно обычный, легитимный конфигурационный файл, определяющий поведение агента. Вы можете включить Vim-режим, выбрать GitHub-тему или указать набор инструментов для запуска внутри Docker-песочницы. На первый взгляд — ничего подозрительного. Но в классической традиции CLI-тулов здесь присутствуют хуки. Один из них — before_agent, который выполняется после отправки промпта, но до начала планирования работы агента. Этот хук может быть командой, например, security_check, способной выполнить произвольный код на системе.

Проблема возникает в момент пул-реквеста. Кто контролирует код в PR? В лучшем случае — вы, в худшем — злоумышленник. До того как уязвимость была исправлена, хакер мог отправить вредоносный пул-реквест, содержащий специально сформированный settings.json. Далее срабатывал GitHub workflow (как в примере с Red Hat — компания не была взломана, но такая конфигурация вполне реальна), который запускал Gemini PR review. Этот workflow выполняется при открытии PR, и злоумышленник получал возможность запустить любые команды внутри CI/CD раннера от имени организации. Итог — извлечение токенов, API-ключей и любых секретов, доступных в окружении раннера.

Team PCP и растущий тренд компрометации CI/CD

Упомянём также группировку Team PCP — threat actor, стоящий за большинством крупных атак на цепочки поставок за последние месяцы. Под удар попали такие инструменты, как LightLLM, Trivy, Check Marks (инструмент анализа состава ПО) и Telnyx. Все эти инциденты объединяет одно: источником компрометации стал скомпрометированный CI/CD пайплайн. В марте этого года Team PCP использовала уязвимость в AquaBot для атаки на репозиторий Trivy action, а затем — компрометацию GitHub action в самой Aqua Security, что привело к каскадным последствиям для зависимых проектов.

Прослеживается тревожный паттерн: компании внедряют современные инструменты разработки и даже следуют хорошим практикам безопасности, но из-за неверных допущений о степени доверия к коду, выполняемому внутри пайплайна, возникают критические уязвимости. CI/CD раннеры (как хостившиеся на GitHub, так и self-hosted) по умолчанию доверяют тому коду, который запускают. Если злоумышленник получает возможность выполнить свой код в таком раннере — например, через описанную выше уязвимость Gemini CLI — и при этом внутри раннера доступны не защищённые должным образом переменные окружения, то утечка базы данных или API-ключей становится лишь вопросом времени.

Что делать? Принцип «всё скомпрометировано»

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

  1. Изоляция процессов. Если вы используете self-hosted раннеры, не полагайтесь на то, что всё окружение одинаково привилегированно. Примените стандартную Linux-модель прав: создайте отдельных пользователей для разных процессов. Тогда даже при захвате одного процесса злоумышленник не получит автоматически доступ к учётным данным другого.

  2. Правильная песочница. Docker — хороший способ ограничить зону поражения. Но убедитесь, что контейнеры не запускаются от root. Это отдельная большая тема, но если вы всё ещё это делаете — самое время пересмотреть подход.

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

Что сделал Google и как обновляться

Хорошая новость: Google оперативно выпустил исправления. В новых версиях введён флаг --trust-workspace, который по умолчанию отключён. Если вы абсолютно уверены, что ваши PR поступают только от доверенных коллабораторов, вы можете включить эту опцию вручную. Однако более безопасный путь — обновить версию GitHub Actions для запуска Gemini CLI до v3.9.1 или v0.40-preview.3. Именно в этих версиях конфигурационные файлы из рабочего пространства по умолчанию не рассматриваются как доверенные.

Важный нюанс: многие разработчики закрепляются (пинят) на конкретную версию Gemini CLI. Все версии, предшествующие указанным выше, подвержены описанной уязвимости. Поэтому простого обновления workflow недостаточно — необходимо явно повысить pin до исправленной версии. Проверьте свои CI/CD конфигурации прямо сейчас.

Ситуация с Gemini CLI — не единичный казус, а симптом системной проблемы. По мере внедрения AI во все этапы разработки мы будем всё чаще сталкиваться с тем, что «безобидный» конфиг или «удобный» хук становится вектором атаки. Принцип «доверяй, но проверяй» здесь не работает — правильнее «не доверяй ничему, но проверяй ещё строже». И да, обновите свои пайплайны, если ещё этого не сделали.