SAST у конвеєрі: чому уразливості доходять до релізу
Статичний аналіз коду найчастіше живе окремим островом: запускається за розкладом або вручну, результати складаються у звіт, який мало хто відкриває. Складальна лінія при цьому проходить повністю зеленою — жоден її крок не дивиться на те, які зміни до неї потрапили.
Тому уразливості в коді спливають не там, де з'явилися. Неперевірене введення, що потрапляє прямо в запит, або ключ доступу, закомічений поруч із конфігом, спокійно доїжджають до тестового контуру, а іноді й до продуктивного.
Знаходить їх частіше не команда розробки, а сканер на периметрі або зовнішній звіт за підсумками перевірки.
Ціна знахідки — не сама правка, а супутня робота: з'ясувати, яка версія зараз в експлуатації, хто автор зміни, чи підпадає дефект під вимоги аудиту, і встигнути випустити позаплановий реліз.
Поки це відбувається, інженери відновлюють контекст за чужими правками замість своїх завдань — одна знахідка забирає день-два роботи кількох людей. Якщо дефект у бібліотеці, яку тягнуть ще кілька сервісів, рахунок іде на релізи.
SAST змінює картину не фактом запуску, а місцем перевірки в процесі: статичний аналіз стає кроком конвеєра, який зупиняє збірку при знахідці заданого класу й залишає слід в історії змін. Розбираємо, як вбудувати перевірку коду перед релізом, не втративши швидкість збірки.
Що змінюється після вбудовування перевірок у збірку
Перевірки коду (SAST) вбудовуються у дві точки: розбір змінених файлів локально до відправлення та повний прохід на кожній гілці у збірці. Критичні знахідки блокують злиття в основну гілку, решта потрапляє у звіт із прив'язкою до рядка й класу дефекту з переліку OWASP.
Рев'юер перестає бути єдиним фільтром: він дивиться логіку, а не шукає забуту перевірку прав доступу.
Частка дефектів, знайдених до рев'ю, зростає з чверті до 70–80%: неекрановане введення, секрет у конфігу й небезпечна десеріалізація ловляться на збірці, а не на тестуванні. На рев'ю приходить код, який уже пройшов формальний бар'єр, і обговорення зміщується до архітектури.
Час розбору знахідки скорочується, бо звіт дає контекст — файл, рядок, правило, приклад виправлення. Розбір займає хвилини замість пів години пошуків за змінами, якщо хибні спрацювання пригнічуються точковим налаштуванням, а не вимкненням правила цілком.
Кількість інцидентів після викочування падає в рази: цілі класи проблем не доходять до основної гілки.
Єдині правила аналізу задають однаковий поріг суворості для всіх репозиторіїв — новий сервіс із першого дня перевіряється так само, як старий, і не з'являється проєкт з ослабленим набором правил.
Якість коду зростає без разового авралу: фіксується базовий рівень знайдених проблем, і збірка падає лише на нових. Старі знахідки закриваються в міру правок, тому перевірки у збірці не гальмують випуск.
Варіанти запуску SAST: збірка, зміни, розклад
SAST рідко вмикають в одній точці конвеєра: різні режими закривають різні ризики й по-різному впливають на час збірки.
Інкрементальний аналіз дає автору зміни зворотний зв'язок за хвилини, повний прогін коду ловить міжмодульні потоки даних, які не видно під час перевірки окремих файлів.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Перевірка змінених файлів на кожен pull request | Потрібен швидкий зворотний зв'язок до рев'ю | Не бачить зв'язку з рештою кодової бази, частіше дає хибні спрацювання |
| Повний прогін коду у збірці | Невеликі репозиторії, критичні релізи | Подовжує конвеєр і навантажує агенти збірки |
| Нічна збірка за розкладом | Великі та багатомовні проєкти | Знахідки приходять із затримкою, вранці потрібен розбір |
| Ручний запуск на гілці релізу | Підготовка до випуску, розбір інциденту | Регулярність тримається на дисципліні команди |
На практиці режими комбінують: перевірку змінених файлів ставлять обов'язковим кроком на кожен pull request, нічну збірку — на всю кодову базу, а падіння збірки налаштовують лише за знахідками високого рівня критичності.
Відомі спрацювання відводять у baseline-файл, інакше звіт швидко втрачає цінність і його перестають читати.
Звіт віддаємо у форматі SARIF прямо в систему рев'ю — зауваження видно в дифі, без окремого порталу. Далі розберемо, який набір режимів доречний за вашого часу збірки та мови проєкту, і зафіксуємо пороги в правилах конвеєра.
Впровадження за кроками: від інвентаризації до передачі
Впровадження SAST — це послідовність робіт, де кожен етап спирається на результат попереднього, а не встановлення одного аналізатора.
Починаємо з інвентаризації репозиторіїв: без карти сервісів, мов і гілок неможливо налаштувати правила так, щоб перевірки не перетворилися на потік хибних спрацювань, який команда вимкне за тиждень.
- Інвентаризація репозиторіїв. Збираємо список проєктів, мов, збирачів і активних гілок, позначаємо архівні. Фіксуємо, де вже працюють лінтери та інші перевірки, щоб не дублювати сигнали.
- Схема інтеграції. Визначаємо точки запуску: на кожну зміну або лише перед злиттям в основну гілку. Тут же домовляємося, що робити при знахідці — блокувати злиття чи поки попереджати.
- Налаштування профілів. Під кожну мову та тип сервісу — свій набір правил. Критичне (ін'єкції, витоки секретів, небезпечна робота з файлами) вмикаємо одразу, шумні правила — у режимі спостереження, а для старих проєктів задаємо базову лінію, щоб не розбирати накопичений борг разом.
- Перевірка на реальній збірці. Проганяємо аналіз на кількох бойових репозиторіях: заміряємо, скільки часу він додає до збірки, відсікаємо хибні спрацювання, перевіряємо читабельність звіту та посилань на код.
- Розкатка за групами. Підключаємо решту репозиторіїв хвилями — від простих сервісів до пов'язаних із платежами та персональними даними. Кожну хвилю супроводжуємо розбором знахідок разом з авторами коду.
- Передача команді. Віддаємо регламент розбору знахідок, порядок оновлення правил і чергування. Окремо фіксуємо, як тимчасово послабити перевірку — з обов'язковим терміном повернення.
Конфігурації, правила та регламенти: що передаємо
Після впровадження SAST замовник отримує не звіт про разову перевірку, а робочі артефакти у своєму репозиторії: їх правлять, переносять між проєктами й передають новим інженерам без нашої участі. Нижче — перелік того, що залишається у вас, із поясненням, навіщо потрібен кожен елемент.
- Конфігурація етапу перевірки у файлі конвеєра: тригери на запити злиття та нічну збірку, поріг блокування, тайм-аути, кеш проміжних результатів.
- Набори правил під ваш стек: базовий профіль плюс окремі профілі для критичних сервісів із прив'язкою до гілок.
- Профілі аналізу: глибина розбору, цільові каталоги, винятки для згенерованого коду та зовнішніх бібліотек — кожен з обґрунтуванням.
- Регламент реагування: категорії серйозності, терміни усунення, хто розбирає знахідку, коли збірка блокується і як оформлюється мотивована відмова.
- Схема проходження знахідки: від коміту до звіту, де зберігаються результати і як вони пов'язуються із завданнями в трекері.
- Документація з перевірок: як додати правило, як придушити хибне спрацювання, як оновлювати профілі при зміні стеку.
- Інструкція для розробника: локальний запуск до відправлення змін, розбір звіту, типові сценарії виправлення.
- Журнал змін правил і матриця відповідальності: хто погоджує нові винятки й хто відповідає за перегляд профілів.
Кейс: перевірки у збірці скоротили розбір дефектів утричі
Що було до перевірок у збірці
У контурі — три продукти зі спільною бібліотекою та роздільними репозиторіями. Статичний аналіз запускали вручну перед релізом: знахідки накопичувалися місяцями й розбиралися пачками, на одну хвилю йшло до двох тижнів інженерного часу.
Половина зауважень стосувалася коду, який усе одно переписували, — корисний сигнал тонув у шумі, а правки після рев'ю тягнули терміни випуску.
Як налаштували пороги
Розгорнули SAST прямо в конвеєрі збірки на базі SonarQube і зафіксували базову лінію за поточним станом коду: старі знахідки потрапили у звіт, але збірку не блокували — інакше команди стали б уже першого дня.
Поріг якості поширили лише на нові зміни та правки в зачеплених файлах, а правила розбили на три рівні: блокувальні, попередження та інформаційні. Генератори, міграції й тестові заготовки винесли у винятки, щоб звіт не втрачав довіру.
За три місяці частка дефектів, що доходять до релізу, скоротилася втричі, час розбору знахідок на зміну — з 40 до 12 хвилин, а частка нових правок під перевірками зросла до 90%. Звіт в описі зміни зняв окрему стадію погоджень: автор бачить причину до рев'ю й закриває її сам.
SAST чи динамічний аналіз: що вибрати на старті
SAST і динамічний аналіз відповідають на різні питання.
Статичний розбір іде за вихідними текстами й не запускає застосунок: він будує граф викликів і відстежує потік даних від точок входу до небезпечних операцій — так знаходяться ін'єкції, обхід перевірок прав, небезпечна десеріалізація, помилки в роботі з криптографією. Він бачить код, який ще не покритий тестами, і вкладається в хвилини на етапі злиття гілки.
Динамічний аналіз дивиться на вже працюючий застосунок: підставляє дані в реальні запити й фіксує те, що проявилося в рантаймі — помилки конфігурації, зайві заголовки, доступ до чужих об'єктів.
Хибних спрацювань тут менше, але покриття обмежене сценаріями, які ви прогнали, і кодом, до якого ці сценарії дійшли. Тому підходи не замінюють, а доповнюють один одного.
Третій шар — перевірка залежностей: маніфести й файли блокування звіряються з базами відомих уразливостей, включно з транзитивними бібліотеками, і окремо перевіряються ліцензії.
Вмикається швидше за інші, не потребує повної збірки проєкту й дає помітну частку реальних знахідок, бо значна частина коду приходить ззовні.
Починати розумно із залежностей: мінімальна ціна включення в конвеєр збірки та передбачуваний результат.
Далі — SAST на зміненому коді, інкрементально, за дифом гілки, щоб команда не тонула у спрацюваннях; коли хибні позначені й поріг за критичністю погоджено, перевірку розширюють на весь репозиторій і роблять блокувальною.
Динамічний аналіз підключають, коли є стенд зі стабільними даними та повторювані сценарії. Один налаштований інструмент із розібраною базою спрацювань корисніший за три, увімкнені формально.
Часті сумніви: хибні спрацювання та швидкість збірки
Сумніви інженерів навколо SAST зазвичай зводяться до чотирьох речей: скільки шуму прийде у звіті, що станеться з порогом блокування збірки, чи встигне перевірка вкластися в конвеєр і що робити зі спадщиною в коді, де зауважень накопичилися тисячі. Розбираємо кожне — з тим, як це закривається на практиці.
Загальний принцип — не вмикати перевірку «на все й одразу», а спершу зафіксувати базовий зріз: поточні знахідки позначаються як відомий борг, блокувальними стають лише нові. Такий режим дає команді чистий сигнал із першого дня й не зупиняє релізи.
Збірка стане через хибні спрацювання?
Поріг блокування налаштовується за класом правила та рівнем достовірності: збірку зупиняють лише підтверджені уразливості у зміненому коді, спірні знахідки йдуть у звіт без блокування.
Кожен виняток оформлюється правилом із причиною та терміном перегляду — шум не накопичується мовчки.
Наскільки сповільниться перевірка?
Аналіз іде за зміненими файлами та їхніми залежностями, а не за всім кодом, результати кешуються між збірками. Повний глибокий прохід виноситься в окремий розклад. Для типової збірки це додає хвилини, а не десятки хвилин, і не блокує паралельні завдання.
У нас тисячі старих зауважень — з чого почати?
Спадщина в коді розбирається за базовим зрізом: фіксуємо поточний обсяг, розкладаємо за критичністю та модулями, далі суворий поріг діє лише на новий код. Старі знахідки закриваються планово — насамперед на гарячих шляхах і на периметрі, де ризик вищий.
Єдині правила залишаються спільними для всіх команд, а відмінності оформлюються профілями й локальними політиками, а не вимкненням перевірок.
Обговоримо задачу: точки впровадження та порядок кроків
Щоб оцінка та план спиралися на факти, а не на припущення, до старту робіт фіксуємо точки впровадження й порядок кроків. Нижче — питання, які знімаємо на першій розмові: від відповідей залежить обсяг робіт і послідовність, у якій SAST вбудовується в наявний конвеєр збірки.
- Де ставимо перевірку: крок збірки, передкомітний хук, сканування образу перед публікацією в реєстр або комбінація точок.
- Основна мова та збирач, чи є генерація коду й залежності, які збираються лише на складальному агенті.
- Режим старту: звіт без блокування збірки або зупинка при перевищенні порогу за критичністю.
- Хто володіє правилами винятків і як підтверджується хибне спрацювання — інакше правило вимкнуть цілком.
- Як знахідки доходять до розробника: коментар у завданні, звіт артефактом збірки, зведення за релізом.
- Які гілки захищені й що відбувається при падінні перевірки — збірка зупиняється чи йде далі з позначкою.
- Що потрібно щодо історії знахідок і доступів до звітів, чи потрібне вивантаження в зовнішню систему.
- Критерії приймання: частка перевірюваних змін, час до першої знахідки, скільки критичних дефектів доходить до стенда.
Опишіть задачу та те, як зараз влаштований конвеєр, — повернемося з оцінкою та планом: точки впровадження, порядок кроків, терміни й критерії приймання.
