Зворотні патчі: стабільність та ризики для безпеки

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

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

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

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

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

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

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

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

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

Недоліки підходу “постійного оновлення”

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

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

1. Ризик “Невідомих невідомостей”

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

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

2. Попередження з XZ Utils

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

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

3. Непередбачувані зміни

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

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

Безпека проти дотримання норм

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

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

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

Висновок

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

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

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

Додаткова інформація