Защита CI/CD пайплайнов: как предотвратить компрометацию поставки кода

CI/CD-пайплайны в 2026 году стали главной целью атакующих — и это не преувеличение. За последние два года количество инцидентов, связанных с компрометацией пайплайнов непрерывной интеграции и доставки, выросло на 480% по данным отчёта Google Cloud Threat Horizons. Причина проста: один скомпрометированный пайплайн даёт атакующему доступ к инфраструктуре сборки, подписи кода и деплоя — то есть ко всем downstream-системам, которые доверяют артефактам из этого пайплайна.

Асимметрия этого вектора атаки пугает: злоумышленник вкладывает ресурсы в компрометацию одного звена (build-сервер, GitHub Actions runner, Jenkins-агент), а получает контроль над сотнями и тысячами конечных систем. Атака на SolarWinds в 2020 году, на Codecov в 2021-м, на XZ Utils в 2024-м — это лишь вершина айсберга. В 2025–2026 годах атаки на пайплайны стали массовыми: группировки активно охотятся на CI/CD-инфраструктуру, используя как известные уязвимости, так и методы социальной инженерии против DevOps-инженеров.

В этой статье мы рассматриваем реальные сценарии атак на CI/CD, архитектурные принципы защиты пайплайнов и пошаговые рекомендации для команд, которые хотят предотвратить компрометацию поставки кода. Материал базируется на анализе инцидентов 2024–2026 годов, фреймворке SLSA (Supply-chain Levels for Software Artifacts) и практиках DevSecOps от Google, Microsoft и AWS.

Почему CI/CD пайплайны стали идеальной целью

Традиционная модель безопасности строилась на защите периметра: production-серверы за брандмауэром, базы данных в изолированном сегменте, доступ через VPN. CI/CD-пайплайн ломает эту модель — он по определению имеет доступ к исходному коду, системе сборки, хранилищу артефактов, production-окружению и учётным данным всех трёх этапов. И это делает его идеальной целью для атакующего.

Привилегированное положение CI/CD в инфраструктуре

Build-сервер (раннер GitHub Actions, Jenkins-агент, GitLab Runner) работает с токенами доступа к репозиториям, хранилищам контейнеров, production-серверам, облачным API. Если злоумышленник получает контроль над раннером — он получает все эти токены. Типичная конфигурация: GitHub Actions workflow имеет доступ к {% raw %}${{ secrets.AWS_ACCESS_KEY_ID }}{% endraw %}, {% raw %}${{ secrets.DOCKER_PASSWORD }}{% endraw %} и {% raw %}${{ secrets.KUBE_CONFIG }}{% endraw %} — то есть к трём критическим системам одновременно.

Сложность обнаружения компрометации пайплайна

В отличие от атаки на production-сервер, где аномальная активность (новые процессы, сетевые соединения) видна EDR-системе, компрометация пайплайна происходит на уровне, который редко мониторится. Изменение скрипта сборки выглядит как легитимный коммит. Модификация Dockerfile — как обычное обновление. Добавление вредоносного пакета в зависимости — как рядовая задача разработчика. По данным отчёта ReversingLabs 2026, 73% компрометаций CI/CD остаются незамеченными более 90 дней.

Эффект каскада: одна жертва — тысячи пострадавших

Supply chain через CI/CD — это асимметричная угроза. Пример: атакующий компрометирует open-source библиотеку через её CI/CD-пайплайн. Все downstream-проекты, использующие эту библиотеку в своих сборках, получают вредоносный код. А каждый из этих downstream-проектов может быть использован для атаки на следующий уровень. Так атака распространяется экспоненциально. Инцидент с XZ Utils в 2024 году едва не скомпрометировал миллионы Linux-дистрибутивов именно по этой схеме.

Реальные атаки на CI/CD в 2025–2026 годах

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

1. Компрометация GitHub Actions через скомпрометированный action стороннего разработчика

В августе 2025 года злоумышленники скомпрометировали популярный GitHub Action для деплоя в Kubernetes (скачиваемость: 5 млн+ установок). Модификация была внесена через взлом учётной записи мейнтейнера, который не использовал MFA. Вредоносная версия action отправляла переменные окружения (включая секреты workflow) на C2-сервер. За две недели было скомпрометировано 4 200 репозиториев, использующих этот action. Ущерб — оценивается в $50+ млн. Инцидент привёл к тому, что GitHub ужесточил требования к верификации actions и ввёл обязательный review для популярных action.

2. Атака на self-hosted Jenkins runner в крупной финансовой организации

В марте 2026 года атакующие получили доступ к self-hosted Jenkins-агенту через уязвимость CVE-2025-46235 (RCE в Jenkins Remoting). Сам Jenkins-мастер находился в защищённом сегменте, но агент — на обычной виртуальной машине без изоляции. Получив shell на агенте, злоумышленники собрали все credentials из Jenkins конфигурации, включая SSH-ключи к production-серверам и токен к AWS. Атака была обнаружена через 3 недели после начала — когда production-база данных начала отправлять данные на внешний сервер. Ущерб — $4,2 млн.

3. Dependency confusion в GitLab CI private registry

В ноябре 2025 года злоумышленники использовали dependency confusion-атаку против internal npm-реестра, настроенного в GitLab CI. Внутренний пакет @company/auth-library имел ту же версию, что и публичный пакет в npm registry. Атакующие опубликовали в npm пакет с таким же именем и более высокой версией. CI-пайплайн при сборке скачал вредоносный публичный пакет вместо внутреннего, поскольку GitLab CI был настроен на fallback к публичному регистру. Пакет содержал код, который при сборке изменял production-конфигурацию приложения. Инцидент затронул 12 microservices до момента обнаружения.

4. Подмена артефакта через compromise подписи в GitLab CI

В феврале 2026 года исследователи из NCC Group продемонстрировали атаку на GitLab CI: злоумышленник, имеющий доступ к конфигурации пайплайна, может модифицировать pipeline definition так, чтобы подпись артефакта создавалась от имени легитимного пользователя, но для вредоносного артефакта. Проблема кроется в том, что в большинстве CI-систем подпись артефакта делегируется pipeline runner'у, а не изолированному signing-сервису. Это позволяет атакующему, скомпрометировавшему runner, подписывать любые артефакты.

Архитектура безопасного CI/CD пайплайна

Безопасный CI/CD пайплайн строится на четырёх принципах: изоляция, верификация, минимальные привилегии и наблюдаемость. Рассмотрим каждый принцип в деталях.

Принцип 1. Изоляция окружений сборки

Каждый этап пайплайна (build, test, sign, deploy) должен выполняться в изолированном окружении. Это означает:

• Ephemeral раннеры — каждый билд запускается в одноразовом контейнере или виртуальной машине. Без использования self-hosted runner'ов с persistent storage. GitHub Actions hosted runners, Ephemeral GitLab Runners, AWS CodeBuild — правильный выбор. Self-hosted Jenkins с постоянными агентами — устаревший и опасный подход
• Изоляция по сети — build-раннеры не должны иметь прямого доступа к production-сети. Весь деплой — через промежуточный registry и approval gate. Раннер не должен иметь возможность подключиться к production-базам данных, SSH-серверам или Kubernetes API
• Изоляция по секретам: каждый этап пайплайна получает только те секреты, которые нужны для его работы. Этап сборки не имеет доступа к production-ключам. Этап деплоя не имеет доступа к SCM-токенам

Принцип 2. Верификация на каждом этапе

Любая операция в пайплайне должна верифицироваться:

• Source integrity — каждый коммит, попадающий в пайплайн, должен быть подписан (GPG/Sign-Commits/Sigstore Gitsign). Без подписи — блокировка сборки
• Dependency integrity — все зависимости (npm, pip, Maven, Go modules) должны проверяться hash-суммой из lock-файла. Политика: запретить установку пакетов без hash в lock-файле. Lock-файлы должны быть в репозитории
• Artifact integrity — каждый собранный артефакт (бинарник, container image, wheel-пакет) должен быть подписан cosign/Sigstore перед публикацией в registry
• Deployment integrity — деплой должен проверять подпись артефакта перед развёртыванием. GitOps-подход с верификацией сигнатур в Flux/Argo CD через cosign verification

Принцип 3. Минимальные привилегии для CI/CD

Традиционная ошибка — давать CI/CD-сервису права администратора в production-окружении. Правильная модель:

• Just-in-Time доступ: CI-система получает credentials на время выполнения конкретного пайплайна через Vault (HashiCorp Vault Dynamic Secrets, AWS STS временные токены). После завершения пайплайна credentials автоматически отзываются
• Fine-grained токены: GitHub Fine-Grained Tokens или GitLab Project Access Tokens с минимально необходимыми scope. Никогда не использовать классические Personal Access Tokens с read/write ко всем репозиториям
• Разделение окружений: отдельные service accounts для dev/staging/production. Service account staging не может деплоить в production. Production-деплой требует approval от второго человека

Принцип 4. Наблюдаемость пайплайна

Если вы не видите, что происходит в вашем CI/CD — вы не можете детектировать атаку. Минимальный набор метрик:

• Audit log всех действий: кто изменил pipeline definition, кто зааппрувил деплой, кто добавил новый секрет. GitLab/GitHub предоставляют audit log — включите его и настройте export в SIEM
• Anomaly detection для сборок: неожиданное изменение времени сборки, появление новых сетевых соединений из раннера, попытка доступа к секретам, которые обычно не используются в этом пайплайне
• Runtime security для раннеров: Falco на раннерах для детекта подозрительных системных вызовов. Если раннер неожиданно запускает bash с сетевым соединением — это триггер для SOC
• SLSA Attestations: создание и верификация attestations для каждого этапа пайплайна через in-toto framework. Это даёт криптографически верифицируемую цепочку доказательств, что каждый этап выполнен корректно

SLSA Framework: практическое применение

SLSA (Supply-chain Levels for Software Artifacts, произносится «saltsa») — это фреймворк уровней безопасности для цепочки поставки ПО, разработанный Google при участии OpenSSF. SLSA определяет четыре уровня зрелости — от SLSA 1 (базовый) до SLSA 4 (максимальный). Для CI/CD-пайплайна критическое значение имеют уровни SLSA 2 и выше.

SLSA 1: Требования к источнику

Все изменения версионируются и фиксируются. Репозиторий имеет audit log. Достаточно для внутренних проектов без downstream-потребителей.

SLSA 2: Подпись источника и билда

Коммиты подписаны GPG или Ssigstore. Процесс сборки задокументирован. Артефакты подписаны. Это минимальный уровень для любого open-source проекта, используемого третьими сторонами.

SLSA 3: Доверенный процесс сборки

Build-сервер работает в изолированной среде (это не ваш ноутбук). Сборка идёт из чистой среды (no persistent state). Сборка детерминирована или верифицируема на повторяемость. Build attestation создаётся и подписывается.

SLSA 4: Максимальная зрелость

Build-сервер полностью изолирован, не имеет доступа к сети после завершения сборки. Двусторонняя верификация: build attestation подписывается изолированным signing-сервисом (не тем же runner'ом, который выполнял сборку). Полный audit trail для всего процесса. Используется in-toto для создания и верификации attestations на каждом этапе.

Zero Trust для CI/CD: как не доверять собственному пайплайну

Принцип Zero Trust применим не только к корпоративной сети, но и к CI/CD-пайплайну. Базовые принципы:

• Никогда не доверять раннеру: каждый раннер — потенциально скомпрометирован. Все операции должны верифицироваться signing-сервисом, к которому раннер не имеет доступа
• Никогда не доверять артефакту без верификации: любой артефакт из registry должен проверяться cosign-верификацией перед деплоем. Если подпись не совпадает — деплой блокируется
• Никогда не доверять ветке или автору коммита: CD-система должна требовать approval от второго человека для деплоя в production, независимо от того, кто автор коммита и из какой ветки пришёл PR
• Постоянная верификация: даже после успешного деплоя система мониторинга проверяет, что production-окружение соответствует ожидаемой конфигурации (runtime integrity). Любое отклонение — инцидент

Реализация: пример конфигурации

Рассмотрим, как выглядит Zero Trust CI/CD на практике. Для GitHub Actions:

• Workflow запускается в ephemeral runner от GitHub (не self-hosted)
• Каждый используемый в workflow action имеет verified creator или принадлежит к allowlist
• Secrets хранятся в GitHub Actions Secrets с библиотекой сценариев использования (не все secrets доступны всем workflow)
• Docker-образ собирается с buildx с аттестацией SBOM
• Образ подписывается через cosign + GitHub OIDC (без хранения private ключа в secrets)
• Деплой в production — только после approval от двух senior-инженеров
• Flux/Argo CD проверяет подпись образа перед деплоем через cosign verification
• Runtime integrity: NeuVector или Falco мониторит развёрнутое приложение на предмет отклонений от ожидаемого поведения

Методы защиты: чек-лист для DevOps-команды

На основе анализа реальных инцидентов и лучших практик Google, Microsoft и AWS, приводим практический чек-лист защиты CI/CD пайплайнов.

Организационные меры

• Разделение обязанностей (SoD): инженер, который пишет код, не должен быть единственным, кто аппрувит деплой в production. Минимум 2 approval для production. Для критических проектов — 3
• Принцип четырёх глаз: любое изменение в pipeline definition (workflow-файлы, Dockerfile, Makefile) требует review от второго разработчика. Branch protection в GitHub/GitLab — включить обязательно
• Security Champion в каждой команде: как минимум один разработчик в команде имеет компетенции в CI/CD безопасности и проводит ревью pipeline-конфигураций
• Регулярный пентест пайплайна: минимум раз в квартал. Сценарии: компрометация runner'а, dependency confusion, privilege escalation в CI, доступ к secrets других проектов

Технические меры

• Изолированные ephemeral раннеры: каждый билд — чистый контейнер. Никакого кэша между сборками (или только read-only кэш с верификацией)
• SBOM для каждого артефакта: генерация Software Bill of Materials на этапе сборки через Syft/Trivy. SBOM подписывается и публикуется вместе с артефактом. Для production-артефактов — обязательный экспорт в Dependency-Track
• Sigstore для подписи: cosign + GitHub/GitLab OIDC — стандарт индустрии 2026 года. Никаких hardcoded ключей в CI-системе. Подпись и верификация — на разных сервисах
• Policy-as-Code для пайплайна: Open Policy Agent (OPA) или Kyverno проверяют конфигурацию пайплайна перед запуском: какие actions разрешены, какие secrets доступны каким workflow, какие registry разрешены для публикации артефактов
• Secrets Management: HashiCorp Vault или external secrets operator для Kubernetes. Динамические секреты с TTL. Ротация ключей — автоматическая, каждые 24 часа для production-ключей
• Network Policy для раннеров: раннеры не имеют доступа в интернет (кроме разрешённых registry для скачивания зависимостей). Весь трафик — через egress proxy с фильтрацией URL

Мониторинг и реагирование

• Audit log централизован: логи GitHub Actions / GitLab CI отправляются в SIEM (Splunk, ELK, Sentinel) через webhook или API
• Алерты на аномалии: нестандартное время выполнения пайплайна, обращение к секретам, не используемым в обычном режиме, попытка сборки в нерабочее время
• Incident Response план: сценарий «скомпрометирован пайплайн» отрабатывается отдельно. План включает: блокировку всех деплоев, ревью последних N сборок, ротацию всех credentials, forensic-анализ раннера
• DR для CI/CD: если пайплайн скомпрометирован, должна быть возможность быстро развернуть чистую CI/CD-инфраструктуру из backup-конфигурации. Время восстановления — не более 4 часов

Выводы

CI/CD пайплайн больше не может рассматриваться как вспомогательная инфраструктура — это критический элемент безопасности. Компрометация пайплайна даёт атакующему ключи от всей инфраструктуры: от исходного кода до production-окружения. Асимметрия угрозы требует асимметричного ответа: защита пайплайна должна быть приоритетом №1 для DevOps и DevSecOps команд.

Ключевой вывод из анализа 2025–2026 годов: 91% атак на CI/CD используют не zero-day уязвимости, а ошибки конфигурации. Это означает, что большинство компрометаций можно предотвратить внедрением базовых практик: ephemeral раннеры, подпись артефактов, SLSA framework, Zero Trust для пайплайна и централизованный audit log.

Рекомендуем начать с аудита текущего состояния: какие раннеры используются, как хранятся секреты, подписываются ли артефакты перед деплоем. Следующий шаг — внедрение SLSA 2 как минимального уровня (подпись коммитов и артефактов). Затем — переход к SLSA 3 с изолированными build-окружениями и полной наблюдаемостью пайплайна. Защита CI/CD — это не разовый проект, а непрерывный процесс улучшения.

📚 Читайте также

• Почему уязвимости ИИ-приложений так часто критичны: анализ и практика защиты
• Безопасность кода, написанного ИИ: риски и практики защиты приложений
• Уязвимости в ИИ-приложениях: каждая третья угроза оказалась критической
• Prompt-инъекции через README: как GitHub-документация атакует ИИ-агентов
• Prompt Injection и безопасность ИИ-агентов: атаки на цепочку поставок кода

📖 Термины

CI/CD · Devsecops · OWASP · SBOM · Supply Chain Attack

🔗 Источники

• GitGuardian — CI/CD Security Best Practices 2026
• Google Cloud Threat Horizons Report 2026 — анализ угроз для CI/CD
• SLSA Framework — Supply-chain Levels for Software Artifacts
• Sigstore — Open Source Signing Service для подписи артефактов
• Xakep.ru — Атаки на CI/CD пайплайны в 2025–2026