Постачальницький ланцюг: чому важливо дати контейнерам охолонути перед відправкою

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

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

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

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

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

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

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

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

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

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

Але якщо вихідний код отруєний?

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

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

Підхід до навмисного оновлення

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коли свіжість стає відповідальністю

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

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

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

Перезбірка – це не перевірка

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

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

Інший вид CVE

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

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

Висновок

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

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

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

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