Security Gate у CI/CD: автоматичне блокування деплою

Security Gate не зупиняє деплой: де ламається контроль

У конвеєрі є кроки перевірки: сканування залежностей, пошук секретів, аналіз базового образу. Security Gate формально налаштований, звіти збираються й складаються артефактами, але випуск потрапляє в прод із критичною уразливістю та ключем доступу, забутим у змінних середовища.

Причин зазвичай дві. Автоматичне блокування деплою переведено в режим попередження, бо заважало терміновим правкам, — і назад його вже ніхто не вмикав. Або перевірки стоять не на тій межі: сканується код у гілці, а в прод викочується образ, зібраний з іншого коміту.

Третя, найнепомітніша причина — винятки. Кожне «відоме» спрацювання закривають правилом ігнорування, список зростає, і в якийсь момент він накриває більшу частину критичних перевірок. Уразливості у випуску залишаються у звітах, але перестають на щось впливати.

Перевірки перед викочуванням працюють лише там, де рішення ще можна скасувати, — до потрапляння образу в прод-середовище.

Блокування після викочування це вже не контроль, а сигнал тривоги: уразливість живе в проді до планового розбору, а відкат обходиться дорожче, ніж зупинка на вході.

Вузьке місце релізу — не швидкість збірки й не кількість перевірок, а те, що їхній результат ні на що не впливає. Розбираємо, де саме у вашому конвеєрі контроль якості деплою перестає бути контролем і що робить блокування реальним.

Що дає автоматичне блокування деплою за перевірками

Перевірки всередині конвеєра перетворюють безпеку з окремого етапу перед релізом на умову випуску. Security Gate — це правило: поки не пройдені обов’язкові контролі, артефакт не потрапляє в середовище.

Ефект вимірний — скорочується частка аварійних випусків, а час відновлення після збою перестає залежати від того, хто з чергових першим помітив проблему.

Усунений клас відмов

Контроль відсікає релізи з відомими уразливостями в залежностях, секретами в образі та несумісними міграціями схеми. Раніше такі дефекти знаходили вже в робочому середовищі, тепер збірка зупиняється до викочування — аварійні випуски скорочуються в рази.

Відкат автоматизовано: середовище повертається до попереднього стабільного артефакту за хвилини, тому вартість простою визначається тривалістю збою, а не часом на погодження.

Швидкість збірки та випуску

Перевірки йдуть паралельно і лише за зміненими шляхами — контроль додає до збірки хвилини, а не десятки хвилин. Ручні погодження замінюються правилом: конвеєр у GitLab CI запускає викочування сам, якщо всі контролі зелені.

Звідси передбачуваність релізів — версія, її склад і результат перевірок фіксуються в одному журналі, і випуск перестає бути подією з ручною координацією.

Варіанти контролю: блокування, попередження, вибіркові правила

Режим перевірок — це не «увімкнути сканер», а політика: що саме вважається підставою зупинити випуск і на які гілки вона поширюється. Нижче три конфігурації, між якими реально обирають команди, та їхні обмеження.

Жорстке блокування на захищених гілках

Правило спрацьовує до злиття: конвеєр не пропускає зміну, поки не пройдені обов’язкові перевірки залежностей, секретів і статичного аналізу.

У GitLab це збирається із захисту гілки та обов’язкових звітів — обійти можна лише явним рішенням власника репозиторію, і це рішення залишається в історії.

Змішаний режим для зрілих команд

Блокування ставиться на критичні шляхи, решта йде з попередженням і потрапляє у звіт про зміну. Випуск не встає через одиничну знахідку, а список боргів залишається видимим і розбирається за пріоритетом.

Етапи впровадження перевірок у конвеєр збірки та випуску

Порядок робіт однаковий і для одного сервісу, і для сотні репозиторіїв: спочатку розбираємо, що вже є в конвеєрі, потім проєктуємо точки контролю і лише потім вмикаємо блокування. Правило, увімкнене без обкатки, зупиняє випуск і підриває довіру до всіх перевірок одразу.

Аудит конвеєра та інвентаризація перевірок

1. Збираємо карту конвеєра: кроки на збірці та перед викочуванням, середовища, ручні підтвердження, середній час проходження.
2. Інвентаризуємо наявні перевірки — сканер залежностей, статичний аналіз, пошук секретів, перевірку образів. Для кожної фіксуємо режим: блокує, попереджає або пише звіт, який ніхто не читає.
3. Проєктуємо схему точок контролю: що перевіряємо до злиття, що на збірці артефакту, що перед викочуванням у бойове середовище. Для кожної точки задаємо клас знахідок, який її зупиняє.
4. Налаштовуємо правила: пороги за критичністю, базовий рівень для успадкованого коду, винятки з власником і строком перегляду. Правило без власника швидко перетворюється на вічний шум.

Обкатка на тестовому контурі

• Розгортаємо копію конвеєра й вмикаємо нові правила в режимі попередження: вони рахують знахідки, але не зупиняють випуск.
• Вимірюємо хибні спрацювання та доданий час збірки. За вимірами правимо пороги, щоб блокувалися лише реальні ризики.
• Переводимо правила в блокуючий режим, описуємо обхід для термінових правок і передаємо команді матрицю «знахідка — дія — строк», інструкцію для розробника та порядок розбору хибних спрацювань.

Що передаємо: правила перевірок, політики доступу, регламенти

Передаємо не набір разових скриптів, а керований контур контролю: правила перевірок, політики доступу, ролі та права, схеми точок контролю й регламенти.

Усе це лежить у репозиторіях замовника й версіонується, тому зміна правил проходить рев’ю, а не правиться руками на сервері в момент інциденту.

Конфігурації та версіонування правил

• Правила перевірок як код: єдиний файл конфігурації для всіх гілок, окремі набори для релізних і звичайних збірок.
• Політики доступу та ролі: сервісні облікові записи для збірки, розділення права читати секрети й права викладати, принцип найменших привілеїв.
• Схема точок контролю: де стоїть Security Gate — до збірки артефакту, перед викладкою в проміжний контур і перед виробництвом.
• Пороги спрацювання: що саме блокує деплой, що йде лише у звіт і як оформити виняток із датою перегляду.
• Історія змін: кожна правка правил — окрема зміна з описом, хто й навіщо послабив перевірку.

Документація та регламент реагування

• Інструкція для розробника: як відтворити перевірку локально, що читати у звіті, куди йти при хибному спрацюванні.
• Регламент реагування: хто й за який час розблокує деплой, за яких умов допустимий обхід і як він фіксується.
• Карта власників: у кожного правила вказаний відповідальний, у кожного винятку — строк життя та умова зняття.
• Порядок відкату: як зняти блокування, якщо перевірка зупинила критичну правку, і що фіксується за підсумками розбору.

Кейс: частка аварійних випусків знизилася втричі

Потік із кількох десятків сервісів — релізи кілька разів на день, у кожного свій конвеєр. Перевірки безпеки при цьому жили збоку від збірки, тому питання «чи можна котити» вирішувалося людьми й по-різному. Нижче — що саме блокували, що показали метрики й як команда переходила на нові правила.

Що було до впровадження

Сканери запускали вручну перед великими релізами, звіт приходив листом через день — на момент читання частина знахідок уже їхала в прод. Частка аварійних випусків (відкат або гарячий патч у першу добу) трималася близько 18%: майже кожен п’ятий реліз вимагав позапланової роботи. Ручна перевірка одного сервісу займала 30-40 хвилин інженера, і на потоці її просто проскакували.

Що змінилося після

Перевірки вбудували прямо в конвеєр збірки на GitLab: уразливості залежностей, секрети в коді та конфігураціях, права в маніфестах. Критична знахідка зупиняє деплой до виправлення, середня йде задачею в трекер із власником і строком.

Час перевірки скоротився до 4-6 хвилин і йде паралельно збірці — випуск не чекає окремої людини. Частка аварійних випусків упала до 6%, тобто втричі.

Перехід зайняв близько місяця: перші два тижні правила працювали в режимі спостереження — знахідки збиралися, але деплой не блокувався, щоб команда побачила реальний шум і ми відкалібрували пороги.

Правило обходу зафіксували окремо: зняти блокування може лише відповідальний за сервіс, із причиною та строком усунення, і такий виняток залишається видимим у звіті.

Чим Security Gate відрізняється від перевірок усередині конвеєра?

Перевірка та шлагбаум — різні сутності. Статичний аналізатор, сканер залежностей або пошук секретів у репозиторії лише формують звіт: їхній висновок за замовчуванням не заважає викладці, поки збірка не прив’язана до точки прийняття рішення.

Security Gate — це політика випуску: набір умов, за яких артефакт допускається в цільовий контур, а в разі невиконання випуск забороняється без ручного підтвердження.

Відмінність від статичного аналізу в тому, що аналізатор відповідає на питання «що знайдено», а шлагбаум — «чи можна це випускати зараз».

Один і той самий інструмент працює в режимі спостереження та в режимі заборони, і перемикання між ними — рішення власника ризику, а не налаштування. Тому правила фіксують поріг: клас уразливості, критичність, наявність виправленої версії залежності, вік знахідки.

Розділення ролей задається явно: інженери платформи пишуть і супроводжують правила, команда сервісу відповідає за усунення або за оформлений виняток, випуск підтверджує той, хто володіє ризиком.

Виняток живе як окремий запис із власником і датою перегляду — інакше шлагбаум обходять правкою конфігурації.

Послідовність перевірок важлива не менше: спочатку швидкі перевірки на етапі збірки, потім аналіз залежностей і образів, і лише після них — рішення про перехід у продуктивний контур.

Заборона ставиться в одній точці — на межі між середовищами, щоб результат був відтворюваний, а обхід не залишався на розсуд чергового.

Часті технічні сумніви щодо блокуючих перевірок

Перед стартом інженери та керівники напряму задають майже одні й ті самі питання: чи не встане збірка, чи не доведеться переписувати конвеєр і хто відповідає за хибне спрацювання. Нижче — короткі відповіді без загальних слів.

Що робити з хибними спрацюваннями?

Правила налаштовуються під профіль проєкту, а не «на все одразу». Виняток оформлюється з обґрунтуванням і строком перегляду, а повторне спрацювання після придушення видно у звіті — частка хибних із часом падає.

Чи можна обійти блокування?

Правило живе на боці сервера перевірок, а не у файлі проєкту, тому правкою маніфесту його не зняти. Обхід можливий лише через явне підтвердження із записом у журнал: хто зняв, за якою задачею і на який строк.

У нас уже розгорнутий конвеєр — переписувати?

Ні, блокування підключається окремим кроком до наявного конвеєра. Спочатку вмикаємо режим спостереження: перевірки звітують, але не зупиняють випуск, — переводимо в блокуючий режим після того, як правила перестануть давати шум.

Доведеться змінювати поточні інструменти?

Сканери, лінтери, тести й сховище образів залишаються на своїх місцях: шлюз агрегує їхні результати та приймає рішення за набором правил. Змінюємо лише те, що заважає отримувати машинно-читний звіт.

Обговоримо схему перевірок і повернемося з планом впровадження

Щоб розмова була предметною, надішліть опис поточного конвеєра: чим збираєте, де зберігаються артефакти, які перевірки вже увімкнені й на якому кроці випуск зупиняється зараз. Цього достатньо, щоб зрозуміти масштаб і не гадати про деталі.

Далі ми розбираємо задачу, погоджуємо точки контролю й повертаємося з оцінкою строків і планом робіт за пунктами. Ви заздалегідь бачите, що і в якому порядку робимо, і де знадобиться ваш доступ або рішення.

• Інвентаризація конвеєра — які гілки та середовища живуть, хто випускає зміни і як часто.
• Точки контролю — де ставити Security Gate: до злиття, перед збіркою образу або перед випуском у продуктив.
• Політика блокувань — які знахідки зупиняють випуск, а які йдуть у звіт і не гальмують команду.
• Регламент винятків — як оформити обґрунтований обхід, щоб він автоматично спливав, а не жив вічно.
• Пілот на одному сервісі — вмикаємо перевірки на одному, рахуємо частку хибних спрацювань і час випуску, потім тиражуємо.
• Порядок робіт і оцінка строків — за етапами, з критеріями готовності на кожному.
• Підтримка після впровадження — оновлення правил, реакція на нові класи уразливостей, підключення нових сервісів.

Опишіть задачу — повернемося з оцінкою та планом.