В 2025 году атакующие компрометировали GitHub-репозитории через инъекцию в workflow-файлы, POST-запросами отправляя credentials на внешние эндпоинты. Ноль эксплойтов на CVE, ноль обхода EDR - хватило украденных developer credentials и права на коммит в
.github/workflows/. Эта цепочка воспроизводится одинаково против GitHub Actions, GitLab CI и Azure DevOps. Детектируется в большинстве организаций только постфактум - когда утёкшие токены всплывают на даркнет-форумах. По сути, YAML-файл в репозитории сейчас опаснее открытого порта.Зачем атакуют безопасность DevOps инфраструктуры
Типичный deployment workflow одновременно хранит AWS credentials, npm publish tokens, Docker Hub passwords, deploy keys и GitHub token с write-правами. Атакующая поверхность - не сервер с уязвимым портом, а YAML-файл в репозитории. Одна модификация этого файла открывает доступ ко всем секретам сборочной среды. Подробнее - в нашем руководстве по атаки на цепочку поставок.Цепочка атаки укладывается в четыре шага: украденные developer credentials → модифицированный workflow → сбор CI-секретов → латеральное перемещение в облако и продакшн. По данным исследований в области software supply chain security, число вредоносных open-source пакетов растёт год к году - счёт идёт на сотни тысяч новых выявленных компонентов ежегодно. Каждый - потенциальная точка входа в пайплайн.
Финансовый импакт разрушителен. Codecov (2021): атакующие получили доступ к CI-среде и экcфильтровали данные тысяч клиентов через компрометацию одного bash-скрипта в build-процессе. При компрометации репозитория Trivy (Aqua Security) утечка затронула значительное число секретов и машин. Оборотные штрафы по 152-ФЗ за утечку персональных данных не делают исключений для «инфраструктурных» инцидентов - регулятору безразлично, произошла утечка через продакшн-сервер или через скомпрометированный build pipeline.
OWASP выделяет 10 рисков для CI/CD (проект OWASP Top 10 CI/CD Security Risks): от CICD-SEC-1 (Insufficient Flow Control Mechanisms) до CICD-SEC-10 (Insufficient Logging and Visibility). На практике инциденты концентрируются вокруг трёх вещей: кража секретов, отравление пайплайна и подмена зависимостей.
Атаки на CI/CD пайплайны: реальные кейсы и TTPs
Кража секретов - Unsecured Credentials (T1552, Credential Access)
Самый прямолинейный вектор. Атакующий с доступом к репозиторию модифицирует workflow, добавляя строки, которые экcфильтруют переменные окружения и секреты через HTTP-запросы. Место в kill chain: credential access → lateral movement → persistence в облаке.Массовые кампании используют injected workflow-файлы, которые POST-ом отправляют credentials на внешние эндпоинты. NPM-червь Shai-Hulud пошёл дальше: он автоматически собирал GitHub Personal Access Tokens через
gh auth token, запускал TruffleHog для разведки секретов в репозитории и использовал скомпрометированные токены для инъекции вредоносного кода в другие пакеты того же разработчика. Результат первой волны - сотни опубликованных малициозных пакетов. Красивая цепочка: один PAT → TruffleHog → все пакеты автора под контролем.Работает если: у атакующего есть write-доступ к репозиторию (через фишинг, утечку PAT, компрометацию SSO-сессии); секреты доступны через переменные окружения в CI-шагах. Не работает если: секреты передаются через OIDC без long-lived tokens; workflow-файлы защищены branch protection + CODEOWNERS; изменения в
.github/workflows/ требуют обязательного ревью.Что искать для detection по OWASP CICD-SEC-6 (Insufficient Credential Hygiene): появление новых
env: секций в workflow-diff, обращения к secrets.* из ранее не использовавших их jobs, сетевые вызовы (curl, wget, python requests) в build-шагах, которых там раньше не было.Supply chain атаки на CI/CD через Poisoned Pipeline Execution (T1195, Initial Access)
Poisoned Pipeline Execution (PPE) - атака, при которой злоумышленник модифицирует определение пайплайна для выполнения вредоносного кода в CI-среде. По классификации OWASP - CICD-SEC-4. Место в kill chain: initial access → execution → credential access.Самый опасный триггер в GitHub Actions -
pull_request_target. В отличие от обычного pull_request, он запускает workflow в контексте базового репозитория с доступом к секретам, но может выполнять код из недоверенного форка. Злоумышленники систематически сканируют публичные репозитории на наличие именно этой мисконфигурации - это, по сути, автоматизированная охота. Среди задокументированных техник эксплуатации: poisoned Go init() functions, инъекция через имя ветки или имя файла, прямая инъекция скриптов. В тяжёлых случаях - полная компрометация репозитория с downstream supply chain атакой.Второй вектор - мутабельные ссылки на actions. Использование
actions/setup-node@main вместо SHA-пиннинга позволяет атакующему модифицировать action-репозиторий и получить выполнение кода во всех downstream workflow. Тут даже write-доступ к целевому репо не нужен - достаточно скомпрометировать action.Работает если: публичный репозиторий с
pull_request_target в workflow (для PPE через форк); или write-доступ к action-репозиторию без SHA-пиннинга. Не работает если: все actions привязаны по SHA256; pull_request_target отключён или ограничен условием if: github.event.pull_request.head.repo.full_name == github.repository.Закрепление и маскировка после initial access
После получения initial access через PPE или кражу credentials атакующие переходят к закреплению и маскировке. Два приёма из реальных инцидентов:Command and Scripting Interpreter (T1059, Execution). В CI/CD всё построено на скриптах - bash, PowerShell, Python. Атакующий добавляет вредоносные команды в build-скрипты, Makefile, Dockerfile или
package.json (секция scripts). Паттерн curl | bash - выполнение удалённого скрипта без проверки целостности - распространён как в легитимных, так и в малициозных конфигурациях. Это и делает detection сложным без контекста: половина CI-пайплайнов в дикой природе тоже так делает. По данным OWASP CI/CD Cheat Sheet, remote script execution должен быть явно запрещён политикой безопасности.Работает если: pipeline выполняет скрипты без sandboxing, runner имеет сетевой доступ к внешним ресурсам, отсутствует content trust для скачиваемых артефактов. Не работает если: runner изолирован от внешней сети, все зависимости загружаются из внутреннего artifact registry, применяется allow-list для сетевых вызовов в CI.
Timestomp (T1070.006, Defense Evasion). Атакующие манипулируют временными метками коммитов, чтобы вредоносные файлы выглядели старыми и доверенными. Техника задокументирована в ряде APT-кампаний - бэкдейтированные коммиты могут ссылаться на инфраструктуру, которая не существовала на указанную дату (хороший индикатор, кстати). Для detection актуальны Sigma-правила:
posh_ps_timestomp.yml (модификация временных меток через PowerShell) и proc_creation_lnx_touch_susp.yml (подозрительное использование touch в Linux). В контексте CI/CD - несоответствие между датой коммита и датой создания аккаунта контрибьютора.Detection: аудит безопасности CI/CD-событий в SIEM
Корреляция событий для защиты GitLab CI и Jenkins
Частая проблема SOC-команд: CI/CD-логи либо не собираются в SIEM, либо собираются без корреляционных правил. По OWASP CICD-SEC-10 (Insufficient Logging and Visibility) это типовой gap, и он присутствует даже в организациях с «зрелым» SOC. Я регулярно вижу эту картину: Elastic стоит, правила написаны, а pipeline-логи туда просто не льются.Минимальный набор событий для мониторинга:
| Событие | Источник | На что указывает | ATT&CK |
|---|---|---|---|
| Изменение workflow/pipeline-файла | Git webhook, SCM audit log | PPE, начало атаки | T1195 |
Новый secrets.* в diff workflow | CI diff analysis | Подготовка к краже секретов | T1552 |
| Сетевые вызовы (curl/wget/POST) в build job | CI runner logs | Exfiltration | T1552 |
Добавление permissions: write-all | Git diff | Расширение blast radius | T1195 |
| Переназначение job на self-hosted runner | CI config change | Runner targeting | T1195 |
| Коммит с аномальным timestamp | Git log analysis | Defense evasion | T1070.006 |
| Изменение visibility репозитория | SCM audit log | Подготовка к supply chain | T1195 |
Для Jenkins: включите аудит через Audit Trail Plugin, направьте логи в SIEM. Ключевые события -
/configure, /configSubmit, изменение числа executors, добавление новых nodes. В GitLab: активируйте Audit Events API - project_changed_audit_event, pipeline_schedule_created, repository_setting_changed.Для автоматизации detection - многоступенчатый подход: фильтрация и diff файлов по CI-relevant путям → извлечение regex-сигналов из каждого diff → контекстный анализ с учётом автора и коммит-метаданных → алертинг и блокировка PR. Для SOC без ресурсов на сложную интеграцию первые два этапа (regex-сигналы по diff) реализуемы средствами SIEM - и уже покрывают основные векторы.
Контрмеры по D3FEND: D3-SWI (Software Inventory) для отслеживания CI/CD-компонентов, D3-AVE (Asset Vulnerability Enumeration) для зависимостей, D3-FIM (File Integrity Monitoring) для контроля целостности pipeline-конфигов.
Insider threat: скомпрометированный разработчик
Отдельная категория, которую часто игнорируют, - скомпрометированный аккаунт разработчика. Атакующий действует от имени доверенного сотрудника, и стандартные ACL бесполезны - по логам всё выглядит как легитимная работа. Именно поэтому baseline поведения тут критичен.Detection-сигналы для SIEM:
- Изменения в workflow-файлах от аккаунта, который ранее не трогал CI-конфигурацию (baseline нарушен)
- Коммит в workflow вне рабочего времени или с нетипичного IP/геолокации
- Первый коммит нового контрибьютора содержит модификацию CI/CD-файлов
- Несоответствие между временем коммита и возрастом аккаунта (специализированные detection-инструменты оценивают account age, contribution history и org membership как часть author trust assessment)
- Появление
id-token: writeв permissions workflow от аккаунта, который ранее не работал с OIDC
Харденинг CI/CD: чеклист для аудита безопасности
Нумерованный чеклист - можно брать и передавать в DevOps/SRE-команду или включать в отчёт по аудиту:Пункты 1, 2 и 5 адресуют CICD-SEC-3 (Dependency Chain Abuse) и CICD-SEC-4 (PPE). Пункты 4, 9 - CICD-SEC-6 (Insufficient Credential Hygiene). Пункт 8 - CICD-SEC-10 (Insufficient Logging).
DevSecOps-команды часто прикручивают SAST/DAST/SCA в пайплайн - и считают, что с безопасностью CI/CD разобрались. Нет. Защита кода, проходящего через CI/CD, не равна защите самого CI/CD. Когда я разбираю результаты аудитов сборочных сред, картина повторяется: секреты в переменных окружения без ротации годами, actions по тегам без SHA-пиннинга, self-hosted runner'ы с persistent state и SSH-ключами от продакшна. Атакующему не нужен 0-day - достаточно одного скомпрометированного аккаунта с write-доступом к репозиторию, и supply chain под контролем. OWASP выпустил отдельный проект Top 10 CI/CD Security Risks не для галочки - это систематизация реальных инцидентов в компаниях с «зрелыми» DevOps-процессами. Мой прогноз: в ближайший год CI/CD pipeline abuse станет самостоятельной категорией в threat intelligence отчётах, отдельно от generic supply chain. Сейчас это серая зона, где SOC не имеет playbook'ов, а DevOps не считает pipeline security своей зоной ответственности. По свежим инцидентам этого типа коллеги на codeby.net разбирают detection-кейсы на регулярной основе.
