Anchore Engine: де дає збій перевірка Docker-образів
Збірка одна, а базовий образ тягнеться з чужого реєстру: уразливості в образах потрапляють у робочий контур не з вашого коду, а з шару, який ви не збирали й ніколи не оновлювали.
Перевірка при цьому тримається на ручному перегляді маніфесту перед релізом — і закінчується рівно там, де починається поспіх.
Ламається це на масштабі. Плаваючий тег указує на різні образи в різні дні, кеш закріплює старий шар, залежності ставляться за файлом фіксації версій місячної давності.
Патч у базовому шарі давно вийшов, перезбирання не було — і уразливість залишилася в проді, хоча формально склад сервісу не змінювався.
Anchore Engine закриває саме цю діру: сканування docker-образів іде за контрольною сумою, а не за тегом, а сам образ розбирається на шари з інвентаризацією пакунків системного менеджера та мовних залежностей.
Контроль базових шарів тримається на політиці: поріг за критичністю, білі та чорні списки пакунків, заборона на випуск збірки, що не пройшла перевірку в поточній редакції.
Різниця видна не у звіті, а в точці перед викаткою. Перевірка до запису в реєстр зупиняє збірку; перевірка після — залишає артефакт у реєстрі й перетворює розбір на ручну роботу чергового. Нижче розбираємо, як це закривається на практиці й що саме ламається найчастіше.
Що дає сканування образів у конвеєрі збірки
Перевірка образів дає ефект лише тоді, коли вбудована в конвеєр збірки: звіт по образу, який зібрали вручну раз на місяць, не впливає на те, що йде в продакшн.
Ми ставимо Anchore Engine на етап збірки й прив’язуємо його вердикт до правил допуску — тоді безпека контейнерів перестає бути окремою задачею й стає умовою випуску релізів. Нижче — чек-лист результатів, за якими видно, що перевірка працює, а не створює видимість.
- Покриття збірок. Раніше перевіряли вибірково, на запит або перед великим релізом; тепер вердикт отримує кожен образ до публікації в реєстрі. Образ без висновку просто не потрапляє далі.
- Час на ручну перевірку. Розбір звіту займає хвилини замість годин ручного перегляду списку пакунків і маніфестів. Зауваження приходить тому, хто збирає образ, а не тому, хто потім чергує вночі.
- Перевірка залежностей за шарами. Видно конкретний пакунок і його версію, через які збірка не проходить. Правка зазвичай зводиться до одного рядка в описі збірки, а не до перезбирання сервісу цілком.
- Зникаючий клас відмов. Правило допуску блокує публікацію образу з критичним рівнем уразливості — сценарій «у продакшн поїхало те, що ніхто не дивився» закривається на етапі збірки.
- Винятки під контролем. Замість мовчазної згоди — запис із причиною та строком перегляду. Реєстр винятків із часом скорочується, бо кожен видно на спільній панелі.
- Тренд замість разового зрізу. За релізами видно, чи зростає кількість уразливостей і що саме його тягне: старіючий базовий образ чи конкретна бібліотека. Це вже підстава для планової заміни, а не для авралу.
Поріг спрацювання та список винятків налаштовуємо під сервіс: для внутрішнього інструмента й для публічного API рівні допуску різняться.
Режими сканування образів та їхні обмеження
Anchore Engine не вмикають одним перемикачем — спочатку обирають точку, де ухвалюється рішення про долю образу. Один і той самий движок дає різний результат залежно від глибини розбору шарів, моменту запуску та порогу, за якого випуск зупиняється.
Режими та їхні межі
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повний розбір шарів | Аудит випуску, розбір інциденту, підготовка до зовнішньої перевірки | Найповільніший: на великих образах іде хвилинами й потребує свіжої бази уразливостей |
| Швидка перевірка на вході в реєстр | Відсікти явно проблемний образ до викатки | Поверхнева: розбирає маніфест і базові шари, власні шари майже не бачить |
| Перевірка за розкладом | Знайти нові уразливості в образах, які вже лежать у реєстрі | Між запусками образ вважається чистим, до випуску не прив’язана |
| Сканування за тригером випуску | Гейт у конвеєрі перед викаткою в середовище | Потрібні пороги й права на реєстр; надто жорсткий поріг зупиняє випуски |
Без порогових правил будь-який режим дає звіт, але не рішення. Поріг визначає, що вважати блокуючим: рівень критичності та наявність виправленої версії пакунка. Винятки виносять у правила з датою перегляду — інакше вони перетворюються на постійний обхід перевірки.
Порядок впровадження: від аудиту реєстру до передавання регламентів
Сканування образів дає ефект лише коли вбудовано в контур постачання: реєстр підключено, пороги зафіксовано, а вердикт перевірки зупиняє викладення уразливої збірки. Тому починаємо з інвентаризації — без неї правила або пропускають критичне, або блокують усе підряд.
- Аудит реєстру образів. Збираємо перелік репозиторіїв і активних тегів, позначаємо архівні та дублі. На виході — карта парку з пріоритетом: що перевіряємо на кожній публікації, що разово.
- Схема підключення до реєстру. Розгортаємо Anchore Engine поруч із реєстром, видаємо обліковий запис лише на читання й налаштовуємо забір образу за подією публікації тега — нова збірка одразу стає в чергу на перевірку.
- Правила та пороги. Розділяємо знахідки за критичністю та типом: уразливості у виконуваному шарі, застарілі пакунки, секрети всередині шарів. Поріг блокування підбираємо так, щоб він ловив реальний ризик, але не спрацьовував на кожній залежності.
- Винятки. Для знахідок, які не можна закрити швидко, фіксуємо адресний виняток зі строком і власником замість загального пропуску правила.
- Обкатка на живих збірках. Проганяємо перевірку на поточних гілках без блокувань, звіряємо вердикти з ручним розбором, прибираємо хибні спрацювання.
- Блокуючий режим. Перевірка стає воротами перед викладкою: образ із критичною знахідкою не йде в продуктивний контур, відкат залишається на попередній перевірений тег.
- Передавання регламенту перевірок. Віддаємо матрицю порогів, порядок розбору знахідок, правила винятків та інструкцію з оновлення бази уразливостей.
Артефакти впровадження: конфігурації, схеми та регламенти
Впровадження закінчується не звітом, а працюючим контуром на вашій стороні.
Anchore Engine розгортається у вашій інфраструктурі, тому налаштування, правила та інструкції залишаються у вашої команди — щоб змінити поріг блокування або підключити новий реєстр, не потрібно звертатися до нас.
- Файли конфігурації — параметри сканера, джерела баз уразливостей, розклад обходу образів, глибина та строк зберігання результатів.
- Схема інтеграції — ланцюжок «реєстр → збірка → сканування → допуск до викатки» з точками відмови й описом поведінки, коли сканер недоступний.
- Політики блокування — які класи уразливостей зупиняють випуск, що йде у винятки, з яким строком перегляду й хто їх знімає.
- Регламент реагування — рівні критичності, строки реакції чергової зміни, порядок ескалації, шаблон запису про інцидент.
- Інструкції з експлуатації — оновлення баз уразливостей, ротація доступів до реєстру, перевірка працездатності, розбір типових відмов.
- Звіт за базовою лінією — які образи вже порушують політику на момент здавання й який обсяг роботи належить закрити.
- Матриця ролей і доступів — хто змінює політику, хто лише читає звіти й як ці дії логуються.
Усе передається у версіонованому вигляді: правки політик проходять через той самий процес перевірки, що й код, а історія змін залишається відновлюваною.
Кейс: прибрали уразливі образи з продакшену
Замовник — продуктовий контур із кількох десятків сервісів, релізи щотижня. Збірка образів була налагоджена, а от перевірка складу — ні: маніфест базового шару та залежності не аналізувалися, тому уразливий пакунок міг дійти до робочого контуру й жити там місяцями.
Знаходили таке зазвичай не ми, а зовнішній сканер периметра або розбір інциденту, коли виправляти вже пізно й дорого.
Ми вбудували сканування у збірку: Anchore Engine розбирає образ пошарово й показує, у якому пакунку та на якому шарі прийшла уразливість. Політика зупиняє збірку за критичних знахідок, для яких є виправлення; решта йде у звіт із пріоритетом і призначеним строком. Оновлення баз уразливостей іде за розкладом, тому вердикт по образу не застаріває.
Метрики до та після
До: перевірку не проходив жоден образ, дев’ять із десяти критичних знахідок виявлялися вже в робочому контурі, середній час від появи уразливості до виправлення — близько тижня.
Після: через сканування проходить кожен образ, вісім із десяти критичних знахідок гасяться до публікації в реєстрі, реакція на нову уразливість у використовуваному пакунку — години, а не дні.
Для циклу випуску це дало передбачуваність: позапланові випуски лише з безпеки скоротилися втричі, відкатів через уразливий шар не було жодного. Команда перестала витрачати час на розбір того, що мало відсікатися на збірці.
Чим Anchore Engine відрізняється від сканерів у реєстрах
Вбудований сканер реєстру перевіряє образ у момент відправлення й не пускає його далі за списком відомих уразливостей. Окремої інфраструктури це не потребує, поріг спрацювання задає провайдер.
Далі починаються обмеження: свої правила допуску задати не можна, звіту за складом пакунків немає, а історія знахідок зникає разом із перезаписаним тегом.
Anchore Engine — окремий сервіс: розбирає образ на шари, збирає список пакунків і версій операційної системи та оцінює його за правилами, які пише ваша команда.
Перевірка йде не лише при відправленні, а й за розкладом — новий запис у базі уразливостей переводить уже випущений образ у статус «є знахідки» без перезбирання.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудований сканер реєстру | Один реєстр, одна команда, потрібна лише заборона на вході | Правила задані провайдером, немає історії знахідок і звіту за складом |
| Відкриті сканери, що запускаються вручну | Разовий аудит перед випуском або перевірка чужого образу | Немає стану між запусками, результат не відтворюється |
| Anchore Engine у вашому контурі | Кілька реєстрів, свої правила допуску, регулярна переперевірка вже випущених образів | Потрібні сховище бази уразливостей і обслуговування сервісу |
Різниця не в кількості знайденого. Вбудована перевірка відповідає на питання «чи пускати образ прямо зараз», окремий сканер веде інвентар: видно, які пакунки всередині, хто підтвердив виняток і що змінилося після оновлення бази.
Технічні питання про сканування образів
Питання в команд майже завжди одні й ті самі: чи заробить Anchore Engine у закритому контурі, чи не подовжить перевірка збірку, як жити з шумом спрацювань і що робити з уже запущеними контейнерами. Нижче — як кожне з цих місць закривається в конфігурації.
Закритий контур без виходу назовні — сканування заробить?
Так. База уразливостей заїжджає всередину пакунком змін через внутрішнє дзеркало: джерело оновлюється на периметрі, а в контур іде лише готовий набір даних. Образи та відомості про пакунки назовні не передаються.
Перевірка подовжить збірку?
Лише якщо залишити її на критичному шляху. Скан запускається паралельно збірці наступного образу або одразу після публікації тега — на окремому вузлі. Конвеєр не чекає вердикту: звіт приходить асинхронно, тривалість збірки не змінюється.
Хибні спрацювання заблокують випуск?
Блокування спрацьовує лише на вибраному рівні критичності. Решта закривається правилами винятків: конкретний ідентифікатор уразливості, версія пакунка, строк дії запису й обов’язкова відмітка в журналі. Тихого вимкнення перевірок не виходить.
Що робити з уже розгорнутими образами?
Перезбирати весь парк одразу не потрібно. Спочатку інвентаризація працюючих тегів, потім планове пересканування за розкладом і сортування знахідок за досяжністю під час роботи. У реліз потрапляє те, що справді використовується.
Обговоримо задачу сканування ваших образів
Щоб повернутися з оцінкою робіт, а не із загальними словами, нам потрібні вхідні дані по вашому контуру.
Сканування образів через Anchore Engine налаштовується під конкретну інфраструктуру: одна й та сама політика на різних складальних контурах дає різний обсяг знахідок і різний час збірки. Тому спочатку збираємо картину, а вже потім пропонуємо план впровадження й підбір режиму.
- Реєстр і доступи: який реєстр використовується, скільки репозиторіїв і тегів активні, які права на читання образів можна видати.
- Складальний контур: де і чим збираються образи, чи є окремі гілки під релізи й як часто виходять нові версії.
- Базові шари: публічні базові образи чи внутрішні, чи є вимоги до їхнього походження.
- Вимоги безпеки: які класи уразливостей критичні, чи потрібен контроль ліцензій і секретів у шарах, хто затверджує винятки.
- Поріг відмови: який рівень знахідок блокує випуск, а який лише потрапляє в журнал для розбору.
- Інтеграції: куди складати звіти й як повідомляти команди — пошта, задачі, чат, панель.
- Зона відповідальності: що закриваємо ми, а що залишається на вашій стороні під час експлуатації.
Опишіть задачу в зручному форматі — повернемося з оцінкою робіт, планом впровадження й підбором режиму перевірок під ваш контур.
