Стабільність, зворотні повернення: переміщення вперед у безпеці

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

У сучасному світі DevSecOps CISO постійно шукають сигнали серед шуму, а результати сканерів безпеки часто мають велике значення. Сканування безпеки, яке повертає звіт «нуль 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. Введення розривних змін ненавмисно

Якщо ви користуєтеся моделлю «постійно новітнє», стабільність вашого середовища також страждає, адже ваші залежності постійно змінюються. Невелике оновлення версії може включати «виправлення», яке змінює, як бібліотека обробляє пам’ять або TAC (час відповіді).

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

Безпека та відповідність

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

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

Висновок

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

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

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

Далі читайте