В 2025-2026 годах описан класс атак на AI-агентов в GitHub Actions: вредоносный комментарий в pull request заставлял агентов - Copilot, Gemini CLI, Claude Code - сливать secrets, включая API-ключи и
GITHUB_TOKEN, прямо в публичные логи workflow. Ноль взаимодействия от мейнтейнера, ноль срабатываний SAST-правил. Я воспроизвёл этот сценарий на изолированном стенде с LangChain-агентом, подключённым к GitHub API через repo-scope токен - от создания issue до коммита вредоносного кода в main прошли секунды. Branch protection не спас: агент имел право создавать PR и мержить через автоматический approval. Ниже - полный kill chain атаки на agentic AI пайплайны в CI/CD, с конкретными CVE, рабочими payload-ами и маппингом на MITRE ATT&CK.Бизнес-логика атаки: зачем атакующему AI-агент в CI/CD
[Применимо: любая организация с AI-агентами в GitHub Actions / GitLab CI/CD, внешний вектор] Подробнее - в нашем материале про безопасность llm приложений.Классический supply chain attack через CI/CD требует либо компрометации мейнтейнера (credential theft), либо внедрения в зависимость (dependency confusion). Оба вектора - серьёзные усилия и время.
AI-агент в пайплайне открывает другой путь. Атакующий не ломает инфраструктуру - он разговаривает с ней. Indirect prompt injection через публичный issue - это initial access с нулевыми привилегиями. Создать issue в публичном репозитории может любой аккаунт GitHub.
Импакт определяется привилегиями, которые наследует AI-агент от workflow:
GITHUB_TOKENс write-доступом - создание коммитов, управление релизами, модификация workflow-файлов- Secrets окружения - API-ключи облачных провайдеров, ключи подписи пакетов, credentials для container registry
- Bash/shell доступ - прямое выполнение команд в runner-среде
pull_request_target без явного ограничения permissions, GITHUB_TOKEN получает права на чтение содержимого репозитория, создание коммитов и управление релизами. Один украденный токен из популярного open-source проекта - supply chain compromise на всё время жизни токена. Поэтому атаки на agentic AI пайплайны интересуют не только исследователей, но и реальных threat actors.Kill chain: от публичного issue до захвата AI workflow
Полная цепочка компрометации CI/CD через LLM - пять шагов. Каждый маппится на MITRE ATT&CK:
- Resource Development - T1588.007 (Artificial Intelligence). Атакующий изучает workflow-файлы целевого репозитория - они публичны в
.github/workflows/. Определяет, какие AI-агенты используются, какие триггеры активны (issues,issue_comment,pull_request), какие secrets доступны. - Initial Access - T1195.002 (Compromise Software Supply Chain). Атакующий создаёт issue или PR-комментарий с embedded prompt injection payload. Единственное активное действие со стороны атакующего.
- Execution - T1059.006 (Python). AI-агент обрабатывает untrusted input, интерпретирует вредоносные инструкции как задачу и выполняет shell-команды через свой toolset.
- Credential Access - T1552.001 (Credentials In Files). Агент вытягивает secrets из переменных окружения, конфигурационных файлов или runner environment и публикует их в доступном атакующему месте - заголовке issue, комментарии PR или логах workflow.
- Defense Evasion - T1685 (Disable or Modify Tools). Атакующий может инструктировать агента подчистить следы - удалить логи, подправить результаты security review (отдельно от галлюцинаций scoring pipeline, описанных в разделе OWASP LLM09:2025).
issues, агент получает тело issue, прогоняет через LLM и выполняет инструкции. Мейнтейнер увидит результат спустя часы - когда токены уже утекли.Indirect prompt injection в GitHub Actions: механика атаки
Как untrusted input попадает в промпт агента
Типичный workflow с AI-агентом для автоматического триажа issues, задокументированный Aikido Security в исследовании PromptPwnd, передаёт данные из issue напрямую в промпт:
YAML:
env:
ISSUE_TITLE: '${{ github.event.issue.title }}'
ISSUE_BODY: '${{ github.event.issue.body }}'
prompt: |
Analyze this issue:
Title: "${ISSUE_TITLE}"
Body: "${ISSUE_BODY}"
Атакующий создаёт issue с безобидным заголовком и телом, содержащим скрытые инструкции для LLM. По OWASP LLM01:2025 (Prompt Injection) - классический indirect prompt injection: вредоносные инструкции доставляются не напрямую, а через данные, которые LLM обрабатывает в рамках штатной работы. Отличие от standalone LLM-приложений принципиальное: здесь агент имеет реальные привилегии в инфраструктуре.
По данным Aikido, типичный AI-агент в GitHub Actions имеет доступ к инструментам вроде
run_shell_command(gh issue edit) и run_shell_command(gh issue list). Если RCE не проходит - можно экcфильтровать secrets, заставив агента изменить заголовок issue на значение переменной окружения с токеном. Результат - в открытом доступе.По данным CSA и Aikido Security, эксплуатабельность вектора подтверждена против нескольких AI-агентов в GitHub Actions, включая Claude Code, Gemini CLI и Copilot. Исследователи отправляли PR-комментарии с injected инструкциями - агенты честно интерпретировали и выполняли их, раскрывая secrets через публично доступные PR-комментарии или логи Actions.
Два свойства GitHub Actions делают этот вектор особенно злым по сравнению с атаками на standalone AI-агентов. Во-первых, workflow автоматически триггерятся на события
pull_request, issues и issue_comment без какого-либо действия мейнтейнера - жертва не читает, не кликает и не аппрувит. Во-вторых, GITHUB_TOKEN без явных ограничений permissions тащит за собой привилегии на чтение содержимого репозитория, создание коммитов и управление релизами.Предусловия и ограничения
Работает если:- Workflow использует AI-агента (Copilot Agent, Gemini CLI, Claude Code, OpenAI Codex) для обработки issue/PR
- Untrusted input (
github.event.issue.body,github.event.pull_request.body, commit messages) вставляется в промпт без санитизации - Агент имеет доступ к secrets через переменные окружения и доступ к shell-инструментам
- Workflow триггерится автоматически на
issues,issue_commentилиpull_request_target
- Workflow не обрабатывает untrusted input через LLM (детерминированная логика)
- AI-агент изолирован в sandbox без доступа к shell и secrets
- Используются жёсткие
permissionsdeclarations с минимальным scope - Input проходит через rule-based фильтрацию до попадания в промпт
CVE и реальные supply chain инциденты
Уязвимости AI пайплайнов в AI-инструментах
CVE-2025-62222 - GitHub Copilot Chat (CVSS 8.8, HIGH). Command injection в расширении VS Code CoPilot Chat - несанкционированный атакующий выполняет код по сети. CWE-20 (Improper Input Validation) и CWE-77 (Command Injection). Вектор:AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - полная триада под угрозой.https://nvd.nist.gov/vuln/detail/CVE-2025-65099
CVE-2025-65099 - Claude Code (CVSS 7.7, HIGH, CVSS 4.0). До версии 1.0.39 мог выполнять код из yarn-плагинов проекта до того, как пользователь принял диалог доверия при запуске. CWE-94 (Improper Control of Generation of Code). Вектор CVSS 4.0:
AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H - атака по сети, низкая сложность, но нужно действие пользователя (запуск Claude Code в недоверенной директории при наличии Yarn 3.0+). Исправлено в 1.0.39.Атаки покрывают широкий спектр целей - от system discovery до credential theft и data exfiltration.
CVE-2025-30066 - tj-actions/changed-files (CVSS 8.6, HIGH). CWE-506 (Embedded Malicious Code). Затронуто более 23 000 репозиториев.
CVE-2025-30154 - reviewdog/action-setup (CVSS 8.6, HIGH). CWE-506. Компрометация 11 марта 2025, 18:42-20:31 UTC. Затронуты также reviewdog/action-shellcheck, reviewdog/action-composite-template, reviewdog/action-staticcheck, reviewdog/action-ast-grep. Добавлен в CISA KEV 24 марта 2025.
По данным CSA, полная цепочка атаки на tj-actions началась за несколько месяцев до видимой компрометации: по разборам Wiz и Unit 42, атака шла через компрометацию смежного проекта (spotbugs/sonar-findbugs), утечку maintainer PAT и последующий lateral movement через reviewdog до самого tj-actions. Одна ошибка конфигурации workflow - и вот вам масштабный supply chain инцидент.
AI-инструменты как явная цель атаки
По данным CSA, компрометация Nx build system в августе 2025 целенаправленно искала credentials AI-инструментов: Claude Code, Gemini CLI, Amazon Q. Атакующие использовали тот факт, что AI coding tools хранят authentication tokens в предсказуемых путях файловой системы. AI-инструменты уже рассматриваются threat actors не просто как вектор, а как цель для credential access (T1552.001).Маппинг на OWASP LLM Top 10 и NIST AI RMF
Атаки на agentic AI пайплайны пересекают сразу несколько категорий OWASP LLM Top 10 2025:| OWASP ID | Название | Проявление в CI/CD |
|---|---|---|
| LLM01:2025 | Prompt Injection | Issue body / PR comment как вектор indirect injection |
| LLM06:2025 | Excessive Agency | AI-агент с repo write + shell access + secrets |
| LLM07:2025 | System Prompt Leakage | Workflow-файлы публичны - system prompt агента доступен для recon |
| LLM09:2025 | Misinformation | Галлюцинации scoring pipeline дают ложные результаты security review |
По NIST AI RMF 1.0, функция MAP (контекст, среда развёртывания) требует включить AI-агент как объект risk assessment. На практике так делают единицы - workflow пишутся как автоматизация, а не как attack surface. Unit 42 подтверждает: уязвимости prompt injection в agentic-приложениях framework-agnostic, зашиты в архитектурные паттерны CrewAI, AutoGen и LangChain, а не в код конкретных библиотек.
Харденинг AI-пайплайнов: чеклист для безопасности AI агентов
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Многие agentic frameworks - LangChain, AutoGen, CrewAI - не реализуют санитизацию tool output по умолчанию. Те же design flaws (prompt injection через tool output, excessive agency, отсутствие валидации межагентных сообщений) сидят не только в production-агентах, но и в самих инструментах тестирования - парадокс, где сканер безопасности уязвим к атакам, которые он призван находить.
Я вижу закономерность: команды, внедряющие AI-агентов в CI/CD, повторяют ошибку десятилетней давности с Jenkins - наделяют автоматизацию максимальными привилегиями "чтобы всё работало". Разница в том, что Jenkins выполнял детерминированный код, а LLM-агент выполняет то, что ему скажут - включая вредоносные инструкции из публичного issue.
Индустрия пока не выработала стандарт безопасной интеграции LLM в пайплайны. OWASP LLM Top 10 описывает риски, NIST AI RMF даёт фреймворк, но между теорией и реальным workflow-файлом - пропасть. Google закрыла уязвимость Gemini CLI за четыре дня после disclosure. Microsoft подтвердила CVE-2025-62222. Архитектурная проблема при этом никуда не делась: любой агент с bash-инструментом и доступом к secrets, обрабатывающий untrusted natural language input, уязвим by design.
Мой прогноз - в ближайший год мы увидим волну supply chain инцидентов через AI-агентов в CI/CD. Не потому что атакующие стали умнее, а потому что поверхность атаки растёт быстрее зрелости защитных мер. CVE-2025-30066 затронула 23 000 репозиториев без всякого AI - добавьте к этому агента, который сам обрабатывает untrusted input и сам выполняет команды, и масштаб другой. Если хочется посмотреть как injection-цепочка разворачивается end-to-end - на HackerLab.pro (http://hackerlab.pro) в web-категории есть задачи, где подобную механику нужно собрать самостоятельно.
Последнее редактирование модератором: