CI/CD сегодня — это сердце любой современной разработки. Jenkins, GitHub Actions, GitLab CI — без них релизить в продакшен с человеческой скоростью и безопасностью невозможно. Но там, где автоматизация, там и уязвимости. В руках хакера CI/CD превращается в золотую жилу: стоит пробиться в пайплайн, и можно вытянуть ключи от продакшена, токены доступа и вообще всё, чем живёт инфраструктура.

Где ломается Jenkins

Jenkins — старичок с огромной экосистемой плагинов. Уязвимости чаще всего рождаются именно там:

• Misconfiguration: если Jenkins открыт во внешний мир без аутентификации или с дефолтными паролями — всё, приехали.
• Script Console: при наличии админ-прав атакер получает интерактивный Groovy-скриптовый шелл прямо в нутрянке Jenkins.
• Secrets in Env Variables: токены, ключи AWS, SSH-ключи часто хранятся как “Secret Text” в Jenkins и пробрасываются в пайплайны. Доступ к билду = доступ к секретам.
  Часто забывают ограничить видимость этих переменных — и злоумышленник с правом «build job» может спокойно напечатать их в логах.

Где горит GitHub Actions

GitHub Actions — модная платформа, но тоже с сюрпризами:

• Pull Request Injection: если репозиторий принимает внешние PR, атакер может подсунуть злой workflow, триггернув его выполнение от имени CI.
• GITHUB_TOKEN: у Actions всегда есть автоматический токен для работы с репозиторием. Если у него стоят слишком жирные права, можно нагенерить себе доступ к артефактам или даже влить код в прод.
• Secrets in Steps: секреты в secrets.* легко утекут, если бездумно делать echo $SECRET в логах. А логи в GitHub — это общий доступ для тех, у кого есть права на Actions.

Типичный сценарий атаки

1. Перехват входа в CI: Jenkins с дырой в плагине или GitHub Actions с PR-инъекцией.
2. Вытягивание переменных окружения: токены, креды, ключи доступа к S3 или Docker Registry.
3. Доступ к продакшену: через SSH-туннель, kubectl или Terraform с этими ключами.

Как итог — атакеру не нужен “взлом сервера”. Достаточно “взлома девопса”.

Как строить защиту

• В Jenkins:
• закрывать Script Console для всех, кроме избранных;
• использовать Role-based security;
• хранить секреты в HashiCorp Vault, а не в Jenkins;
• не светить переменные окружения в логах.
• В GitHub Actions:
• убирать авто-запуск Actions для external PR (или запускать их в безопасном sandbox без секретов);
• ограничивать права у GITHUB_TOKEN (Least Privilege);
• секреты хранить в GitHub Secrets, но никогда не дампить их в логи;
• мониторить коммиты на утечки через gitleaks/trufflehog.

🔥 Вывод хардкорщика:
CI/CD — это фактически корень доверия. Пробой здесь = полный захват всего проекта. История про “угон ключей” — не страшилка, а ежедневная практика, когда компании допускают банальные конфиги-косяки.

Задача разработчика и девопса — строить пайплайны так, чтобы даже если атакер получил доступ в систему сборки, он не смог вынести секреты наружу.

На этом все. Всем хорошего дня!