Как закрыть цепочку поставки в CI/CD

CI/CD-конвейер давно стал частью production-периметра. Через него проходят токены, сборочные артефакты, релизы, контейнерные образы и доступ к package registry. Поэтому безопасность pipeline упирается в два вопроса: кто может запустить сборку и какой код эта сборка подтянет во время выполнения.

Даже строго ограниченный workflow остаётся уязвимым, если он ссылается на изменяемые теги, свежие пакеты без задержки, внешние action’ы с транзитивными зависимостями и модули, которые скачиваются в момент сборки. Надёжная схема строится вокруг закрепления версий, автоматизированных обновлений, ревью diff’ов и статического анализа конфигураций.

GitHub Actions стоит пиннить по SHA

Первый слой защиты — отказ от плавающих ссылок в uses:. Запись вида actions/checkout@v6 удобна для чтения, но тег остаётся изменяемым объектом. При компрометации аккаунта сопровождающего или force-push в тег pipeline может получить другой код при следующем запуске.

Более безопасный вариант — указывать полный commit SHA:

- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Комментарий сохраняет человеку понятную версию, а runner скачивает конкретный коммит. Такой же подход применим к сторонним action’ам для Docker, Cosign, линтеров, релизных утилит и любых вспомогательных шагов. Контейнерные образы в workflow также лучше фиксировать по @sha256: digest, чтобы сборка зависела от конкретного слоя вместо обновляемого тега.

У SHA-пиннинга есть слабая зона: транзитивные зависимости action’ов. Если закреплённый action внутри вызывает другой action по тегу, это разрешение происходит уже во время выполнения. Значит, базовый контроль стоит дополнять аудитом action’ов, ограничением доверенных поставщиков и готовностью перейти на lock-файлы для workflow, когда такая возможность станет доступна в GitHub Actions.

Обновления должны проходить через контролируемого бота

Ручное обновление десятков SHA быстро превращается в долг, поэтому пиннинг нужно связывать с автоматизацией. Renovate умеет поднимать digest’ы GitHub Actions и контейнерных образов, открывать pull request с изменением конкретных ссылок и держать зависимости актуальными без возврата к плавающим тегам.

Для такой автоматизации важна граница доверия. Бот должен работать через отдельное GitHub App с минимальными разрешениями вместо персонального token разработчика. PR от бота можно проверять по автору, инициатору события и ожидаемому набору изменённых файлов. Авто-апрув допустим только для строго определённых источников и только после прохождения CI.

Полезная практика — задержка обновлений. Если новый релиз пакета или action’а опубликован несколько часов назад, безопаснее дать экосистеме время заметить явную компрометацию. В Renovate это задаётся через minimumReleaseAge, например пять дней для major, minor и patch обновлений. Такой cooldown снижает риск подхватить вредоносный релиз в первые минуты после публикации.

Allow-list для автослияния должен быть явным: официальные action’ы GitHub и Docker, собственная организация, Kubernetes SIGs, Go, Prometheus, HashiCorp, etcd и другие доверенные пространства имён. Всё за пределами списка уходит на человеческое ревью. Такой режим сохраняет скорость для рутинных обновлений и оставляет ручную проверку для менее предсказуемых зависимостей.

Go-модули выгодно переносить во время ревью

Для Go-проектов отдельный риск связан с тем, что сборка может скачать модуль из внешнего proxy в момент выполнения. go.mod и go.sum фиксируют версии и checksums, но решение о доверии всё равно часто переносится в runtime сборки. Вендоринг меняет модель: дерево зависимостей попадает в репозиторий, а изменения видны в pull request.

CI может проверять согласованность go.mod, go.sum и vendor/. Если разработчик добавил новый модуль, diff покажет не только строку в manifest, но и фактический код, который войдёт в сборку. Это особенно полезно против опечаточных пакетов, неожиданных транзитивных зависимостей и незаметной подмены источника.

Для крупных проектов стоит добавить CODEOWNERS на vendor/ и назначить отдельную группу ревьюеров. Они смотрят на новые пути импорта, лицензии, размер дерева и причину добавления библиотеки. Некоторые зависимости разумно исключить из автоматических обновлений: компоненты с координированными релизами, внутренние форки, библиотеки с проектными патчами и модули, влияющие на совместимость API.

Периодический аудит зависимостей тоже даёт практический эффект. Если библиотека нужна ради небольшой helper-функции, несколько строк локального кода могут быть безопаснее постоянной внешней зависимости. Чем меньше дерево, тем проще ревью, быстрее сборка и ниже вероятность supply chain инцидента.

Форки не всегда окупаются

Иногда возникает идея форкнуть все сторонние action’ы и модули в собственную организацию. Для очень чувствительных систем это может быть частью модели безопасности, но операционная цена высокая. Форки нужно синхронизировать с upstream, отслеживать security-fix’ы, обновлять workflow и поддерживать отдельный контур Renovate.

SHA-пиннинг уже даёт важное свойство: workflow получает конкретный коммит. Если upstream скомпрометирован после выбранного commit SHA, закреплённая сборка не изменится сама. Форк становится разумной эскалацией для особенно рискованных поставщиков или после повторяющихся инцидентов, но универсальный форк всего дерева часто создаёт больше сопровождения, чем защиты.

Статический анализ ловит ошибки в workflow

Даже хорошая политика со временем ломается из-за мелких правок. Кто-то добавляет новый workflow без permissions:, использует ubuntu-latest, вставляет shell-команду с небезопасной подстановкой или забывает имя job. Эти ошибки лучше останавливать до ручного ревью.

CodeQL для GitHub Actions может падать на workflow, где не выставлены явные permissions. Для задач без записи подходит permissions: read-all или permissions: {}. Для релизов и подписи артефактов права стоит задавать точечно: contents: write, id-token: write и только там, где они реально нужны.

actionlint дополняет эту проверку: валидирует синтаксис YAML, выражения GitHub Actions, небезопасные паттерны и проектные соглашения. Через него удобно запретить плавающий ubuntu-latest, требовать имена для job и step, ловить trailing spaces и подозрительные конструкции в run:.

Особое внимание нужно уделить injection через ${{ }}. Значения из pull request title, branch name или issue body подставляются в YAML до запуска shell. Если такой ввод попадает прямо в run:, атакующий может протащить ;, $(...) или backticks. Безопаснее сначала передавать недоверенное значение в переменную окружения, а в shell использовать quoted form: "$MY_VAR". Это выглядит как мелочь, но именно такие детали часто обходят человеческое ревью.

Минимальный набор для практического внедрения

Для небольшого open source или homelab-проекта можно начать с компактного baseline:

заменить все uses: org/action@v1 на полный commit SHA с комментарием версии;
закрепить контейнерные образы в CI по sha256 digest;
включить Renovate для digest updates и добавить задержку публикации;
разрешить automerge только для доверенного allow-list и только после CI;
вендорить Go-зависимости или как минимум проверять diff manifest’ов и lock-файлов;
добавить CODEOWNERS для критичных зависимостей и workflow;
включить CodeQL/actionlint для .github/workflows;
явно задавать permissions в каждом workflow;
убрать прямую подстановку недоверенных ${{ }} в shell.

Такая схема повышает защиту pipeline и переводит большинство решений о доверии из момента выполнения в pull request. Это главное улучшение: изменения становятся видимыми, проверяемыми и воспроизводимыми. CI/CD перестаёт быть чёрным ящиком, который каждый раз скачивает новый внешний код, и превращается в управляемый контур с понятными границами доверия.