Сканування образів через Grype: де губляться уразливості
Аналіз образу відбувається за шарами, і базовий шар майже завжди зафіксований на момент збірки. Syft знімає інвентар — перелік пакетів операційної системи та залежностей застосунку з їхніми версіями.
За цим переліком Grype зіставляє версії з базами уразливостей і видає знахідки з оцінкою критичності та зазначенням шару, з якого вони прийшли.
Розрив виникає між збіркою та перезбіркою. Застосунок оновлюється кожен реліз, а системні бібліотеки в базовому шарі залишаються незмінними місяцями.
Уразливість уже опублікована, базу оновлено, але в образі живе попередня версія пакета — і перевірка контейнерів під час викладки її не показує, якщо запускається за фактом готового образу, а не на етапі збірки.
Друга точка втрат — фільтри. Відсікання за рівнем критичності або вимкнення перевірки застарілого базового шару прибирає шум, але водночас приховує найчастіший клас знахідок: високий вплив за низької формальної оцінки.
Третя — формат результату. Плоский список зручний для читання й марний для управління: не видно, чи повторюється знахідка з релізу в реліз і чи закрилася вона після оновлення.
Інвентар складу прив'язує кожен запис до конкретного пакета та шару, тому зрозуміло, що саме потрібно оновити.
Розбираємо цей шлях за кроками: зняття інвентаря, налаштування порогів, автоматична перезбірка базових шарів — і показуємо, де саме уразливості в образах губляться.
Що дає регулярне сканування Docker-образів
Автоматичне сканування на етапі збірки перетворює безпеку контейнерів із ручної перевірки перед релізом на штатний крок конвеєра. Інструмент розбирає шари образу, звіряє пакети та їхні версії з базами уразливостей і видає знахідки до того, як образ потрапив до реєстру. Нижче — три ефекти, які видно вже через два-три релізи.
Вікно уразливості стискається до одного циклу збірки
Поки образ лежить у реєстрі й не перезбирається, уразливість у ньому живе місяцями: про знахідку дізнаються на черговому аудиті або після розбору інциденту.
За сканування під час збірки та за розкладом строк від публікації уразливості до її закриття в робочому середовищі падає з тижнів до одного-двох циклів — зазвичай у межах доби.
Ручне приймання релізу зникає
Політика за рівнями критичності («критичні — стоп збірки, високі — попередження й запис у звіт») дає формальний вердикт замість перегляду списку очима.
Реліз або проходить, або падає із зазначенням конкретного пакета та шару — приймання перестає бути вузьким місцем і не залежить від того, хто сьогодні на чергуванні.
Єдиний список знахідок за всіма реєстрами
Сканування всіх репозиторіїв однією конфігурацією дає єдиний формат звіту та єдиний поріг. Видно, прийшла уразливість із базового шару чи із залежностей застосунку: зрозуміло, хто править — команда супроводу базових образів чи розробник. Контроль базових шарів стає регулярним, а не разовим.
Ми налаштовуємо Grype разом із формуванням переліку компонентів образу — за ним знахідки можна переперевіряти та порівнювати між релізами.
Підходи до сканування образів: порівняння варіантів
Один режим перевірки майже завжди залишає діру. Перевірка під час збірки нічого не знає про те, що вже тижнями працює в кластері, а регулярний обхід розгорнутих образів не зупинить викладку уразливої збірки.
Причина в асиметрії: образ збирається один раз, а база відомих уразливостей оновлюється щодня — учорашній чистий образ сьогодні містить проблеми.
Нижче — чотири режими, між якими реально обирають, і межі застосовності кожного.
| Режим сканування | Коли підходить | Обмеження |
|---|---|---|
| На етапі збірки, блокувальний | Нові сервіси та активна розробка; потрібно не пропустити уразливість далі конвеєром | Ловить лише те, що відомо на момент збірки; хибні спрацювання гальмують релізи, якщо поріг суворий |
| Перед викладкою, за маніфестом | Регулярні релізи в кілька середовищ; потрібен контроль на вході в продакшн | Потребує доступу до реєстру та прав на зупинку викладки; не покриває образи, викладені в обхід конвеєра |
| Періодичний обхід розгорнутих образів | Уже працюючий контур, довгоживучі сервіси, вимоги комплаєнсу | Не запобігає — лише фіксує; потрібен розбір знахідок і план оновлення |
| Перевірка за збереженим переліком компонентів | Закриті контури без доступу до образів; розбір інциденту заднім числом | Перелік потрібно формувати заздалегідь і зберігати разом із релізом |
На практиці режими не конкурують, а доповнюють один одного: блокувальна перевірка під час збірки відсікає явний брак, періодична — піднімає те, що стало уразливим після викладки, а збережений перелік компонентів дозволяє за хвилини відповісти на питання «де ще зустрічається ця бібліотека», коли щодо неї виходить критичне повідомлення.
Grype і Syft працюють з одним і тим самим переліком компонентів, тому всі режими спираються на єдине джерело правди, а не на три неузгоджені звіти.
Впровадження Grype в конвеєр збірки образів: етапи робіт
Сканування образів вбудовуємо в конвеєр збірки, а не запускаємо окремим завданням за розкладом: перевірка відбувається до публікації образу в реєстр, інакше дефект уже в продакшені.
Syft збирає склад пакетів за шарами, Grype зіставляє його з базами уразливостей, а збірка отримує код повернення, за яким вирішується — пропускати образ далі чи зупиняти. Порядок робіт вибудувано так, щоб на момент увімкнення блокувань команда розуміла кожне спрацювання.
- Інвентаризація образів. Збираємо перелік сервісів, базових шарів і зовнішніх залежностей — без нього пороги блокувань ставляться навмання й зупиняють збірку на першій же зміні.
- Схема інтеграції. Визначаємо точку виклику в конвеєрі (після збірки, до публікації), спосіб зберігання звітів і локального дзеркала баз уразливостей, поведінку на вузлах без доступу до зовнішньої мережі.
- Налаштування Grype. Задаємо набір джерел уразливостей, формати виводу — читабельний для логів, машинозчитуваний для розбору, — та винятки для вочевидь незастосовних спрацювань зі строком перегляду.
- Пороги блокувань і політики безпеки. Рівні критичності розділяємо: збірка падає на уразливостях із доступним виправленням і високим ризиком, решта йде у звіт і в чергу на усунення. Пороги калібруємо за реальним складом образів, щоб не отримати стіну хибних зупинок.
- Перевірка на бойових збірках. Проганяємо на чинних сервісах: заміряємо час доданого кроку, частку спрацювань і вартість підтримки баз у закритому контурі.
- Передача регламентів. Віддаємо опис політик, інструкцію з розбору спрацювань і порядок дій при зупиненій збірці — команда змінює пороги та винятки самостійно.
Після передачі ведемо супровід: оновлення баз, перегляд винятків і правка порогів у міру зміни складу сервісів.
Політики сканування, регламенти та пороги блокувань
Сканування без регламенту швидко перетворюється на фон: звіти формуються, знахідки накопичуються, а рішення щодо них ухвалюються щоразу заново.
На момент увімкнення Grype в конвеєр команда отримує пакет артефактів, де в кожного правила є власник, строк і зрозумілий спосіб заперечити — інакше перше ж блокування збірки навчить інженерів обходити перевірку, а не виправляти причину.
- Конфігурація сканування: файл політики з порогами за рівнями критичності, переліком перевірюваних шарів і режимом роботи для кожної гілки — де достатньо попередження, а де збірка зупиняється.
- Матриця пріоритетів: які знахідки закриваються в найближчому релізі, які йдуть у плановий порядок, а які припустимо прийняти як відомий ризик.
- Список винятків уразливостей: кожен запис з обґрунтуванням, відповідальним і датою перегляду — виняток перестає бути вічним і повертається в роботу автоматично.
- Регламент реагування: хто отримує повідомлення, за який час підтверджує знахідку, як випускається виправлений образ і за яких умов блокування знімається.
- Документація зі сканування: де зберігається склад образу, знятий Syft, як відтворити перевірку локально тими самими правилами та як читати звіт під час розбору інциденту.
- Звітність за образами: зведення за репозиторіями та тегами — частка образів без критичних знахідок, динаміка за тижнями, перелік прострочених винятків.
- Порядок ревізії: плановий перегляд порогів і винятків, а також позаплановий — після зміни базового образу або появи виправлення у постачальника компонента.
- Ролі та точка ескалації: хто володіє політикою і хто ухвалює рішення, коли знахідка конфліктує зі строком випуску.
Такий пакет залишається в команди, а не в підрядника: перевірку можна перезапустити, пороги — обґрунтувати, а будь-який виняток — зняти однією правкою конфігурації.
Кейс: скоротили частку неперевірених образів у рази
До робіт образи збиралися вручну, а сканування запускалося від випадку до випадку — зазвичай перед великим релізом. Реєстр при цьому зростав швидше, ніж хтось устигав переглядати його вміст, і знахідки спливали вже в експлуатації: за фактом інциденту або звернення.
Що було до впровадження
Замір базової картини дав конкретні цифри: під регулярною перевіркою перебувала приблизно десята частина образів, решта жили в реєстрі без контролю.
Час реакції на нову уразливість у використовуваному пакеті вимірювався тижнями, а визначити, в якому саме образі сидить проблемна бібліотека, можна було лише ручним розбором.
Що змінили
У конвеєр збірки додали два кроки. Syft розбирає образ на перелік пакетів із версіями, Grype звіряє цей перелік із базами уразливостей і видає знахідки з рівнем критичності.
Звіт став обов'язковим артефактом: без нього образ не потрапляє до реєстру, а критичні знахідки блокують просування в середовище експлуатації. Окремо прогнали накопичений реєстр — старі знахідки розібрали за пріоритетом, а не «колись».
Що стало
Частка неперевірених образів скоротилася до одиниць відсотків — поза контролем залишаються лише локальні збірки, які не покидають машини розробників.
Час реакції на критичну знахідку стиснувся до годин: вона приходить разом із результатом збірки, а не після інциденту в експлуатації. Метрики безпеки знімаються автоматично, і зростання реєстру більше не означає зростання сліпої зони.
Чим сканування шарів відрізняється від перевірки файлової системи?
Образ — це не монолітний зліпок, а стек шарів: кожен додає або перекриває файли попереднього. Сканування шарів читає маніфест і зібраний перелік пакетів, тому бачить, який менеджер пакетів поставив компонент, у якому шарі він з'явився і що притягнуло його транзитивною залежністю. Відповідь приходить із походженням, а не лише з номером версії.
Перевірка файлової системи контейнера працює з тим, що реально змонтовано й доступно процесу: розпаковані бінарники, бібліотеки, файли, покладені копіюванням в обхід менеджера пакетів.
Зате родоводу вона не знає — за знахідкою не видно, з якого шару вона прийшла і чи оновлювалася пізніше.
Різниця підходів видна на двох класах помилок. Перевірка за шарами покаже компонент із нижнього шару, навіть якщо верхній його замінив або видалив, — у звіті спливає вже неіснуюча версія.
Файлова система маркери видалення не враховує й описує фінальний стан, але пропускає все, що не дожило до робочого контейнера.
Тому охоплення збирають із двох джерел: перелік пакетів формується за шарами на етапі збірки, а готова файлова система перевіряється після — як страховка від ручних копіювань і розпакувань.
Grype зіставляє знахідки з базою уразливостей, але повнота звіту залежить від того, чим зібрано перелік і за яким джерелом — образ цілком, директорія чи окремий шар. Ми налаштовуємо обидва режими й розводимо знахідки, щоб звіт не тонув у хибних спрацюваннях.
Технічні обмеження та питання зі сканування образів
Сканування образу вбудовується в збірку й одразу піднімає чотири інженерні питання: скільки часу воно додає, що робити з уразливостями без виправлення, як відсікати хибні спрацювання та чи потрібна перезбірка після оновлення баз. Нижче — як ми відповідаємо на кожне.
Чи сповільнить сканування збірку?
Syft розбирає шари образу й складає перелік пакетів, Grype звіряє його з базою уразливостей. Основний час іде на читання шарів, а не на пошук, тому перевірка йде паралельно з іншими кроками й на типовому образі не змінює загальний час випуску.
Що робити з уразливостями, для яких немає виправлення?
Частина знахідок — у пакетах, де постачальник ще не випустив оновлення, і встановленням нової версії їх не закрити. Такі випадки не блокують випуск: правила налаштовуються за рівнями небезпеки, а невиправне йде до списку прийнятого ризику з датою перегляду.
Як відсікати хибні спрацювання?
Хибне спрацювання виникає, коли збіг іде за іменем пакета, а не за фактично зібраним кодом. Лікується винятками з обґрунтуванням і прив'язкою до номера уразливості — правило живе в репозиторії, його видно на review і можна відкликати.
Чи потрібна перезбірка при оновленні баз?
Ні. База уразливостей зберігається окремо від образу: повторне сканування вже зібраних тегів дає свіжу картину без випуску нових версій. Перезбірка потрібна лише при зміні базового образу або самих правил.
Обговоримо задачу: сканування ваших образів і пороги блокувань
Щоб оцінка задачі спиралася на вашу схему збірки, а не на усереднені цифри, розбір починаємо з того, як образи з'являються й живуть у вас.
Надішліть файли збірки, вивантаження маніфестів із реєстру, перелік базових образів і порядок випуску релізів — за ними видно, на якому кроці сканування Grype і Syft вбудовується, не зупиняючи випуск.
Після розбору ви отримуєте:
- карту поточного потоку: від коміту до публікації образу в реєстрі й далі до стенда;
- перелік базових образів і шарів з оцінкою уразливостей за кожним;
- запропоновані пороги блокувань за рівнями критичності та правило їх перегляду;
- схему придушення хибних спрацювань із журналом винятків і строками, коли запис спливає;
- варіант вбудовування — на збірці, у перевірці перед злиттям або в реєстрі — з обґрунтуванням вибору;
- план робіт етапами, де зазначено, на яких кроках випуск можна зупинити, а на яких ні;
- список того, що потрібно від ваших інженерів: доступи, сервісні облікові записи, вікна змін.
Опишіть задачу як зручно: абзацом у листі або коротким дзвінком із вашим інженером. Ми повернемося з оцінкою, планом робіт і зрозумілою картиною того, що зміниться у випуску після впровадження безпеки контейнерів.
