Стабільність, зворотні патчі та приховані ризики нових версій

У сучасному світі DevSecOps, CISOs постійно шукають сигнали в шумі, а результати сканерів безпеки часто мають велике значення. Сканування безпеки, яке повертає звіт “нуль CVE”, часто відкриває можливість для переходу в продуктивне середовище; один червоний сигнал може заблокувати випуск.

Цей бінарний погляд на безпеку спричинив появу двох протилежних філософій. З одного боку, ми маємо підхід з довгостроковою підтримкою (LTS): залишайтеся на перевіреній версії та застосовуйте конкретні виправлення безпеки. З іншого боку, є підхід “випускати останнє”: постійно оновлюватися до останніх версій, щоб не пропускати CVE.

У цій статті я порівняю переваги та недоліки підходу “випускати останнє” та “підходу LTS”, і аргументую, що поки “перехід вперед” радує ваша система сканування, вона може робити вашу інфраструктуру більш крихкою.

Аргументи на користь зворотних патчів: стабільність – це опора безпеки

Модель LTS ґрунтується на принципі мінімальних змін. Наприклад, коли виявляється вразливість, інженери безпеки Canonical виводять мінімальний набір змін, необхідних для усунення проблеми, і застосовують його до старіших версій.

Перевага цієї моделі – стабільність: ви отримуєте виправлення без “зміни функцій”. Ваші API не змінюються, файли конфігурації не ламаються, а поведінка вашого додатку залишається передбачуваною. Стабільність – це не лише про API. Це стосується споживання ресурсів. Зворотний патч LTS не подвоює вашу пам’ять раптово або не додає нових фонових телеметрій – чого остання версія може зробити без попередження.

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

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

Недоліки підходу “випускати останнє”

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

Однак підхід “випускати останнє” базується на небезпечному припущенні: що “новіше” завжди “безпечніше”. Розгляньмо деякі негативні пункти та ризики цього підходу.

1. Ризик “невідомого невідомого”

CVE – це відомий вразливість. Коли ви використовуєте старшу, широко впроваджену версію пакета (як ті, що в Ubuntu LTS), ви, ймовірно, використовуєте код, який був “витриманий” роками глобального виробничого використання.

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

2. Насторожуюча історія XZ Utils

Шпигунський код у XZ Utils (CVE-2024-3094) є найкращим запереченням філософії “завжди остання”. У цьому відомому прикладі шкідливий код був введений в останні “новітні” версії інструмента. Кожен новий рядок коду є потенційною новою вразливістю.

Користувачі дистрибутивів, таких як Debian Stable або Ubuntu LTS, були захищені за замовчуванням, не тому що вони були розумнішими, а тому, що їхня залежність від перевіреного, узгодженого коду діяла як обов’язковий період охолодження для глобального постачального ланцюга. У порівнянні, модель “випускати останнє” створює шосе для такого типу складних атак у продуктивне середовище.

3. Ненавмисне введення рушійних змін

Якщо ви користуєтеся моделлю “випускати останнє”, стабільність вашого середовища також буде страждати, оскільки ваші залежності постійно змінюються. Невелике оновлення версії може містити “виправлення”, яке змінює, як бібліотека обробляє пам’ять або тайм-аут мережі.

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

Безпека vs. Сумісність

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

Виробники, які підтримують модель “випускати останнє”, не обов’язково вирішили проблему; вони просто змістили ризик. Створюючи постійно змінювані операційні системи, позбавлені історичної стабільності, вони обіцяють миттєве виправлення. Вартість обіцянки LTS про гарантовану сумісність.

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

Висновок

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

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

Ми насправді більш захищені, чи просто втомилися дивитися на червоні точки на панелі? Шляхом зворотного перенесення виправлень CVE, Ubuntu Pro визнає, що коду потрібно час, щоб його було довірено. У світі, де атаки на постачальний ланцюг стали новим фронтиром, стабільний і перевірений код може бути найзахищенішою функцією, яку ви маєте.