За последние несколько лет CI/CD превратился в главный вход для supply chain‑атак: скомпрометированный билд‑сервер или раннер позволяет незаметно внедрять вредоносный код в артефакты и разносить его по всем средам. Индустрия ответила не только патчами и сканерами, но и сменой парадигмы: «доверять сети» перестало работать, безопасность строится вокруг идентичностей, контекста и минимальных привилегий на каждом шаге пайплайна.
Zero Trust в контексте DevSecOps — это перенос принципа «never trust, always verify» на весь жизненный цикл доставки: разработчики, сервисные аккаунты, раннеры, артефакты, окружения и внешние интеграции постоянно проходят аутентификацию, авторизацию и проверку целостности. Цель этой статьи — не описать идеологию, а собрать практический чек‑лист и приёмы, которые можно завтра внедрить в пайплайны под GitLab и TeamCity.
Принципы Zero Trust в DevOps
Если отбросить маркетинг, Zero Trust в CI/CD сводится к нескольким базовым идеям, которые лучше воспринимать как свойства среды. Не остаётся «доверенных зон»: локальный GitLab, on‑prem TeamCity и приватный VPC больше не считаются безопасным периметром, поэтому каждый запрос из пайплайна к репозиторию, registry, кластеру или секретам должен явно проверяться. На первый план выходит идентичность: важен не IP‑адрес или сетевой сегмент, а то, какой субъект — OIDC‑токен джоба, сервисный аккаунт или робот‑пользователь — выполняет действие и в каком контексте. Принцип минимальных привилегий и сегментации означает, что каждый джоб, раннер и сервисный аккаунт получает только те права и только в тех средах, которые реально нужны для конкретной операции.В 2025‑м Zero Trust‑архитектура уже плотно встроена в практики DevSecOps. Отчёты по индустрии отмечают заметное падение числа инцидентов с несанкционированным доступом у команд, которые перестали относиться к билд‑системе как к «по умолчанию доверенной» и начали строить пайплайны, раннеры и доступ к окружениям через чёткие политики и идентичности.
Доверенные раннеры и секреты
GitLab официально движется в сторону Zero Trust‑архитектуры, смещая контроль доступа с уровня сети на уровень пользователей, устройств и эндпоинтов. В контексте пайплайна это означает, что раннер перестаёт быть «чёрной коробкой с root‑правами» и становится управляемым компонентом с чёткой идентичностью и минимальными привилегиями. Имеет смысл использовать изолированные раннеры на проект или группу вместо одного общего пула, особенно для продуктивных и security‑критичных сервисов, чтобы компрометация одного проекта не давала простой путь к соседям. Джобы, которые работают с продом, секретами и критичными артефактами, выносятся на защищённые раннеры, а запуск таких задач ограничивается защищёнными ветками и одобренными мейнтейнерами.Ключевые практики для GitLab CI:
- Использовать изолированные раннеры на проект/группу вместо одного большого пула, особенно для прод‑ и security‑критичных сервисов.
- Применять защищённые (protected) раннеры и теги для джобов, работающих с продом, секретами и критичными артефактами.
- По максимуму переходить на временные, одноразовые раннеры (ephemeral runners), которые уничтожаются после джоба и не накапливают состояние.
TeamCity: раннеры и уязвимости
Истории с критическими уязвимостями в TeamCity, включая обход аутентификации и удалённое выполнение кода, показали, как единичный дефект в CI‑сервере может превратиться в полноценную supply chain‑атаку. В Zero Trust‑модели важно исходить из допущения, что сервер и build‑агенты могут быть атакованы, а значит, архитектура должна строиться вокруг минимальных прав и жёсткого разграничения. Агентов имеет смысл разделить по уровням доверия: отдельные пулы для разработки, теста и прода с понятными сетевыми правилами между ними, чтобы агент, который собирает pull request, не имел прямого доступа к прод‑кластерам или прод‑секретам. Отказ от одного общего «CI‑user» в пользу отдельных сервисных аккаунтов на проект и окружение помогает упростить аудит и резко уменьшить blast radius при компрометации.Практические рекомендации для TeamCity:
- Разделить build‑агенты по уровням доверия и назначению: отдельные пулы под dev, test и prod с жесткими сетевыми ограничениями.
- Использовать отдельные учётные данные и сервисные аккаунты для каждого проекта и окружения, а не один универсальный «CI‑user».
- Встроить в процессы регулярное обновление TeamCity и агентов плюс автоматический контроль их конфигурации и состояния безопасности.
Secrets: от переменных к управляемым хранилищам
Секреты остаются одной из самых частых точек провала в пайплайнах: токены годами лежат в настройках, одни и те же credentials используются в разных проектах, а чувствительные данные периодически оказываются в логах. В Zero Trust‑подходе ни один секрет не хранится «навсегда» и нигде не считается доверенным только потому, что он уже находится «внутри CI». Базовый уровень гигиены — отказ от долгоживущих секретов в конфигурации пайплайнов и переход на внешние хранилища вроде Vault, облачных секрет‑манагеров или решений на базе KMS, которые выдают временные токены под конкретный джоб. Маскирование переменных и запрет на вывод секретов в логи становятся настройками по умолчанию, а ротация ключей и токенов, особенно для доступа к прод‑ресурсам, превращается в регулярную операционную процедуру.В хорошо спроектированной Zero Trust‑модели каждый джоб получает ровно те секреты, которые ему нужны здесь и сейчас, и только на время выполнения. Он не видит весь список переменных проекта «на всякий случай», не использует одинаковые ключи для разных окружений и не опирается на «вечные» токены.
Политики для артефактов и окружений
CI‑артефакты — образы, пакеты, бинарники — давно стали одним из главных носителей атак: можно внедрить бэкдор на этапе сборки, подменить содержимое в registry или воспользоваться скомпрометированным кэшем. В Zero Trust‑подходе артефакт становится таким же субъектом доверия, как пользователь или сервисный аккаунт: его происхождение должно быть подтверждаемым, а целостность — проверяемой на каждом критичном шаге. Поэтому в конвейере появляется обязательная подпись артефактов и контейнерных образов и проверка этой подписи на этапе деплоя. Дополнительно команды ведут SBOM и запускают SCA‑сканы не только по исходному коду, но и по собранным артефактам, отслеживая уязвимые зависимости в том виде, в каком они реально уходят в прод.Доступ к staging и production перестаёт строиться по принципу «если джоб запустился, ему можно всё». Вводятся явные политики окружений: описывается, какие джобы имеют право деплоить в конкретную среду, из каких веток, с какими типами артефактов и при выполнении каких дополнительных проверок. CI/CD интегрируется с IdP, а access‑tokens к Kubernetes, облачным ресурсам и API выдаются по OIDC‑контексту джоба и автоматически отзываются после выполнения. Для критичных операций появляются ручные гейты: деплой идёт автоматически до определённой точки, а дальше решение о выпуске принимает человек с нужной ролью, формально подтверждая, что контекст деплоя его устраивает.
Мониторинг нарушений и Blue Team
В Zero Trust‑модели мониторинг пайплайна превращается из пассивного сбора логов в постоянный поиск аномалий. Blue Team интересует не только факт деплоя, но и то, кто его инициировал, из какого контекста и с каким набором прав. Подозрительными выглядят прод‑деплои из нетипичных веток, запуски в необычное время, операции от ранее не замеченных пользователей или ботов. Отдельный класс сигналов — попытки джобов обращаться к ресурсам, не описанным в политике для данного пайплайна: неожиданным внешним URL, дополнительным реестрам, неучтённым бакетам и подобным целям.
Практические шаги:
- Инвентаризовать все CI/CD‑инстансы и агенты (включая «теневые» GitLab/TeamCity/Jenkins) и держать их в едином реестре.
- Завести базовые правила корреляции: изменение конфигурации раннеров, появление новых внешних endpoint‑ов для артефактов, необычные права у билд‑сервера, повторяющиеся сбои проверок подписи.
- Регулярно проводить учения в формате purple teaming, моделируя компрометацию раннера, утечку секретов или подмену артефакта и проверяя, какие события реально попадают в мониторинг и к расследованию.
Инструменты, ресурсы и заключение
Zero Trust в пайплайне невозможен без набора инструментов, но это не один «волшебный продукт», а комбинация решений. На уровне идентичности и доступа используются IdP и механизмы выдачи токенов для людей, сервисов и джобов, включая OIDC‑интеграции с GitLab и TeamCity. Поверх этого работают SAST, SCA, контейнерные и инфраструктурные сканеры, встроенные в пайплайн, а также инструменты supply chain‑безопасности — подпись артефактов, управление SBOM и проверка цепочки доверия на этапе деплоя. Зрелые команды выбирают не самый «громкий» бренд, а связку, которая органично ложится на их GitLab‑ и TeamCity‑пайплайны и позволяет описывать политики Zero Trust как код.Отдельного внимания заслуживает SAST как первый фильтр уязвимостей на этапе CI. В статье “Настройка SAST в GitLab Pipeline 2025: готовые конфиги и troubleshooting для production” приведены готовые YAML‑фрагменты и разбор частых ошибок при использовании SAST в крупных репозиториях.
Последнее редактирование:
