Az XZ Utils Scare kemény igazságokat tár fel a szoftverbiztonság terén

Az XZ Utils Scare kemény igazságokat tár fel a szoftverbiztonság terén

Időbélyeg: 10. április 2024. 6:22
Az XZ Utils Scare kemény igazságokat tár fel a szoftverbiztonság PlatoBlockchain adatintelligenciájában. Függőleges keresés. Ai.

A közelmúltban felfedezett hátsó ajtó az XZ Utils adattömörítő segédprogramban – amely szinte minden nagyobb Linux disztribúcióban jelen van – határozottan emlékeztet arra, hogy a nyílt forráskódú összetevőket fogyasztó szervezetek végső soron felelősséggel tartoznak a szoftver biztonságáért.

Az XZ Utils, több ezer más nyílt forráskódú projekthez hasonlóan, önkéntes irányítású, és egyetlen karbantartó kezeli. Az ilyen projektek gyakran alig vagy egyáltalán nem rendelkeznek erőforrásokkal a biztonsági problémák kezelésére, ami azt jelenti, hogy a szervezetek saját kockázatukra használják a szoftvert. Ez azt jelenti, hogy a biztonsági és fejlesztőcsapatoknak ugyanúgy intézkedéseket kell végrehajtaniuk a nyílt forráskódú kockázatok kezelésére, mint a belső fejlesztésű kódoknál – állítják biztonsági szakértők.

„Bár nem valószínű, hogy egy szervezet hatékonyan meg tudja akadályozni az ellátási lánc kockázatainak való [minden] kitettséget, a szervezetek feltétlenül olyan stratégiára összpontosíthatnak, amellyel csökkenthető az ellátási lánc támadása sikerességének valószínűsége” – mondja Jamie Scott, az Endor Labs alapító termékmenedzsere.

A nyílt forráskód nem egyenlő a kiszervezéssel: „A szoftverek nyílt forráskódú karbantartói önkéntesek. Iparági szinten úgy kell kezelnünk őket. Mi vagyunk a szoftvereink; felelősek vagyunk az általunk újrafelhasznált szoftverekért."

Jó szándékú, forráshiányos

Aggodalmak a nyílt forráskódú szoftverek biztonságával kapcsolatban egyáltalán nem újak. De gyakran olyan felfedezésekre van szükség, mint a Log4Shell sebezhetőség és a hátsó ajtó az XZ Utils-ben valóban hazavezetni, mennyire sebezhetőek a szervezetek a kódjuk összetevői miatt. És gyakran a kód jó szándékú, de reménytelenül forráshiányos nyílt forráskódú projektekből származik, amelyeket minimálisan karbantartanak.

Az XZ Utils például lényegében egyszemélyes projekt. Egy másik személynek sikerült besurranni a hátsó ajtón a segédprogramba közel három év alatt, fokozatosan elnyerve kellő bizalmat a projekt fenntartójától. Ha egy Microsoft fejlesztő március végén nem találkozik vele, amikor egy Debian-telepítéssel kapcsolatos furcsa viselkedést vizsgált, a hátsó ajtó valószínűleg több millió eszközön kötött volna ki világszerte – beleértve a nagyvállalatokhoz és kormányzati szervekhez tartozókat is. Mint kiderült, a hátsó ajtónak minimális hatása volt, mert az XZ Utils azon verzióit érintette, amelyek csak a Debian, Fedora, Kali, nyílt SUSE és Arch Linux instabil és béta verzióiban voltak jelen.

A következő ilyen nyílt forráskódú kompromisszum sokkal rosszabb lehet. „A vállalati szervezetek számára az a legfélelmetesebb, hogy alkalmazásaik nyílt forráskódú szoftverprojektekre épülnek, akárcsak az XZ Utils” – mondja Donald Fischer, a Tidelift társalapítója és vezérigazgatója. „Az XZ Utils egy több tízezres csomag, amelyet a tipikus vállalati szervezetek naponta használnak” – mondja.

A legtöbb ilyen szervezet nem rendelkezik kellő rálátással a szoftverellátási lánc ezen részének biztonságára és rugalmasságára, hogy képes legyen értékelni a kockázatokat – jegyzi meg.

Egy nemrégiben Harvard Business School tanulmány a nyílt forráskódú szoftverek keresleti oldali értékét elképesztően 8.8 billió dollárra becsülte. Fischer szerint a fenntartók az ökoszisztéma középpontjában állnak, és sokan közülük egyedül repülnek. A Tidelift tavalyi felmérése szerint a nyílt forráskódú projektek karbantartóinak 44%-a nevezi magát projektjeik kizárólagos fenntartójának. XNUMX százalékuk fizetetlen hobbinak vallotta magát, és ugyanennyien azt mondták, hogy vagy felmondtak, vagy fontolgatták, hogy felhagynak projektfenntartói szerepkörükkel. Sok karbantartó stresszes, magányos és anyagilag kifizetődő munkának írta le erőfeszítéseit, mondja Fischer.

„Az XZ utils feltörése jelentősen csökkenti a vállalati szervezetek által támaszkodó nyílt forráskódú szoftverek ellátási láncának egészségébe és ellenálló képességébe való alulbefektetés kockázatát” – mondja Fischer. „A vállalati szervezeteknek be kell látniuk, hogy a leginkább támaszkodó nyílt forráskódú csomagok többségét önkéntesek tartják fenn, akik fizetés nélküli hobbiként írják le magukat. Ezek a karbantartók nem vállalati beszállítók, de elvárják, hogy úgy dolgozzanak és szállítsanak, mint ők.”

Veszély: tranzitív függőségek

A tanulmány, amelyet Endor végzett 2022-ben megállapította, hogy a nyílt forráskódú sebezhetőségek 95%-a úgynevezett tranzitív függőségekben vagy másodlagos nyílt forráskódú csomagokban vagy könyvtárakban található, amelyektől egy elsődleges nyílt forráskódú csomag függhet. Ezek gyakran olyan csomagok, amelyeket a fejlesztők nem közvetlenül maguk választanak ki, hanem egy nyílt forráskódú csomag automatikusan alkalmazza őket fejlesztési projektjükben.

"Például, ha megbízik egy Maven-csomagban, átlagosan további 14 függőség van, amelyekben implicit módon megbízik" - mondja Scott. "Ez a szám még nagyobb bizonyos szoftver-ökoszisztémákban, például az NPM-ben, ahol átlagosan 77 további szoftverösszetevőt importál minden megbízhatónak számítóhoz."

A nyílt forráskódú kockázatok mérséklésének egyik módja az, hogy odafigyelünk ezekre a függőségekre, és szelektíven választjuk ki, milyen projekteket választunk – mondja.

A szervezeteknek ellenőrizniük kell a függőségeket, különösen a kisebb, egyedi csomagokat, amelyeket egy- és kétfős csapatok irányítanak. Dimitri Stiliadis, az Endor technológiai igazgatója és társalapítója. Meg kell határozniuk, hogy a környezetükben lévő függőségek megfelelő biztonsági ellenőrzésekkel rendelkeznek-e, vagy egyetlen személy követi-e el az összes kódot; hogy vannak-e olyan bináris fájlok a tárukban, amelyekről senki sem tud; vagy még akkor is, ha valaki aktívan karbantartja a projektet, mondja Stiliadis.

„Erőfeszítéseit összpontosítsa válaszadási hatékonyságának javítására – az olyan alapvető vezérlők, mint a kiforrott szoftverleltár fenntartása, továbbra is az egyik legértékesebb program, amellyel gyorsan azonosíthatja, felmérheti és reagálhat a szoftverkockázatokra, miután azonosították őket.” tanácsolja.

A szoftverkompozíció-elemző eszközök, a sebezhetőségi szkennerek, az EDR/XDR-rendszerek és az SBOM-ok szintén segíthetnek a szervezeteknek a sebezhető és veszélyeztetett nyílt forráskódú összetevők gyors azonosításában.

A fenyegetés elismerése

„Az expozíció mérséklése azzal kezdődik, hogy a C-csomagban és még az igazgatótanácsi szinten is meg kell osztani a megértést és elismerni, hogy az átlagos szoftvertermékek összetevőinek nagyjából 70%-a nyílt forráskódú szoftver, amelyet korábban többnyire nem fizetett közreműködők hoztak létre” – mondja Fischer, a Tidelifttől.  

A pénzügyi szolgáltatási ágazatban, az FDA-ban és a NIST-ben új szabályozások és iránymutatások fogják meghatározni a szoftverfejlesztés módját az elkövetkező években, és a szervezeteknek most kell felkészülniük rájuk. „Az itteni nyertesek gyorsan alkalmazkodnak a reaktív stratégiától a proaktív stratégiához a nyílt forráskóddal kapcsolatos kockázatok kezeléséhez” – mondja.

A Fischer azt javasolja, hogy a szervezetek kérjék fel biztonsági és mérnöki csapataikat, hogy azonosítsák, hogyan érkeznek új nyílt forráskódú összetevők a környezetükbe. Meg kell határozniuk ezen összetevők megfigyelésére szolgáló szerepköröket is, és proaktívan el kell távolítaniuk azokat, amelyek nem felelnek meg a vállalat kockázati étvágyának. „A késői szakaszban lévő problémákra való reagálás az elmúlt évek során nem hatékony módja annak, hogy kezeljük a vállalkozást érintő kockázatok mértékét, és Az Egyesült Államok kormánya jelez ez a korszak a végéhez közeledik” – mondja.

Időbélyeg:

Még több Sötét olvasmány