Сканування контейнерів: де ламається контроль образів
Базовий образ у проєкті зазвичай не ревʼюють: інженер бере публічну збірку, додає залежності застосунку і надсилає до реєстру.
Оновлення «чужої» базової збірки минає непомітно — її немає в дереві проєкту, ніхто не дивиться її шари, а тег залишається тим самим, змінюється лише вміст під ним.
За тижні сканування контейнерів показує критичну вразливість у системному пакеті, якого немає у вихідних кодах застосунку. Вона прийшла з базового шару — і на тій самій збірці стоять ще десятки сервісів. Патч одного сервісу нічого не закриває: наступний реліз сусіда збереться поверх тієї самої діри.
Контроль образів перед викочуванням пробують робити руками: подивитися тег, пробігти список пакетів, звірити з минулим релізом.
На кількох десятках сервісів і двох-трьох середовищах це не відтворюється — результат залежить від того, хто чергує, а історія шарів ніде не зберігається. Уразливі образи в продакшені живуть не тому, що їх не шукали, а тому що шукали один раз і не там.
Ціна: екстрений відкат у розпал інциденту, позаплановий випуск і ручний обхід реєстру, щоб оцінити масштаб. Частина сервісів залишається на старій збірці місяцями — її потрібно перезібрати, перевірити і викотити, а це ручна робота на кожен сервіс окремо.
Розбираємо, як це закривається: де у збірці зʼявляється обовʼязковий шлюз, що він перевіряє до викочування і як ловиться вразливість, що прийшла з чужої базової збірки.
Що дає рання перевірка образів у конвеєрі
Рання перевірка образів зміщує точку контролю вліво: сканування відбувається одразу після збірки, до публікації в реєстр. Сканер розбирає шари й маніфест, звіряє системні пакети та залежності застосунку з базою вразливостей і віддає знахідки з рівнями критичності. На цьому етапі збій коштує перезбірки, а не відкату релізу.
Політика збірки відсікає знахідки високого й критичного рівня в тих шарах, що потрапляють у середовище виконання; зауваження до залежностей рівня розробки залишаються попередженням. Так зникає цілий клас відмов — уразливий базовий образ, забутий пакет, бібліотека без оновлень.
Пороги блокування ми налаштовуємо за класифікацією ризиків контейнерного середовища, описаною в OWASP: це дає спільну мову з командою безпеки замість ручних домовленостей.
Час викочування при цьому не зростає: перевірка йде паралельно тестам, скануються лише змінені шари, а незмінний базовий образ береться з кешу. Результат приходить раніше, ніж завершується збірка, — окремого етапу очікування в конвеєрі немає. Реліз, який раніше потрапляв в експлуатацію і відкочувався, тепер просто не проходить далі.
Час реакції на інцидент визначається не швидкістю сканера, а наявністю інвентарю. До кожного образу привʼязаний перелік компонентів з версіями, тому при появі відомостей про нову вразливість ми знаходимо всі уражені образи одним запитом, а не перебором реєстру вручну. Далі — перезбірка на виправленому базовому шарі, і відкат на попередній тег залишається доступним.
Підсумок: контроль переноситься туди, де виправлення дешевше, а дані про склад образу залишаються під рукою в момент інциденту.
Способи сканування контейнерів: порівняння режимів
Режими різняться тим, на якому етапі життєвого циклу образу виконується перевірка і який шар вона бачить.
Перевірка під час збірки ловить вразливості до публікації, перевірка в реєстрі образів страхує теги, що прийшли ззовні, а періодична інвентаризація знаходить те, що вже працює на стендах. Тому сканування контейнерів вибудовують як послідовність режимів, а не обирають один.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Під час збірки образу | Власний код, контроль на вході: конвеєр зупиняється на критичних знахідках | Уповільнює збірку; не бачить образи, зібрані поза конвеєром |
| Під час публікації в реєстр | Кілька команд і спільний реєстр: єдина політика для всіх тегів | Реагує після факту збірки; потрібна інтеграція з реєстром |
| Перед викочуванням | Кластери з жорсткими вимогами: запуск відхиляється до проходження політики | Крихко: ламає викочування при зміні правил, потрібен список винятків |
| Періодична інвентаризація запущеного | Довгоживучі стенди: видно фактичний стан, а не намір | Запізнюється: образ уже працює, поки триває перевірка |
Спільне обмеження перевірок — база вразливостей оновлюється, і вчора чистий образ сьогодні отримує критичні знахідки. Крім того, перевірка не розрізняє бібліотеку, яка реально викликається під час роботи, і мертвий код.
Тому політику будують на пріоритетах: блокувати лише те, для чого вже є виправлена версія, решту — у чергу з фіксованим терміном усунення.
Як ми вбудовуємо перевірки в конвеєр: етапи робіт
Порядок етапів залежить від того, як влаштований ваш конвеєр збірки: де збирається образ, як потрапляє до реєстру, хто має право його публікувати. Вбудовуємо сканування контейнерів так, щоб крок перевірки не розтягував збірку і не зупиняв релізи на хибних спрацюваннях.
- Аудит конвеєра збірки. Розбираємо стадії, де формуються образи, і які політики доступу до реєстру вже діють. Фіксуємо час збірки до змін — це точка відліку для оцінки накладних витрат.
- Схема перевірок образів. Визначаємо, що і на якому кроці перевіряємо: базовий шар, залежності, облікові дані в шарах, конфігурацію запуску. Швидкі перевірки — на кожен коміт, повний розбір — на релізну гілку.
- Налаштування правил допуску. Критичні вразливості блокують публікацію, середній рівень іде в чергу на розбір. Винятки оформлюємо письмово, з причиною і терміном перегляду, інакше правила швидко стають формальністю.
- Перевірка на стенді. Проганяємо сценарій на реальних образах проєкту: заміряємо доданий час, дивимося частку хибних спрацювань і перевіряємо відкат на попередню збірку.
- Передача регламентів. Опис схеми, порядок читання звітів, правила оновлення бази вразливостей і матриця відповідальності: хто розбирає зауваження і як змінювати пороги без правки самого конвеєра.
Політики допуску, звіти та схеми: що залишається команді
Сканування перестає бути разовою перевіркою, коли спирається на артефакти, які живуть у репозиторії та внутрішній базі знань. Нижче — той мінімум, з яким чергова зміна і реліз-інженери працюють без нашої участі.
- Конфігурації перевірок у репозиторії: етапи збірки, пороги критичності, правила винятків для хибних спрацювань і зовнішніх залежностей.
- Політики допуску образів — які рівні вразливостей блокують випуск, що проходить за винятком і хто підписує його на строк.
- Окремі правила для службових і прикладних образів, щоб випуск не зупинявся через знахідки, не застосовні до ролі контейнера.
- Схеми конвеєра: місце перевірки в ланцюжку і реакція на спрацювання — зупинка, попередження або випуск із позначкою.
- Шаблони звітів щодо вразливостей: склад знахідок, пріоритет, відповідальний, термін усунення, ознака повторної появи.
- Інструкції для чергової зміни: як читати звіт, що робити при блокуванні перед релізом і за якою ознакою ескалювати.
- Регламент синхронізації баз вразливостей і ревізії винятків — щоб тимчасове послаблення не стало постійним.
Артефакти лежать поруч із кодом і повʼязані зі схемою конвеєра: під час правки політики одразу видно, які перевірки зачеплені. Рішення про допуск образу стає відтворюваним — його ухвалює описане правило, а не конкретний інженер.
Кейс: як прибрали вразливі образи з викочування
Що було
Образи збиралися тими самими завданнями, що й зараз, але вразливості спливали вже на проді — їх знаходив сканер периметра або інцидент.
Зауваження служби безпеки накопичувалися окремим реєстром: критичних набралося кілька десятків, термін закриття сягав трьох тижнів, бо оновлення базового шару тягнуло перезбірку залежних сервісів.
Що змінили
Перевірку поставили між збіркою та надсиланням образу до реєстру, звіт на базі Trivy розклали на два пороги. Критичні вразливості з доступним виправленням блокують викочування, середні йдуть завданням із терміном, хибні спрацювання гасяться винятками у файлі політики. Обійти поріг можна лише правкою політики — це залишається в історії змін.
| Показник | До | Після |
|---|---|---|
| Частка відхилених образів | блокування не було | 17–20% збірок |
| Від виявлення до виправлення | 2 доби | 3–5 годин |
| Закриття зауважень безпеки | до 3 тижнів | 2–4 дні |
| Критичні вразливості в проді | десятки | одиниці |
Сканування додало до збірки близько сорока секунд — ціну прийняли свідомо, бо термін викочування визначало очікування перевірок, а не збірка.
Частка відхилених образів стабілізувалася не одразу: спочатку відхилялася майже чверть збірок, потім сервіси перейшли на підтримувані базові образи, і показник тримається на одному-двох релізах на тиждень.
Чим перевірка базового образу відрізняється від перевірки шарів?
Перевірка базового образу відповідає на питання, чи не приїхала вразлива спадщина з батьківського шару. Сканер іде маніфестом і звіряє версії пакетів дистрибутива: вердикт майже не залежить від вашого коду і змінюється, коли оновлюється сам базовий образ.
Перевірка шарів додає все, що ви доложили зверху: зібрані бінарники, залежності застосунку, скопійовані конфіги. Сканери на кшталт Trivy читають історію шарів, і тут же спливають секрети — файл, видалений у наступному шарі, залишається в попередньому і дістається з реєстру. Тому контроль базового образу не скасовує пошарову перевірку.
Третій рівень — перевірка запущеного екземпляра. Вона бачить фактично змонтовану файлову систему, права процесу і підключені томи, включно з пакетами, доустановленими під час старту.
Суворість правил зростає разом із рівнем: на базовому образі збірку валять за критичними, на шарах — попереджають і вимагають розбору, на запущеному екземплярі блокують викочування лише за досяжними вразливостями.
Часті технічні сумніви перед упровадженням перевірок
Інженерні заперечення перед упровадженням перевірок зазвичай ті самі: аналіз уповільнить збірку, підніме шум хибними спрацюваннями і змусить перезбирати вже випущені образи. Нижче — як кожне з них закривається на практиці, без зупинки випуску.
Як гасити хибні спрацювання?
Ми не сперечаємося зі знахідками, а налаштовуємо політику: правила винятків із зазначенням пакета, шляху і причини, обовʼязковим терміном перегляду та власником. Блокують випуск лише вразливості критичного і високого рівня, решта йде у звіт і розбирається за планом. Так черга заявок на «вимкніть перевірку» не зростає.
Наскільки перевірка уповільнить збірку?
Базовий образ сканується один раз і перевикористовується з кешу, на кожній збірці перевіряється лише змінений шар — тобто новий код і оновлені залежності.
Повний обхід запускається за розкладом, а не на кожен коміт, тому зростання часу збіркового завдання вимірюється секундами, а не хвилинами.
Що робити з уже опублікованими образами?
Вмикаємо режим спостереження: реєстр обходиться повністю, знахідки складаються у звіт, випуск не блокується.
Далі за критичними знахідками йде окремий план заміни, а ворота з блокуванням вмикаються лише для нових збірок — старі теги живуть до планового оновлення, без аврального переписування релізу.
Чи можна перевірити сторонні образи постачальника?
Так, але довіряти чужому звіту не можна: перевіряємо базовий шар і залежності своїми правилами, а непрозоро зібрані базові образи перезбираємо в себе з вихідних кодів.
Теги фіксуємо за контрольною сумою образу, інакше постачальник підмінить вміст під тим самим іменем, і перевірка втратить сенс.
Чи доведеться міняти свій інструмент сканування?
Ні. Наявний сканер підключається як окремий крок збіркового ланцюжка, а звіти приводяться до єдиного вигляду — спрацювання з різних джерел потрапляють в одну чергу. Заміну робимо лише якщо інструмент не вміє потрібний формат виводу або не закриває потрібні класи вразливостей.
Обговорімо задачу: з чого починається впровадження перевірок
Упровадження перевірок починається не з налаштування сканера, а з інвентаризації: що вже збирається, з яких базових образів і куди потрапляє під час випуску.
Перший етап — доступи й розбір поточного конвеєра, бо політики, написані без розуміння розгалуження та порядку збірки, блокують релізи замість того, щоб їх захищати.
План робіт із конвеєром будується хвилями: спочатку перевірка на етапі збірки в режимі спостереження, потім — блокувальні правила для критичних сервісів.
Щоб повернутися з оцінкою і планом, а не із загальними словами, нам потрібен від вас короткий стартовий набір:
- читальний доступ до репозиторіїв і налаштувань розгалуження — бачимо, де точки входу і хто має право змінювати правила;
- доступ до реєстру образів із правом читати метадані тегів та історію шарів;
- опис поточного конвеєра: етапи, тригери, хто і як випускає у промислове середовище;
- відповідальний за правила — інженер, який ухвалює рішення щодо порогів критичності та винятків;
- перелік сервісів, які не можна зупиняти, і перелік тих, де припустимий блокувальний режим;
- відомості про базові образи: свої чи публічні, хто відповідає за їх оновлення;
- контакт для приймання — той, хто підтвердить, що перевірка не ламає випуск.
Опишіть задачу у двох-трьох абзацах: скільки сервісів, який конвеєр, де зараз проходить межа між збіркою і випуском.
Ми повернемося з оцінкою термінів, послідовністю етапів і тим, що ви отримаєте на кожному кроці — від першого прогону в режимі спостереження до блокувальних політик.
