Проблема постачання, пов’язана з охолодженням контейнерів перед відправкою

Вразливість, з якою ми зіткнулися, і та, що може бути попереду

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

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

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

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

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

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

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

Підхід до нічних перебудов

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

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

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

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

Підхід до свідомих оновлень

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

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

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

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

Хто першим відправить задню двері?

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

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

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

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

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

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

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

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

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

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

Коли свіжість стає ризиком

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

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

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

Перебудова не є верифікацією

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

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

Інший вид CVE

Коли всі прагнуть “нулевих відомих CVE”, ми ігноруємо ширші ризики. Ми перестаємо запитувати: “Цей образ вразливий?” Нам потрібно почати запитувати: “Цей образ занадто довірливий?”

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

Висновок

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

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

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

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