XZ Utils Scare avslører harde sannheter i programvaresikkerhet

XZ Utils Scare avslører harde sannheter i programvaresikkerhet

Tidsstempel: 10. april 2024 6:22
XZ Utils Scare avslører harde sannheter i programvaresikkerhet PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Den nylige oppdagelsen av en bakdør i XZ Utils datakomprimeringsverktøy – som finnes i nesten alle store Linux-distribusjoner – er en sterk påminnelse om at organisasjoner som bruker åpen kildekode-komponenter til syvende og sist har ansvaret for å sikre programvaren.

XZ Utils, som tusenvis av andre åpen kildekode-prosjekter, er frivillig drevet, og i tilfelle har en enkelt vedlikeholder som administrerer det. Slike prosjekter har ofte små eller ingen ressurser for å håndtere sikkerhetsproblemer, noe som betyr at organisasjoner bruker programvaren på egen risiko. Det betyr at sikkerhets- og utviklingsteam må implementere tiltak for å håndtere åpen kildekode-risiko på samme måte som de gjør med internt utviklet kode, sier sikkerhetseksperter.

"Selv om det er usannsynlig at en organisasjon effektivt kan forhindre [all] eksponering for forsyningskjederisiko, kan organisasjoner absolutt fokusere på en strategi for å redusere sannsynligheten for at et forsyningskjedeangrep er vellykket," sier Jamie Scott, grunnleggende produktsjef ved Endor Labs.

Åpen kildekode er ikke det samme som outsourcing: «Open source vedlikeholdere av programvare er frivillige. På bransjenivå må vi behandle dem som det. Vi eier programvaren vår; vi er ansvarlige for programvaren vi gjenbruker."

Velmenende, lite ressurssterke

Bekymringer om sikkerhet for åpen kildekode er på ingen måte nye. Men det krever ofte oppdagelser som Log4Shell-sårbarhet og bakdør i XZ Utils å virkelig kjøre hjem hvor sårbare organisasjoner er for komponenter i koden deres. Og ofte kommer koden fra velmente, men håpløst under-ressursfattige åpen kildekode-prosjekter som vedlikeholdes minimalt.

XZ Utils, for eksempel, er i hovedsak et enmannsprosjekt. En annen person klarte det snike bakdøren inn i verktøyet over en nesten tre års periode, ved gradvis å få nok tillit fra prosjektansvarlig. Hvis en Microsoft-utvikler ikke hadde kommet på det i slutten av mars da han undersøkte merkelig oppførsel knyttet til en Debian-installasjon, kunne bakdøren godt ha havnet på millioner av enheter globalt – inkludert de som tilhører store selskaper og offentlige etater. Det viste seg at bakdøren hadde minimal innvirkning fordi den påvirket versjoner av XZ Utils som bare var til stede i ustabile og betaversjoner av Debian, Fedora, Kali, open SUSE og Arch Linux.

Det neste kompromisset med åpen kildekode kan være langt verre. "Det skumleste for bedriftsorganisasjoner er at applikasjonene deres er bygget på toppen av programvareprosjekter med åpen kildekode akkurat som XZ Utils," sier Donald Fischer, medgründer og administrerende direktør i Tidelift. "XZ Utils er en pakke med titusenvis som er i bruk hver dag av typiske bedriftsorganisasjoner," sier han.

De fleste av disse organisasjonene mangler tilstrekkelig innsyn i sikkerheten og motstandskraften til denne delen av programvareforsyningskjeden for å kunne evaluere risiko, bemerker han.

En fersk Harvard Business School studie estimerte etterspørselssiden verdien av åpen kildekode-programvare til å være en forbløffende $8.8 billioner. Vedlikeholdere er kjernen i dette økosystemet, og mange av dem flyr alene, sier Fischer. En undersøkelse utført av Tidelift i fjor fant at 44 % av prosjektvedlikeholderne av åpen kildekode beskriver seg selv som de eneste vedlikeholderne av prosjektene sine. Seksti prosent identifiserte seg som ulønnede hobbyister, og den samme prosentandelen sa at de enten har sluttet eller har vurdert å slutte i rollene som prosjektvedlikeholdere. Mange vedlikeholdere beskrev innsatsen deres som stressende, ensomt og økonomisk lite givende arbeid, sier Fischer.

"XZ utils-hacket bringer i sterk lettelse risikoen for underinvestering i helsen og motstandskraften til leverandørkjeden for åpen kildekode [som] bedriftsorganisasjoner er avhengige av," sier Fischer. "Bedriftsorganisasjoner må innse at flertallet av de mest pålitelige åpen kildekode-pakkene vedlikeholdes av frivillige som beskriver seg selv som ubetalte hobbyister. Disse vedlikeholderne er ikke bedriftsleverandører, men forventes å jobbe og levere som dem."

Fare: Transitive avhengigheter

A studie som Endor gjennomførte i 2022 fant at 95 % av sårbarhetene med åpen kildekode er tilstede i såkalte transitive avhengigheter, eller sekundære åpen kildekode-pakker eller biblioteker som en primær åpen kildekode-pakke kan være avhengig av. Ofte er dette pakker som utviklere ikke velger direkte selv, men som automatisk brukes av en åpen kildekode-pakke i utviklingsprosjektet deres.

"For eksempel, når du stoler på én Maven-pakke, er det i gjennomsnitt ytterligere 14 avhengigheter du implisitt stoler på som et resultat," sier Scott. "Dette tallet er enda større i visse programvareøkosystemer som NPM hvor du i gjennomsnitt importerer 77 andre programvarekomponenter for hver du stoler på."

En måte å begynne å redusere risikoen for åpen kildekode er å ta hensyn til disse avhengighetene og være selektiv med hensyn til hvilke prosjekter du velger, sier han.

Organisasjoner bør veterinæravhengige, spesielt de mindre engangspakkene, bemannet av en- og tomannsteam, legger til Dimitri Stiliadis, Endors CTO og medgründer. De bør avgjøre om avhengigheter i deres miljø har riktige sikkerhetskontroller eller om en enkelt person forplikter all kode; om de har binære filer i depotene sine som ingen vet om; eller selv om noen aktivt vedlikeholder prosjektet i det hele tatt, sier Stiliadis.

"Fokuser innsatsen din på å forbedre responseffektiviteten din – grunnleggende kontroller som å opprettholde en moden programvarebeholdning er fortsatt et av de mest verdifulle programmene du kan ha på plass for raskt å identifisere, omfang og svare på programvarerisikoer når de er identifisert," Scott råder.

Programvaresammensetningsanalyseverktøy, sårbarhetsskannere, EDR/XDR-systemer og SBOM-er kan også hjelpe organisasjoner raskt å identifisere sårbare og kompromitterte åpen kildekodekomponenter.

Erkjenner trusselen

"Begrensende eksponering starter med delt forståelse og anerkjennelse i C-suiten og til og med på styrenivå at omtrent 70 % av ingrediensene i det gjennomsnittlige programvareproduktet er åpen kildekode-programvare historisk skapt av stort sett ukompenserte bidragsytere," sier Tidelifts Fischer.  

Nye forskrifter og retningslinjer i finansnæringen, FDA og NIST vil forme hvordan programvare utvikles i årene fremover og organisasjoner må forberede seg på dem nå. "Vinnerne her vil raskt tilpasse seg fra en reaktiv strategi til en proaktiv strategi for å håndtere åpen kildekode-relatert risiko," sier han.

Fischer anbefaler at organisasjoner får sikkerhets- og ingeniørteamene sine til å identifisere hvordan nye åpen kildekode-komponenter kommer inn i miljøet deres. De bør også definere roller for overvåking av disse komponentene og proaktivt fjerne de som ikke passer selskapets risikovilje. "Å reagere på problemer på sent stadium har blitt en ineffektiv måte å håndtere omfanget av risikoen for virksomheten de siste årene, og Den amerikanske regjeringen signaliserer den epoken går mot slutten, sier han.

Tidstempel:

Mer fra Mørk lesning