Защита CI/CD в open source-проекте, часть 3: учётные данные, верификация и что дальше

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

Отдельно разбор дорожной карты безопасности GitHub Actions на 2026 год и того, как платформенные изменения соотносятся с уже выстроенными контролями. Полезно DevOps- и SRE-инженерам, специалистам по безопасности и мейнтейнерам OSS-проектов. Защита учётных данныхМы исходим из того, что любой отдельный слой может отказать.

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

Если CI-workflow когда-нибудь скомпрометируют, важно, чтобы атакующий не дотянулся до чего-то значимого. Сильные значения по умолчаниюПо умолчанию наши GITHUB_TOKENs ограничены минимальными правами на чтение для contents и packages. Workflow, которым нужно больше, обязаны подключить это явно.

Поэтому workflow, который забыл объявить разрешения, не получает широкого права записи на всю организацию. Мы держим два разных набора учётных данных реестра за отдельными защищёнными окружениями GitHub:Учётные данные CI могут пушить в реестр образов для разработки (quay. io/cilium/*-ci) и доступны CI-сборкам.

Даже если CI-workflow скомпрометируют, этими данными нельзя запушить в продакшен-теги образов. Продакшен-данные лежат за окружением release, и до них workflow доберётся только после явного одобрения мейнтейнера. Ни форк, ни feature-ветка, ни CI-сборка к этим секретам не доберутся.

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

Только релизные сборки по тегу, одобренные мейнтейнером. В худшем случае при компрометации CI атакующий опубликует вредоносный -ci-образ. Но не опубликует в quay.

Этих учётных данных просто нет на раннере. Каждый вызов actions/checkout также ставит persist-credentials: false, поэтому GITHUB_TOKEN никогда не попадает в git config раннера, где его мог бы перехватить более поздний шаг. Подписание и аттестация того, что мы выпускаемКаждый контейнерный образ из релиза (cilium, operator-*, hubble-relay, clustermesh-apiserver) подписан через Sigstore Cosign с keyless (без ключей) OIDC.

Долгоживущих ключей подписи, которые можно украсть, нет. Конвейером подписания управляет переиспользуемое composite-действие:. github/actions/cosign/action.

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