Защита CI/CD для open source-проекта: запираем зависимости

Вот важная новость с фронта ИИ: levashove 5 минут назад Защита CI/CD для open source-проекта: запираем зависимости 7 мин 92 Блог компании VK Tech DevOps * Информационная безопасность * Open source * Управление разработкой * Перевод Автор оригинала: André Martins и Feroz Salam Команда VK Cloud перевела второй пост из серии трёх частей о том, как Cilium укрепляет свой CI/CD-конвейер. Первая часть рассказывала про управление доступом: кто может запускать сборки и какой CI-код разрешено исполнять. Этот пост про уровень зависимостей: какой код эти сборки подтягивают и как мы убеждаемся, что его не подделали.

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

Технические детали

Каждая директива uses: в файлах workflow ссылается на action'ы по полному 40-символьному коммит-SHA, а человекочитаемую версию мы указываем комментарием:- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6. 2Если кто-то скомпрометирует тег v6 и сделает force-push вредоносного кода, workflow его не подтянут: они запиннованы к конкретному коммиту. Это работает для каждого стороннего action'а: docker/build-push-action, sigstore/cosign-installer, golangci/golangci-lint-action и десятков других.

Контейнерные образы, которые шаги workflow используют напрямую, мы пиннуем так же по @sha256:-дайджесту. У пиннинга есть одно слепое пятно — транзитивные зависимости. Когда вы пиннуете actions/checkout@de0fac2e…, код этого action'а известен точно.

Но если сам actions/checkout ссылается на другой action по тегу (uses: some-org/some-helper@v1), это разрешение происходит во время выполнения и остаётся невидимым. Атакующий, который скомпрометирует вложенную зависимость, всё ещё может добраться до конвейера. Исправление на подходе: блокировку зависимостей на уровне workflow анонсировали в дорожной карте безопасности GitHub Actions на 2026 год.

Отраслевые последствия

Она добавит в YAML workflow секцию dependencies, которая запирает все прямые и транзитивные зависимости-action'ы по коммит-SHA аналогично паре go. Мы возьмём её на вооружение, когда она выйдет. Автоматизированные обновления с границей доверияПоддерживать SHA-пины руками непрактично, поэтому мы этого не делаем.

Конфигурация Renovate расширяет пресет helpers: pinGitHubActionDigests и глобально выставляет pinDigests: true. Когда выходит новая версия action'а, Renovate открывает PR с поднятым SHA — это позволяет проекту оставаться актуальным и не возвращаться к изменяемым ссылкам. Renovate работает как self-hosted бот по часовому расписанию и использует выделенное GitHub App с тонко настроенными разрешениями вместо персонального access token'а.

Включён vulnerabilityAlerts, так что известные CVE в дереве зависимостей сразу превращаются в PR'ы.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.