XZ Utils Scare розкриває сувору правду щодо безпеки програмного забезпечення

XZ Utils Scare розкриває сувору правду щодо безпеки програмного забезпечення

Мітка часу: 10 квітня 2024 р., 6:22
XZ Utils Scare розкриває сувору правду щодо безпеки програмного забезпечення PlatoBlockchain Data Intelligence. Вертикальний пошук. Ai.

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

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

«Хоча організація навряд чи зможе ефективно запобігти [всьому] ризику ланцюга постачання, організації можуть повністю зосередитися на стратегії зменшення ймовірності успішної атаки на ланцюг постачання», — каже Джеймі Скотт, менеджер із продукції-засновника Endor Labs.

Відкритий вихідний код — це не те ж саме, що аутсорсинг: «Супроводжувачі програмного забезпечення з відкритим кодом є волонтерами. На галузевому рівні ми повинні ставитися до них як до таких. Ми володіємо нашим програмним забезпеченням; ми несемо відповідальність за програмне забезпечення, яке ми повторно використовуємо».

З добрими намірами, недостатньо ресурсів

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

XZ Utils, наприклад, по суті є проектом однієї людини. Ще одній особи це вдалося проникнути бекдором в утиліту протягом майже трьох років, поступово завойовуючи достатню довіру з боку супроводжуючого проекту. Якби розробник Microsoft не випадково натрапив на нього наприкінці березня, досліджуючи дивну поведінку, пов’язану з інсталяцією Debian, бекдор цілком міг би опинитися на мільйонах пристроїв у всьому світі — включно з тими, що належать великим корпораціям і державним установам. Як виявилося, бекдор мав мінімальний вплив, оскільки він впливав на версії XZ Utils, які були присутні лише в нестабільних і бета-версіях Debian, Fedora, Kali, open SUSE та Arch Linux.

Наступний такий компроміс із відкритим кодом може бути набагато гіршим. «Найстрашніше для корпоративних організацій полягає в тому, що їхні додатки побудовані на основі проектів програмного забезпечення з відкритим кодом, таких як XZ Utils», — говорить Дональд Фішер, співзасновник і генеральний директор Tidelift. «XZ Utils — це один пакет із десятків тисяч, які щодня використовуються звичайними корпоративними організаціями», — каже він.

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

Недавній Гарвардська школа бізнесу Згідно з дослідженням, вартість програмного забезпечення з відкритим кодом з боку попиту становить неймовірні 8.8 трильйона доларів. Супроводжувачі є основою цієї екосистеми, і багато з них літають поодинці, каже Фішер. Опитування, проведене Tidelift минулого року, показало, що 44% супроводжувачів проектів з відкритим кодом описують себе як єдиних супроводжувачів своїх проектів. Шістдесят відсотків назвали себе неоплачуваними любителями, і такий самий відсоток сказав, що вони або залишили, або розглядали можливість залишити свою роль супроводжуючого проект. Багато супроводжувачів описували свої зусилля як стресову, самотню та фінансово невигідну роботу, каже Фішер.

«Злом XZ ​​utils чітко пояснює ризики недостатнього інвестування в здоров’я та стійкість ланцюга поставок програмного забезпечення з відкритим кодом, на який покладаються] корпоративні організації», — каже Фішер. «Комерційні організації повинні усвідомити, що більшість пакетів з відкритим кодом, яким найбільше покладаються, підтримуються волонтерами, які називають себе неоплачуваними любителями. Ці супроводжувачі не є корпоративними постачальниками, але очікується, що вони працюватимуть і постачатимуть послуги, як вони».

Небезпека: транзитивні залежності

A дослідження, яке провів Endor у 2022 році виявили, що 95% уразливостей з відкритим кодом присутні в так званих транзитивних залежностях або вторинних пакетах із відкритим кодом чи бібліотеках, від яких може залежати основний пакет із відкритим кодом. Часто це пакети, які розробники не вибирають безпосередньо, але автоматично застосовуються пакетом з відкритим кодом у своєму проекті розробки.

«Наприклад, якщо ви довіряєте одному пакету Maven, у середньому з’являється ще 14 додаткових залежностей, яким ви беззастережно довіряєте», — каже Скотт. «Це число ще більше в певних екосистемах програмного забезпечення, таких як NPM, де ви в середньому імпортуєте 77 інших компонентів програмного забезпечення для кожного, якому довіряєте».

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

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

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

Інструменти аналізу складу програмного забезпечення, сканери вразливостей, системи EDR/XDR і SBOM також можуть допомогти організаціям швидко ідентифікувати вразливі та скомпрометовані компоненти з відкритим кодом.

Визнання загрози

«Пом’якшення ризику починається зі спільного розуміння та визнання в керівництві та навіть на рівні правління того, що приблизно 70% інгредієнтів середньостатистичного програмного продукту є програмним забезпеченням з відкритим кодом, яке історично створювалося переважно безкомпенсованими учасниками», — каже Фішер з Tidelift.  

Нові нормативні акти та вказівки в галузі фінансових послуг, FDA та NIST визначатимуть, як розроблятиметься програмне забезпечення в наступні роки, і організаціям потрібно підготуватися до них уже зараз. «Переможці тут швидко адаптуються від реактивної стратегії до проактивної стратегії для управління ризиками, пов’язаними з відкритим кодом», – каже він.

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

Часова мітка:

Більше від Темне читання