SonarQube: чому налаштування за замовчуванням пропускає уразливості
Аналізатор розгорнуто, звіти зі статичного аналізу коду відкриваються на кожному злитті — а критичний дефект доходить до релізу і виявляється вже в експлуатації.
Причина зазвичай не в самому інструменті, а в тому, що профіль правил і пороги якості залишили такими, якими вони прийшли з коробки: аналізатор формально працює, але не заважає випустити уразливість.
Базовий профіль розрахований на усереднений проєкт. Він покриває загальні правила, але не знає контексту вашого стеку, тому пропущеними залишаються дефекти, специфічні для фреймворку: небезпечна робота з сесіями, конкатенація значень у запитах, слабкі алгоритми хешування паролів.
Саме так з'являються пропущені уразливості — Quality Gate при цьому стоїть у режимі попередження, збірка проходить зеленою, а зауваження накопичуються в черзі.
Технічний борг зростає швидше, ніж команда встигає його розбирати.
Перевірка на новому коді включена не для всіх гілок, старі модулі ніхто не переглядає, а сотні зауважень без пріоритету зливаються в один шум — рев’юери перестають відкривати звіт, і він перетворюється на формальність.
Робоче налаштування SonarQube будується від зворотного: профіль правил збирається під конкретний стек, Quality Gate блокує злиття, а не прикрашає звіт, і окремо задається період нового коду, щоб старі модулі не маскували свіжі зміни. Додаються виключення для згенерованого коду та пороги за покриттям тестами.
Нижче розбираємо, як це закривається на практиці — від розгортання та профілю до порогів, які ловлять дефекти до релізу і не гальмують команду.
Що змінюється після впровадження статичного аналізу
Перший вимірюваний ефект — момент виявлення. Поки перевірка живе тільки в нічних збірках, дефект виринає через добу після правки, коли контекст уже втрачено.
SonarQube у зв'язці з системою контролю версій запускає аналіз на кожному запиті на злиття і блокує його при нових порушеннях — ціна правки це один рядок в описі, а не розбір інциденту в проді.
Час проходження перевірки тримається в межах 2–4 хвилин: аналізуються тільки змінені файли, повний прохід по всій кодовій базі йде в нічний розклад. Це знімає головний аргумент проти статичного аналізу — «збірка стала довшою, команда чекає».
Технічний борг перестає зростати, коли правило сформульовано як «нуль нових порушень»: легасі не чіпають, новий код зобов'язаний проходити чисто. Метрика боргу не падає миттєво, але перестає розширюватися — її вже можна планувати як окрему задачу, а не як некерований фон.
З класів відмов виходять ті, що ловляться формально: розіменування пустого посилання, незакриті потоки та з'єднання, збірка запиту з рядків, облікові дані у вихідних кодах. Це не «всі помилки», а конкретний зріз, який дешевше не допускати взагалі.
На виході з'являється прогноз за релізами: Quality Gate працює як формальний критерій — версія або проходить його, або ні. Керівник напрямку отримує не «ми старалися», а відтворювану оцінку ризику перед викаткою.
Варіанти розгортання: власне середовище, контейнери, хмара
Аналізатор можна розмістити кількома способами, і вибір тут диктують не зручність адміністрування, а два обмеження: де фізично зберігається вихідний код і хто відповідає за оновлення.
Розгортання аналізатора в закритому контурі виключає передачу коду назовні, контейнерний запуск дає однакову конфігурацію на всіх стендах, а хмарний режим аналізу знімає турботу про інфраструктуру, але змінює модель довіри до коду.
Порівняння режимів розміщення
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власне середовище на своїх серверах | Закритий контур, вимоги до зберігання вихідного коду всередині периметра, десятки проєктів | Оновлення, резервні копії та масштабування — на боці вашої команди |
| Контейнерний запуск | Потрібно швидко підняти аналізатор і повторювати одну конфігурацію на різних стендах | Стан і базу аналізу виносять в окремі томи, інакше результати губляться при перестворенні |
| Хмарний режим аналізу | Розподілені команди, короткий термін запуску, своєї інфраструктури немає | Вихідний код залишає периметр — частина проєктів такого не пропустить за своїми правилами |
| Гібрид: розбір у закритому контурі, звіти в загальному | Потрібна єдина картина по всіх командах при жорстких правилах на код | Потрібні два контури і синхронізація профілів і шлюзів якості |
Вибір зводиться до одного питання: чи допустимо, щоб вихідний код залишав ваш периметр. Якщо ні — залишаються власне середовище або контейнери всередині контуру, а хмару розглядають тільки для відкритих проєктів.
Для команди до десяти розробників контейнерний запуск зазвичай дає той самий набір перевірок, що й повноцінна установка, але піднімається помітно швидше.
Налаштування SonarQube під ваш стек: порядок робіт
Налаштування SonarQube починається не з установки сервера, а з розбору того, як код зараз потрапляє в основну гілку і які перевірки там уже є.
Так видно, де аналізатор дасть ефект відразу, а де спочатку доведеться навести лад у конвеєрі збірки — інакше частину проєктів просто не буде чого аналізувати. Нижче — маршрут, за яким ідемо на впровадженні.
- Аудит конвеєра збірки. Розбираємо системи збірки, модель розгалуження, релізний цикл і доступи до репозиторіїв. На виході — список проєктів, які підключаємо першими, і вузькі місця, що заважають аналізу.
- Схема розгортання. Визначаємо розміщення сервера аналізу, бази та сховища звітів, описуємо, як задача аналізу вбудовується в збірку і що бачить розробник в інтерфейсі.
- Налаштування профілю правил. Збираємо профіль під ваш стек: мови, фреймворки, критичні для бізнесу перевірки. Вимикаємо шум, який дає хибні спрацьовування і підриває довіру до звіту.
- Пілотний репозиторій. Запускаємо аналіз на одному проєкті середньої складності і дивимося реальний потік зауважень і час проходження збірки. Правки в профіль вносимо за фактом, а не за документацією.
- Перевірка порогів якості. Фіксуємо умови проходження гілки та релізу, перевіряємо поведінку на брудному і чистому коді, тестуємо блокування збірки і зрозумілість виводу.
- Передача в супровід. Віддаємо команді конфігурації, регламент додавання правил та інструкцію з розбору хибних спрацьовувань. Далі — плановий перегляд профілю в міру зростання коду.
Такий порядок дає передбачуваний результат: на момент розкатки на всі проєкти пороги вже відкалібровані, а команда розуміє, що робити з кожним зауваженням.
Що залишається у вас: профілі, правила, схеми інтеграції
Інженерний результат впровадження — не запущений сервер аналізу, а артефакти, які залишаються у вашому репозиторії і працюють без нас. Перелічуємо, що саме передається команді на руки і за якими документами далі живе SonarQube у вашому конвеєрі.
- Профіль правил — активний набір під ваш стек, вивантажений у репозиторій файлом: розгортається на новому контурі однією командою, а не ручним переналаштуванням в інтерфейсі.
- Порогові умови якості — роздільні для нового коду і гілки релізу: покриття нових рядків, частка дублів, відсутність блокуючих зауважень.
- Політики виключень — маски на згенерований код, міграції, вендорні каталоги і застарілі модулі, щоб аналіз показував проблеми в коді, який ви реально змінюєте.
- Схема інтеграції з конвеєром — де стає крок аналізу, що кешується між збірками, як зауваження потрапляють у запит на злиття і що саме блокує злиття.
- Регламент розбору зауважень — хто розбирає потік, у який термін закривається блокуюче зауваження, коли допустиме придушення з обов'язковою міткою і терміном перегляду.
- Звітність за якістю — вивантаження метрик за релізами: щільність дефектів, покриття, динаміка технічного боргу, без ручного збору цифр.
- Експлуатаційна документація — схема контурів, ролі та доступи, порядок оновлення правил і порядок відключення аналізу, якщо він затримує збірку.
Кейс: прибрали клас дефектів і скоротили борг за кодом
До впровадження: звіт, який обходили
Аналіз SonarQube запускався вручну, найчастіше на релізній гілці, а Quality Gate стояв на стандартних порогах.
Пороги ці були марні: правило або мовчки пропускало все, або блокувало збірку на форматуванні та спірних правилах стилю — за пару місяців команда звикла перевірку обходити.
Щільність дефектів трималася на 1.2 на тисячу рядків нового коду, розбір зауважень займав до 40 хвилин на зміну, а борг за кодом додавав по 5-7% за квартал: у звіті зростав список, але ніхто не розбирав його за пріоритетом.
Що перебудували
Зібрали профіль правил під наш стек — прибрали шумні перевірки, залишили блокуючі з безпеки та надійності, включили аналіз тільки нових рядків зміни, щоб звіт не тонув у успадкованому коді.
Quality Gate прив'язали до нового коду: покриття нової логіки тестами, нуль блокуючих знахідок, обмеження за дублюванням. Перевірка стала обов'язковим кроком конвеєра до злиття, а зауваження автоматично потрапляли в трекер з пріоритетом і терміном реакції за рівнем критичності.
Метрики після
- щільність дефектів на тисячу рядків: 1.2 → 0.4
- час розбору зауважень на зміну: 40 → 12 хвилин
- частка блокувань збірки: 32% → 4%, і майже всі — за критичними знахідками, а не за стилем
- борг за кодом: зростання зупинено, за два квартали обсяг скоротився у 2.5 раза
Ключовий ефект не в цифрах звіту, а в тому, що критичні дефекти перестали доходити до релізної гілки — відкатів з причин, які ловить статичний аналіз, за період спостереження не було.
Чим порогова умова якості відрізняється від перевірки збірки
Перевірка в збірці відповідає тільки на питання «чи запустився аналіз». Задача кроку — розібрати код, зібрати звіт і зберегти його поруч зі збіркою. Якщо сам аналізатор не впав, крок вважається успішним навіть при сотні зауважень: конвеєр зелений, зміна йде далі.
Порогова умова якості — це рішення про приймання. Сервер рахує метрики за конкретною зміною і порівнює із заданими межами: частка покриття новим кодом, число блокуючих зауважень, обсяг дублів, критичні уразливості. Межі не виконані — статус «не пройдено», і система контролю версій не дає виконати злиття.
Практична деталь, від якої залежить, чи приживеться поріг: рахувати його за новим кодом, а не за всією базою. На успадкованому коді умова за всіма файлами не стане зеленою ніколи, і команда звикне його ігнорувати. Для старого коду тримають окремі м'які межі і посилюють їх у міру розбору боргів.
У SonarQube це налаштовується як умова на гілку або запит на злиття плюс правило блокування на боці сховища коду: поки статус не зелений, кнопка злиття неактивна. Крок конвеєра при цьому отримує ненульовий код повернення — збірка зупиняється, а не просто позначає звіт.
Часта помилка — залишити перевірку «інформаційною»: знахідки є, але гілку ніхто не блокує. Тоді критерії приймання коду залишаються на совісті рев'юера, а метрики поступово деградують.
Різниця проста: перевірка показує, що знайшлося, порогова умова вирішує, чи потрапить зміна в основну гілку.
Технічні сумніви, з якими приходять команди
Перед стартом команди піднімають одні й ті самі питання — це нормальна ознака зрілого процесу. Зібрали ті, що найчастіше виринають при узгодженні методики, разом з відповідями наших інженерів.
У нас великий легасі — аналіз потоне в знахідках
Включаємо інкрементальний аналіз: перевіряються тільки змінені рядки, а не весь масив. Поточний стан фіксується як базова лінія, і вона не блокує збірку — борг знижується в міру правок у зачеплених файлах, без зупинки розробки.
Чи можна описати свої правила під внутрішні угоди?
Так. Свої правила закривають те, що не покривають стандартні набори: заборона самописних обгорток над системними бібліотеками, обов'язкові заголовки ліцензій, обмеження на звернення до застарілих модулів. Правила живуть у профілі і версіонуються разом з кодом.
Кілька контурів — як вони не заважають одне одному?
Розводимо проєкти по ізольованих контурах: окремі адреси, свої набори умов якості, незалежні токени доступу. Передрелізні збірки не перетирають звіти основної гілки, а збій в одному контурі не блокує інші.
Тестовому коду потрібні інші пороги?
Так, роздільні пороги обов'язкові. На тестовий код розраховуються інакше покриття і дублювання — низькі значення там очікувані і не повинні зупиняти збірку. Задаємо окремі умови якості, щоб заготовки не створювали хибних блокувань.
Обговоримо задачу: розберемо ваш випадок і повернемося з планом
Щоб оцінка обсягу робіт була предметною, а не «середньою по галузі», нам потрібні ввідні про ваш код і конвеєр. Чим конкретніші вихідні, тим точніший план впровадження і менше переробок по ходу: інструмент статичного аналізу вбудовується в уже існуючий процес, а не замінює його.
- структура репозиторіїв: скільки проєктів, якими мовами, монорепозиторій або набір окремих;
- поточний конвеєр: чим збирається, які етапи вже є, де збірка найчастіше падає;
- що перевіряється зараз: лінтери, обов'язкове рев'ю, ручне тестування — і що з цього не можна вимикати;
- вимоги до якості: які правила вважати блокуючими і хто вправі зупинити збірку;
- доступи та оточення: де розміщується сервіс аналізу, як він підключається до репозиторіїв і систем збірки;
- режим роботи: скільки часу збірка може додати, що критично за термінами випуску;
- історія інцидентів: які дефекти вже доходили до експлуатації і на якому етапі їх можна було спіймати.
Зі свого боку уточнюємо межі: де проходять довірені і недовірені збірки, як розмежувати права на зміну правил, чи потрібен окремий контур для legacy-коду, щоб він не блокував роботу над новим. Усе це впливає на глибину налаштування і на те, скільки конвеєрів доведеться перебудувати.
Повертаємося з оцінкою обсягу робіт, планом впровадження за етапами і розбором конвеєра: які перевірки куди стають, що стане блокуючим відразу, а що вводиться поступово. Окремим пунктом — передача документації: конфігурації, правила, інструкції для розробників і чергових.
Опишіть задачу у вільній формі — за цими ввідними зберемо оцінку і повернемося з планом робіт.
