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

Порушення, яке ми отримали, і те, що нас чекає

У вересні 2025 року десятки популярних пакетів JavaScript, таких як chalk і debug, були скомпрометовані в реєстрі npm. Ці пакети такі поширені, що вони потрапляють у все: фронтенд-застосунки, бекенд-мікросервіси та CI-інструменти. Розробники не зробили нічого поганого, вони просто виконали ту ж команду, яку завжди вводять: npm install chalk. Але потім програмне забезпечення з шкідливим кодом прийшло непомітно.

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

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

Це було тільки npm. Тепер уявіть собі таку ж техніку, що націлюється на системні бібліотеки, на які залежать ваші контейнери, перш ніж ваш додаток взагалі запуститься, такі як libcurl, zlib або openssl. Це компрометує основу під всім рештою, що ви запускаєте або створюєте.

Ласкаво просимо до температурної проблеми безпеки ланцюга постачання. Індустрія відправляє код, який все ще занадто гарячий, щоб з ним працювати.

Дві філософії для створення контейнерів

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

Підхід до нічного перезбірки

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

Але якщо джерело отруєне?

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

Ви подаєте код прямо з «верхньої» печі. Без решітки для охолодження. Без часу на відпочинок. Ніхто не перевірив температуру.

Процес навмисного оновлення

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

Це не помпезно, але спокійно, задумливо і передбачувано.

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

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

Цей контейнер може працювати на версії curl з 2022 року, не тому, що Ubuntu відстає, а тому, що розробники точно знають, що ця версія робить. І, що більш важливо, чого вона не робить. Вона охолола давно. А охолоджений код – це прогнозований код.

Хто перший випустить задній шлях?

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

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

Навмисна модель оновлення, така як Ubuntu? Закріплена версія старіша, але вона передбачувана і стабільна. Розробники Ubuntu дають коду охолонути, і отрута розкривається в верхньому рівні, перш ніж вона взагалі досягне тарілки.

Проблема нульового CVE

Сканери безпеки люблять відзначати CVE. Знайшли один? Ви в небезпеці. Нуль знайшли? Все у порядку.

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

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

Справжня безпека заробляється повільно

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

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

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

Коли свіжість стає зобов’язанням

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

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

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

Перезбірка не є перевіркою

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

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

Інший вид CVE

Коли всі гоняться за «нулевими відомими CVE», ми ігноруємо ширші ризики. Ми перестаємо запитувати: «Чи вразливий цей образ?» Нам потрібно почати запитувати: «Чи занадто довірливий цей образ?»

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

Висновок

Це не про жодного конкретного постачальника чи проект. Це про те, як індустрія ставиться до довіри та температури.

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

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

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