XZ Utils Scare obnaża twarde prawdy dotyczące bezpieczeństwa oprogramowania

Niedawne odkrycie backdoora w narzędziu do kompresji danych XZ Utils — obecnym w prawie wszystkich głównych dystrybucjach Linuksa — stanowi wyraźne przypomnienie, że organizacje korzystające z komponentów open source ostatecznie ponoszą odpowiedzialność za zabezpieczenie oprogramowania.

XZ Utils, podobnie jak tysiące innych projektów open source, jest prowadzony przez wolontariuszy i w tym przypadku zarządza nim jeden opiekun. W takich projektach często brakuje zasobów do rozwiązywania problemów związanych z bezpieczeństwem, co oznacza, że ​​organizacje korzystają z oprogramowania na własne ryzyko. Oznacza to, że zespoły ds. bezpieczeństwa i rozwoju muszą wdrożyć środki zarządzania ryzykiem związanym z oprogramowaniem open source w taki sam sposób, jak w przypadku kodu opracowanego wewnętrznie, twierdzą eksperci ds. bezpieczeństwa.

„Chociaż jest mało prawdopodobne, aby organizacja była w stanie skutecznie zapobiec [całkowicie] narażeniu na ryzyko łańcucha dostaw, organizacje mogą całkowicie skoncentrować się na strategii zmniejszającej prawdopodobieństwo powodzenia ataku na łańcuch dostaw” – mówi Jamie Scott, założyciel i menedżer produktu w Endor Labs.

Otwarte oprogramowanie to nie to samo, co outsourcing: „Opiekunowie oprogramowania typu open source są ochotnikami. Na poziomie branży musimy je traktować jako takie. Posiadamy własne oprogramowanie; jesteśmy odpowiedzialni za oprogramowanie, którego ponownie używamy.”

Mający dobre intencje i niedostatecznie zasobni

Obawy dotyczące bezpieczeństwa oprogramowania typu open source nie są wcale nowe. Ale często potrzebne są odkrycia takie jak Luka Log4Shell oraz backdoor w XZ Utils aby naprawdę uświadomić sobie, jak podatne są organizacje na komponenty swojego kodu. Często kod pochodzi z projektów open source mających dobre intencje, ale beznadziejnie niedofinansowanych i utrzymywanych w minimalnym stopniu.

Na przykład XZ Utils jest zasadniczo projektem jednoosobowym. Udało się to innej osobie wkraść się tylnymi drzwiami do narzędzia przez okres blisko trzech lat, stopniowo zdobywając wystarczające zaufanie ze strony opiekuna projektu. Gdyby programista firmy Microsoft nie natknął się na to pod koniec marca podczas badania dziwnego zachowania związanego z instalacją Debiana, backdoor mógłby równie dobrze znaleźć się na milionach urządzeń na całym świecie — w tym na urządzeniach należących do dużych korporacji i agencji rządowych. Jak się okazało, backdoor miał minimalny wpływ, ponieważ dotyczył wersji XZ Utils, które były obecne tylko w niestabilnych i beta wersjach Debiana, Fedory, Kali, otwartego SUSE i Arch Linux.

Następny taki kompromis w zakresie otwartego kodu źródłowego może być znacznie gorszy. „Najbardziej przerażające dla przedsiębiorstw jest to, że ich aplikacje są tworzone w oparciu o projekty oprogramowania typu open source, tak jak XZ Utils” – mówi Donald Fischer, współzałożyciel i dyrektor generalny Tidelift. „XZ Utils to jeden pakiet spośród dziesiątek tysięcy, z których codziennie korzystają typowe przedsiębiorstwa” – mówi.

Zauważa, że ​​większości tych organizacji brakuje wystarczającego wglądu w bezpieczeństwo i odporność tej części łańcucha dostaw oprogramowania, aby móc ocenić ryzyko.

Ostatnia Harvard Business School W badaniu oszacowano wartość popytu na oprogramowanie typu open source na zdumiewające 8.8 biliona dolarów. Konserwatorzy stanowią rdzeń tego ekosystemu i wielu z nich lata samotnie, mówi Fischer. Ankieta przeprowadzona przez Tidelift w zeszłym roku wykazała, że ​​44% opiekunów projektów open source opisuje siebie jako jedynych opiekunów swoich projektów. Sześćdziesiąt procent określiło się jako nieopłacani hobbyści i taki sam procent stwierdziło, że albo zrezygnował, albo rozważał rezygnację z roli opiekunów projektów. Fischer twierdzi, że wielu opiekunów określiło swoje wysiłki jako stresującą, samotną i finansowo niewdzięczną pracę.

„Hack XZ utils wyraźnie łagodzi ryzyko niedoinwestowania w kondycję i odporność łańcucha dostaw oprogramowania open source, na którym polegają organizacje przedsiębiorstw” – mówi Fischer. „Organizacje korporacyjne muszą zdać sobie sprawę, że większość najbardziej niezawodnych pakietów open source jest obsługiwana przez wolontariuszy, którzy określają siebie jako nieopłacanych hobbystów. Ci konserwatorzy nie są dostawcami dla przedsiębiorstw, ale oczekuje się od nich, że będą pracować i dostarczać produkty tak jak oni.

Niebezpieczeństwo: zależności przechodnie

A badanie przeprowadzone przez Endora w 2022 r. wykazało, że 95% luk w zabezpieczeniach oprogramowania open source występuje w tak zwanych zależnościach przechodnich lub wtórnych pakietach lub bibliotekach open source, od których może zależeć główny pakiet open source. Często są to pakiety, których programiści nie wybierają sami bezpośrednio, ale są automatycznie wykorzystywani przez pakiet open source w swoim projekcie programistycznym.

„Na przykład, jeśli ufasz jednemu pakietowi Mavena, w rezultacie pośrednio ufasz średnio 14 dodatkowym zależnościom” – mówi Scott. „Ta liczba jest jeszcze większa w niektórych ekosystemach oprogramowania, takich jak NPM, gdzie importuje się średnio 77 innych komponentów oprogramowania dla każdego, któremu ufasz”.

Jednym ze sposobów rozpoczęcia ograniczania ryzyka związanego z oprogramowaniem open source jest zwrócenie uwagi na te zależności i wybiórcze podejście do wybieranych projektów, mówi.

Organizacje powinny weryfikować zależności, zwłaszcza mniejsze, jednorazowe pakiety, obsługiwane przez jedno- i dwuosobowe zespoły, dodaje Dimitri Stiliadis, dyrektor ds. technicznych i współzałożyciel firmy Endor. Powinni określić, czy zależności w ich środowisku mają odpowiednią kontrolę bezpieczeństwa, czy też pojedyncza osoba zatwierdza cały kod; czy mają w swoich repozytoriach pliki binarne, o których nikt nie wie; lub nawet jeśli ktoś w ogóle aktywnie utrzymuje projekt, mówi Stiliadis.

„Skoncentruj swoje wysiłki na poprawie efektywności reagowania — podstawowe kontrole, takie jak utrzymywanie zapasów dojrzałego oprogramowania, pozostają jednym z programów o największej wartości, jakie możesz wdrożyć, aby szybko identyfikować, określać zakres i reagować na zagrożenia związane z oprogramowaniem po ich zidentyfikowaniu” – Scott radzi.

Narzędzia do analizy składu oprogramowania, skanery podatności, systemy EDR/XDR i SBOM mogą również pomóc organizacjom szybko identyfikować podatne i zagrożone komponenty open source.

Uznanie zagrożenia

„Ograniczenie narażenia zaczyna się od wspólnego zrozumienia i uznania na szczeblu kierowniczym, a nawet na szczeblu zarządu, że około 70% składników przeciętnego oprogramowania to oprogramowanie typu open source, które w przeszłości było tworzone głównie przez autorów nie otrzymujących wynagrodzenia” – mówi Fischer z Tidelift.  

Nowe regulacje i wytyczne w branży usług finansowych, FDA i NIST ukształtują sposób tworzenia oprogramowania w nadchodzących latach, a organizacje muszą się na nie przygotować już teraz. „Zwycięzcy szybko przejdą ze strategii reaktywnej na strategię proaktywną w celu zarządzania ryzykiem związanym z otwartym oprogramowaniem” – mówi.

Fischer zaleca, aby organizacje zleciły swoim zespołom ds. bezpieczeństwa i inżynierii określenie, w jaki sposób nowe komponenty open source trafiają do ich środowiska. Powinni także określić role w zakresie monitorowania tych elementów i aktywnie usuwać te, które nie odpowiadają apetytowi firmy na ryzyko. „Reagowanie na problemy na późnym etapie stało się w ciągu ostatnich kilku lat nieskutecznym sposobem radzenia sobie ze skalą ryzyka dla biznesu, a Rząd USA sygnalizuje ta era dobiega końca” – mówi.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security