Безпека контейнерів: впровадження Trivy у CI/CD

Уразливості в образах контейнерів: де ламається Trivy CI/CD

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

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

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

Окрема пастка — підміна базового образу: тег указує на перезібраного предка, вміст змінився, а попередні перевірки цього не помітили, бо порівнювали ім'я, а не незмінне посилання.

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

Тоді сканування на збірці формально є, але рішення про зупинку не ухвалює ніхто, і уразливі образи проходять рев'ю за інерцією.

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

Що дає сканування образів у Trivy CI/CD

Контроль уразливостей на кожному коміті

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

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

Збірка зростає на секунди, а не на хвилини

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

Блокування викочування за порогом

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

Реєстр перестає зростати

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

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

Режими перевірки: від ручного прогону до блокування збірки

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

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

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

Порядок впровадження: від аудиту образу до регламенту

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

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

1. Аудит образів. Збираємо перелік базових образів, реєстрів і складальних завдань, дивимося, що тягнеться із зовнішніх джерел і де немає закріплення за контрольною сумою, — отримуємо карту того, що взагалі належить перевіряти.
2. Схема допусків. Домовляємося, що вважати блокуючим: критичні уразливості з доступним виправленням зупиняють збірку, решта йде у звіт і чергу на розбір. Без цього правила впровадження скочується в суперечку про кожен рядок.
3. Налаштування сканування. Вбудовуємо Trivy у збірку та в перевірку перед відправленням у реєстр, розносимо рівні строгості для гілок розробки й релізних, кешуємо базу уразливостей, щоб перевірка не тягла її заново.
4. Перевірка на реальних образах. Проганяємо правила на поточних артефактах, а не на навчальних: дивимося, скільки спрацювань реально блокують збірку, і калібруємо пороги, поки доданий час не стане непомітним.
5. Винятки та строк їхнього життя. Оформлюємо обґрунтовані винятки з відповідальним і датою перегляду — так тимчасове послаблення не перетворюється на постійну діру в схемі допусків.
6. Регламент і передача. Фіксуємо порядок дій при спрацюванні, точки відкату й порядок оновлення правил, проводимо розбір із командою та віддаємо документацію разом із налаштуваннями.

Пакет передачі: політики, конфігурації та документація

Після здачі в репозиторії залишається вся обв'язка навколо Trivy: не лише запускані перевірки в CI/CD, а й конфігурація, політики та регламенти. Усе це версіонується поруч із кодом і змінюється через звичайне рев'ю змін, а не через листування з підрядником.

• Конфігурація перевірок — файл налаштувань сканування з наборами правил, рівнями серйозності та списком винятків; кожен пропуск позначений власником і датою перегляду.
• Політики допуску образів — які уразливості блокують збірку, які лише логуються, для яких гілок діє суворий режим.
• Артефакти сканування — звіт у машинозчитуваному вигляді та склад образу у форматах CycloneDX або SPDX, прив'язані до тегу збірки.
• Регламент реагування — таблиця «рівень серйозності → строк реакції → відповідальний», порядок підтвердження та зняття винятків.
• Інструкції для чергових — як читати звіт, що робити при критичній знахідці в опублікованому образі, як відкотитися на попередній тег.
• Схема інтеграції — на яких етапах конвеєра запускається перевірка, куди йдуть результати й як вони пов'язані з журналом збірки.
• Журнал рішень — розбір спірних знахідок із командою та точка розширення: куди додавати нові правила й як їх перевіряти.

Розбір: як закрили потік уразливих образів у продуктовій команді

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

Третина образів у реєстрі несла уразливості з готовим виправленням, а від виявлення до перезбирання минало дев'ять днів.

Що змінили

Сканування на Trivy поставили окремим кроком перед публікацією в реєстр — на тій самій збірці, що йде в прод. Збірка падає на критичних і високих знахідках, для яких є виправлена версія залежності; решта йде у звіт для розбору.

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

Що стало

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

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

Чим відрізняється перевірка в реєстрі від перевірки на збірці?

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

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

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

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

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

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

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

У реєстрі — регулярний перегляд зі звітом і зрозумілим правилом: який образ і в який строк перезбирати або відкликати.

Технічні сумніви інженерів: розбираємо заперечення

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

Сканер Trivy ставимо на етап збірки образу, до публікації в реєстр. Поріг блокування задаємо за рівнем критичності — збірка падає лише на тому, що справді потребує правки.

Як оформлюються винятки в правилах?

Перевірку цілком не вимикаємо. Виняток — це запис із пакетом, кодом уразливості та причиною, плюс строк, після якого він перестає діяти. Такі правки йдуть через рев'ю разом із кодом, а у звіті видно, скільки винятків активні й які прострочені.

Чи працює це в закритому контурі?

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

Де межа відповідальності?

Наша частина — збірка, налаштування сканера, пороги, зв'язка з реєстром і звіти. Ваша — пріоритизація знахідок і оновлення базових образів: сканер показує, що правити, рішення про патч ухвалює власник сервісу. Список фіксуємо на старті, щоб спірні знахідки не зависали.

Обговоримо задачу й повернемося з оцінкою та планом робіт

Для старту нам потрібен доступ до репозиторію та реєстру образів — на читання достатньо, щоб подивитися поточний конвеєр, Dockerfile-и й те, як збираються та публікуються артефакти.

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

Далі ми повертаємося не загальним «треба впровадити Trivy», а планом, де кожен пункт можна перевірити й прийняти:

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

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