root Компрометація CI/CD та репозиторіїв: методи атак, ризики та стратегії захисту
У сучасному світі DevOps та автоматизованих систем розгортання CI/CD-процеси (Continuous Integration та Continuous Deployment) стали фундаментом розробки програмного забезпечення. Вони дозволяють мінімізувати людські помилки, прискорити розробку, забезпечити стабільність релізів та досягти високого рівня гнучкості. Проте саме CI/CD сьогодні є однією з найбільш привабливих цілей для атакувальників. Компрометація репозиторіїв або пайплайнів відкриває шлях до вставки шкідливого коду, викрадення секретів, підміни залежностей і навіть повного захоплення інфраструктури.
Ця стаття є глибоким аналітичним матеріалом щодо атак на CI/CD та репозиторії. Ми розглянемо їхню природу, причини, механізми, реальні приклади та сучасні методи захисту, рекомендовані провідними експертами кібербезпеки.
1. Що таке компрометація CI/CD та репозиторіїв
Компрометація CI/CD — це форма supply-chain атаки, у якій зловмисник отримує несанкціонований доступ до систем автоматичної інтеграції та розгортання або до кодових репозиторіїв. Мета атакувальника — вплинути на процеси розробки, отримати доступ до конфігурацій, змінити вихідний код або отримати контроль над середовищем, у якому працює виробничий продукт.
Компрометація репозиторіїв, у свою чергу, дозволяє атакувальнику виконувати такі дії:
- вставляти шкідливий код у основні гілки
- підміняти залежності
- видаляти або змінювати історію комітів
- викрадати SSH-ключі, токени, паролі
- маніпулювати pull request’ами
2. Чому CI/CD та репозиторії — найбільш привабливі цілі для атаки
Ось кілька ключових причин, чому атакувальники активно шукають вразливості саме у цих системах:
- Доступ до повної кодової бази. Репозиторії містять критично важливий код та конфігурації.
- Привілеї системи. CI/CD часто має доступ до продакшен-середовищ.
- Секрети. У пайплайнах зберігаються токени, ключі API, SSH і паролі.
- Автоматизація. Будь-яка внесена зміна автоматично поширюється на всі середовища.
- Нестача контролю. Залежності, скрипти та конфігурації часто не проходять належний аудит.
Якщо CI/CD компрометовано, атакувальник фактично отримує доступ до всього життєвого циклу розробки — від коду до серверів.
3. Основні типи атак на CI/CD
Атакувальники застосовують широкий спектр технік, спрямованих на різні частини CI/CD-ланцюга. Розглянемо найпоширеніші методи.
3.1. Компрометація акаунтів розробників
Це один із найпопулярніших способів. Зловмисник отримує доступ до GitHub/GitLab/Bitbucket-акаунту через:
- фішинг
- викрадення токенів OAuth
- бракування паролів (weak password policies)
- використання повторюваних паролів
Після цього він може:
- змінювати вихідний код
- створювати шкідливі коміти
- публікувати компрометовані версії продукту
3.2. Атакування CI-агентів
CI-агенти — це машини, які виконують скрипти збірки та тестування. Якщо зловмисник отримує доступ до агента, він може:
- викрасти секрети, доступні агенту
- змінювати артефакти збірки
- розповсюджувати бекдори
У багатьох компаній CI-агенти працюють у тому ж середовищі, що й продакшен, що значно збільшує ризики.
3.3. Компрометація пайплайнів через шкідливі конфігурації
Файли .gitlab-ci.yml, github/workflows/*.yml, Jenkinsfile містять інструкції, які виконуються автоматично. Вразливі конфігурації можуть дозволити виконання довільного коду при створенні pull request або навіть при відкритті issue.
3.4. Викрадення або витік секретів
CI/CD часто зберігає:
- SSH-ключі
- токени деплою
- паролі до БД
- ключі cloud-провайдерів
Якщо атакувальник отримує доступ до них, він може проникнути у всю інфраструктуру.
3.5. Підміна артефактів
Артефакти — це результат збірки. Вони можуть бути змінені на шкідливі, якщо:
- сховище артефактів не захищене
- комунікація між агентами незахищена
Підміна артефактів — один із найнебезпечніших типів атак, оскільки шкідливий код потрапляє безпосередньо у продакшен.
3.6. Атаки через PR — Pull Request Hijacking
У популярних системах CI/CD пайплайни часто запускаються при кожному pull request. Якщо attacker прикріплює скрипт або payload у PR, він може отримати доступ до секретів, які пайплайн автоматично передає для перевірки.
3.7. Атаки на інфраструктуру CI/CD
Це включає:
- використання вразливостей у Jenkins
- атаки на слабкі API-tokenи GitHub Actions
- компрометацію GitLab через RCE
- експлуатацію old-версій TeamCity
Цей тип атак один із найнебезпечніших, оскільки дозволяє атакувальнику керувати системою DevOps повністю.
4. Атаки на репозиторії: методи та сценарії
4.1. Несанкціоновані коміти або пуші
Якщо атакувальник отримує доступ до акаунту розробника або ключів Git, він може пушити зміни напряму у важливі гілки, що призводить до:
- вставки бекдорів
- підміни залежностей
- впровадження вразливостей
4.2. Компрометація Git hooks
Зловмисник може модифікувати скрипти:
post-commitpre-pushpost-checkout
Це дозволяє автоматично виконувати шкідливі дії при роботі з репозиторієм.
4.3. Підробка pull request
Соціальна інженерія може призвести до того, що розробники схвалять шкідливий PR без повної перевірки.
4.4. Викрадення Git-токенів
Токени можуть бути вкрадені через:
- незахищені змінні середовища
- використання на публічних серверах
- невірні дозволи на CI/CD-агентах
4.5. Маніпуляція історією комітів
Зловмисник може використовувати:
git rebaseдля зміни історіїgit push --forceдля підміни гілок
Це дозволяє приховувати шкідливі зміни або видаляти докази атаки.
5. Резонансні реальні випадки атак на CI/CD
5.1. SolarWinds (2020)
Одне з найбільших вторгнень, коли атакувальники компрометували процес збірки Orion Platform. Шкідливий код був вставлений у легітимні оновлення, які отримали понад 18 000 клієнтів.
5.2. Codecov (2021)
Зловмисники підмінили bash-скрипт CI-процесу, що вів до витоку токенів та ключів тисяч компаній.
5.3. GitHub Actions атаки через PR з fork
Дослідники виявили, що PR з форків можуть запускати робочі процеси GitHub Actions із доступом до секретів.
5.4. TravisCI витік секретів
Вдалося отримати ключі AWS та GitHub через неправильне управління конфігураціями CI.
6. Індикатори компрометації CI/CD або репозиторію
- Незрозумілі або неочікувані зміни у пайплайнах
- Аномальні логи агента або збільшене навантаження
- Поява нових токенів
- Запуск збірок у незвичний час
- Зміна історії комітів без пояснень
- Поява нових користувачів або доступів
- Підозрілі PR з мінімальними змінами
7. Як захиститися від атак на CI/CD та репозиторії
Наведемо рекомендації, які допомагають значно знизити ризики.
7.1. Використання багатофакторної автентифікації
Усі акаунти розробників повинні використовувати:
- 2FA
- hardware-токени
- passwordless-методи
7.2. Сканування конфігурацій CI/CD
Рекомендується використовувати автоматизовані системи для перевірки:
- GitHub Advanced Security
- Snyk
- SonarCloud
- Checkov
7.3. Мінімізація прав доступу
Кожен агент, кожен користувач та кожен сервіс повинен мати мінімально необхідний набір прав.
7.4. Використання Secrets Manager
Ніколи не зберігайте секрети у відкритих змінних, у репозиторіях або у конфігураціях YAML.
7.5. Ізоляція CI/CD-агентів
Агенти повинні бути ізольовані:
- у контейнерах
- у sandbox-середовищах
- без прямого доступу до продакшену
7.6. Контроль PR і commit-політик
- код-рев’ю двома особами
- заборона
push --forceна main - обов’язкова перевірка скриптів у PR
7.7. Аудит історії репозиторіїв
Регулярно аналізуйте зміни у:
- гілках
- конфігураціях пайплайнів
- тегах
- артефактах
7.8. Використання підписів комітів (GPG або SSH-signing)
Це дозволяє підтвердити автентичність кожного коміту.
7.9. Впровадження SBOM та інструментів контролю складу ПО
Software Bill of Materials дозволяє відстежувати всі елементи, які входять до продукту.
8. Найкращі практики DevSecOps для CI/CD
- Безпечний pipeline-by-design
- Захист артефактів і контейнерних образів
- Використання політик IaC (policy as code)
- Постійне сканування секретів
- Моніторинг аномальної поведінки у пайплайнах
- Регулярні penetration-тести CI/CD
9. Висновок
Компрометація CI/CD та репозиторіїв — один з найнебезпечніших та найскладніших типів атак у сучасному середовищі розробки. Вона дозволяє зловмисникам контролювати весь ланцюг створення програмного забезпечення, починаючи від коду і закінчуючи продакшеном. З огляду на це організації повинні впроваджувати комплексні заходи захисту, включно з автоматизацією безпеки, аудитами, ізоляцією середовищ та перевіркою конфігурацій.
Лише поєднання DevSecOps-підходів, регулярних перевірок та строгих політик доступу дозволяє побудувати надійний CI/CD, стійкий до атак.