Новый supply chain инцидент: кампания Megalodon за несколько часов протолкнула тысячи вредоносных коммитов в публичные GitHub-репозитории.
Суть атаки простая и опасная: злоумышленники не трогали основной код приложения. Вместо этого они подменяли GitHub Actions workflows - то есть саму CI/CD-инфраструктуру.
В коммитах всё выглядело как рутинная оптимизация пайплайна:
ci: add build optimization step
chore: optimize pipeline runtime
Авторы тоже маскировались под автоматизацию: build-bot, auto-ci, ci-bot, pipeline-bot.
Но внутри workflow лежал base64-encoded bash payload, который при запуске CI вытаскивал чувствительные данные:
• AWS / GCP / Azure credentials
• SSH private keys
• Kubernetes и Docker configs
• Vault и Terraform токены
• .env, credentials.json, service-account файлы
• GitHub Actions OIDC tokens
• API keys, JWT, PEM keys и другие секреты
Почему это важно, потому что CI/CD сегодня это не просто «сборка и тесты». Это точка доступа к облакам, деплою, registry, production-секретам и всей цепочке поставки ПО.
Megalodon показывает неприятную вещь: атакующему не обязательно взламывать приложение. Достаточно незаметно изменить workflow, дождаться запуска пайплайна - и секреты сами уедут наружу.
1. Включена ли branch protection для .github/workflows/*
2. Кто может пушить изменения в CI/CD-конфиги
3. Требуется ли review на изменения workflow-файлов
4. Используются ли минимальные permissions для GITHUB_TOKEN
5. Где включен id-token: write и действительно ли он нужен
6. Нет ли подозрительных коммитов от bot-like авторов
7. Не попали ли секреты в раннеры, логи или артефакты
Защищать нужно не только код и зависимости, но и сам pipeline.
CI/CD - это production-инфраструктура. Относиться к нему нужно соответственно.