Кожна команда, до якої я приходив, повторює ту саму мантру — наче це закон фізики: або безпека, або швидкість, обирай щось одне. Або повільні релізи, або ризик. Я не погодився ні на те, ні на інше. Далі — історія про те, як я зібрав security gates у CI/CD pipeline, що працюють паралельно зі збіркою: безпека стала невидимою, а деплой не втратив жодної хвилини.
Схема, зламана від самого початку
Опишу «нормальний» процес безпеки — найпевніше, ви це вже проходили.
Security review трапляється один раз, десь просто перед релізом. У прод їдуть container images, які взагалі ніхто жодного разу не сканував. RBAC-політики скопійовані з відповіді на Stack Overflow трирічної давнини. А всі просто тихо сподіваються, що пронесе.
Потім хтось нарешті чіпляє сканер на pipeline — і робить це найгіршим з можливих способів. Скан запускається після збірки. Розробник чекає результат 45 хвилин. Один medium-фіндінг блокує весь pipeline. За тиждень команда вже обходить процес стороною, і «рішення» завжди одне: вимкнути gate.
Про це не говорять на конференціях. Безпека, що гальмує, — це безпека, яку вимикають. Ти не стаєш захищенішим. Ти отримуєш галочку і хибне відчуття спокою.
Ідея, що змінює все: ганяти паралельно
Секрет — не в модному фреймворку й не у вендорській платформі. Секрет у паралельному виконанні.
Скани не запускаються після збірки. Вони йдуть поруч із нею. Pipeline робить свою звичну роботу — компіляція, тести, пакування, — а security-стадії крутяться в тому ж вікні, за тим самим годинником. Додатковий час для розробника — практично нуль.
Що реально працює:
- SonarQube на кожен pull request. Якість коду й пошук вразливостей прилітають коментарями в рев'ю ще до того, як PR відкриє жива людина.
- Trivy сканує кожен container image на етапі збірки — не після деплою, коли вже пізно.
- Terraform-плани перевіряються проти security-політик ще до того, як торкнуться інфраструктури. Той самий публічний S3-бакет ловиться ще до того, як з'явиться.
- Перевірки залежностей ідуть у ту ж хвилину, що й unit-тести.
- Jenkins диригує всім потоком: пройшли всі gate — авто-апрув і деплой; щось впало — розробник отримує фідбек просто у своєму pull request, а не листом за три тижні.
Блокує лише critical. Решта — у розклад.
Ось рішення, завдяки якому все це вижило при зустрічі з живими розробниками.
Деплой зупиняє лише critical. Решта — medium, low, інформаційне — трекається, заводиться в тікети й планується. Один галасливий фіндінг більше не бере реліз у заручники. Gate суворий там, де мусить, і мовчить усюди, де можна, — тому йому довіряють, а не воюють з ним.
Безпека перестає бути глухою стіною і стає тим, чим мала бути від початку: коментарями в рев'ю, там, де розробник і так працює.
Результати
- Нуль critical-вразливостей у проді — спіймані на етапі PR, а не в post-mortem.
- Швидкість деплою не змінилася. Навіть трохи зросла — бо ніхто більше не чекає послідовний скан.
- Покриття пішло від «квартального аудиту, якого всі бояться» до «кожен коміт, автоматично».
І мій улюблений підсумок, якого я не планував: розробники перестали вимикати security-перевірки. Не тому що я змусив, — тому що вони забули, що перевірки взагалі є. Це найвища похвала для security pipeline.
Справжній висновок
Той самий shift left, який усі згадують на слайдах, — це не продукт, який купують. Це рішення в дизайні. Перенеси фідбек у момент, коли пишеться код; зроби його паралельним, щоб він нічого не коштував; і блокуй лише те, що справді не можна пускати в прод.
Безпека, що гальмує, — це безпека, яку вимкнуть. Зроби її невидимою — або втратиш зовсім.
Безпека — не блокер. Це фіча твого pipeline.
І питання наостанок: твій security gate працює паралельно — чи це те саме вузьке горло, яке тихо ненавидить уся команда?