Стаття / інженерна стаття
Безпека CI/CD: що перевірити до наступного релізу
Pipeline має доступ до коду, артефактів і часто до production. Аудит варто починати з того, хто може запускати код із цими правами. Нижче — порядок перевірки для невеликої команди, яка хоче покращити контроль без придбання нового набору інструментів.
Намалювати межі доступу
Випишіть події, які запускають pipeline: pull request, push, тег, ручний запуск. Поруч позначте дозволені гілки, runner, доступні секрети й можливість публікації. Найкорисніший результат такого огляду — знайти шлях від зовнішньої зміни до привілейованої дії.
Наше правило проєктування: перевірка стороннього коду та production-деплой мають різні умови довіри. Не передавайте deploy-доступ звичайній перевірці pull request лише тому, що їх зручно описати одним job.
Зменшити права та строк життя секретів
GitHub рекомендує мінімальні права GITHUB_TOKEN та використання секретів замість відкритих значень. OIDC дозволяє обміняти ідентичність workflow на короткоживучі хмарні облікові дані, коли провайдер і налаштування довіри це підтримують.
Ми перевіряємо не тільки місце зберігання ключа, а й те, що ним можна зробити. Відсутність секрету в репозиторії не допомагає, якщо будь-який workflow може отримати адміністративний токен.
- Встановити read-only права за замовчуванням і підвищувати їх лише для конкретної операції.
- Обмежити довіру cloud role репозиторієм, гілкою або deployment environment.
- Перевірити логи й артефакти на випадкове розкриття даних.
- Якщо ключ розкрито, відкликати або замінити його; видалення рядка з Git недостатнє.
Перевіряти те, що входить у збірку
Зовнішня action — код, який запускається всередині вашого workflow. GitHub рекомендує фіксувати actions на повний commit SHA. Власник pipeline має перевіряти походження й оновлення залежностей, а не лише наявність зеленого статусу.
Для нашого checklist окремі питання — lockfile, версія runtime, доступ job до мережі та походження артефакту, який буде випущений. Сканування залежностей корисне, коли для знахідок є відповідальний і строк розбору, а не нескінченний список попереджень.
Визначити, що блокує реліз
Не кожна знахідка однаково небезпечна. Ми рекомендуємо фіксувати доступність у production, можливість експлуатації та потрібні права. Виняток має містити причину, власника й дату повторного перегляду.
| Знахідка | Перший крок |
|---|---|
| Відкритий production-секрет | Відкликати доступ і з'ясувати використання. |
| Недовірений PR отримує deploy-права | Зупинити небезпечний шлях запуску й розділити jobs. |
| Вразлива залежність | Перевірити досяжність, оновити й прогнати критичний сценарій. |
| Застарілий сканер без власника | Призначити відповідального й відновити обробку результатів. |
Перевірити відновлення, а не лише заборони
Попросіть команду показати, як вона визначає поточний реліз, повертає попередній артефакт і діє після невдалої міграції. Це виявляє прогалини, які не видно в YAML.
Результатом огляду має бути короткий список конкретних змін із відповідальними. Цей checklist допомагає організувати роботу; він не є сертифікацією відповідності чи заміною перевірки конкретної інфраструктури.
Джерела та контекст
Маєте подібну задачу?
Розкажіть про продукт, поточні обмеження й потрібний результат — визначимо предметний наступний крок.