XZ Udils Scare afslører hårde sandheder i softwaresikkerhed

XZ Udils Scare afslører hårde sandheder i softwaresikkerhed

Tidsstempel: 10. april 2024 kl. 6
XZ Utils Scare Exposes Hard Truths in Software Security PlatoBlockchain Data Intelligence. Vertical Search. Ai.

Den nylige opdagelse af en bagdør i XZ Utils datakomprimeringsværktøj - der findes i næsten alle større Linux-distributioner - er en skarp påmindelse om, at organisationer, der bruger open source-komponenter, i sidste ende har ansvaret for at sikre softwaren.

XZ Utils er, ligesom tusindvis af andre open source-projekter, frivilligt drevet og har i sit tilfælde en enkelt vedligeholder, der administrerer det. Sådanne projekter har ofte få eller ingen ressourcer til at håndtere sikkerhedsproblemer, hvilket betyder, at organisationer bruger softwaren på egen risiko. Det betyder, at sikkerheds- og udviklingsteams skal implementere foranstaltninger til styring af open source-risici på samme måde, som de gør med internt udviklet kode, siger sikkerhedseksperter.

"Selvom det er usandsynligt, at en organisation effektivt kan forhindre [al] eksponering for forsyningskæderisici, kan organisationer absolut fokusere på en strategi for at reducere sandsynligheden for, at et forsyningskædeangreb er vellykket," siger Jamie Scott, grundlægger produktchef hos Endor Labs.

Open source er ikke det samme som outsourcing: "Open source-vedligeholdere af software er frivillige. På brancheniveau er vi nødt til at behandle dem som sådan. Vi ejer vores software; vi er ansvarlige for den software, vi genbruger."

Velmenende, under-ressourcer

Bekymringer over open source-softwaresikkerhed er på ingen måde nye. Men det kræver ofte opdagelser som Log4Shell sårbarhed og bagdør i XZ Utils for virkelig at køre hjem, hvor sårbare organisationer er over for komponenter i deres kode. Og ofte kommer koden fra velmenende, men håbløst underressourcebesparende open source-projekter, der er minimalt vedligeholdt.

XZ Utils, for eksempel, er i det væsentlige et enkeltmandsprojekt. Det lykkedes en anden person snige bagdøren ind i værktøjet over en næsten tre-årig periode, ved gradvist at opnå tilstrækkelig tillid fra projektets vedligeholder. Hvis en Microsoft-udvikler ikke havde fundet på det i slutningen af ​​marts, da han undersøgte mærkelig adfærd forbundet med en Debian-installation, kunne bagdøren meget vel være endt på millioner af enheder globalt – inklusive dem, der tilhører store virksomheder og statslige agenturer. Som det viste sig, havde bagdøren minimal indflydelse, fordi den påvirkede versioner af XZ Utils, der kun var til stede i ustabile og betaversioner af Debian, Fedora, Kali, open SUSE og Arch Linux.

Det næste kompromis med åben kildekode kunne være langt værre. "Det mest skræmmende for virksomhedsorganisationer er, at deres applikationer er bygget oven på open source softwareprojekter ligesom XZ Utils," siger Donald Fischer, medstifter og administrerende direktør for Tidelift. "XZ Utils er en pakke med titusindvis, der er i brug hver dag af typiske virksomhedsorganisationer," siger han.

De fleste af disse organisationer mangler tilstrækkeligt overblik over sikkerheden og modstandsdygtigheden i denne del af deres softwareforsyningskæde til at være i stand til at vurdere risiko, bemærker han.

En nylig Harvard Business School undersøgelse estimerede efterspørgselssiden værdien af ​​open source software til at være en forbløffende $8.8 billioner. Vedligeholdere er kernen i dette økosystem, og mange af dem flyver solo, siger Fischer. En undersøgelse foretaget af Tidelift sidste år viste, at 44% af open source-projektvedligeholdere beskriver sig selv som de eneste vedligeholdere af deres projekter. Tres procent identificerede sig selv som ulønnede hobbyister, og den samme procentdel sagde, at de enten har sagt op eller har overvejet at forlade deres roller som projektvedligeholdere. Mange vedligeholdere beskrev deres indsats som stressende, ensomt og økonomisk ugivende arbejde, siger Fischer.

"XZ utils-hacket bringer risikoen for underinvestering i sundheden og modstandsdygtigheden af ​​open source-softwareforsyningskæden [som] virksomhedsorganisationer er afhængige af," siger Fischer. "Erhvervsorganisationer skal indse, at størstedelen af ​​de mest påberåbte open source-pakker vedligeholdes af frivillige, der beskriver sig selv som ulønnede hobbyister. Disse vedligeholdere er ikke virksomhedsleverandører, men forventes at arbejde og levere som dem."

Fare: Transitive afhængigheder

A undersøgelse, som Endor har gennemført i 2022 fandt, at 95 % af open source-sårbarhederne er til stede i såkaldte transitive afhængigheder eller sekundære open source-pakker eller biblioteker, som en primær open source-pakke kan være afhængig af. Ofte er det pakker, som udviklere ikke selv vælger direkte, men som automatisk anvendes af en open source-pakke i deres udviklingsprojekt.

"For eksempel, når du stoler på en Maven-pakke, er der i gennemsnit yderligere 14 afhængigheder, du implicit stoler på som et resultat," siger Scott. "Dette tal er endnu større i visse software-økosystemer såsom NPM, hvor du i gennemsnit importerer 77 andre softwarekomponenter for hver, du stoler på."

En måde at begynde at afbøde open source-risici på er at være opmærksom på disse afhængigheder og være selektiv med hensyn til, hvilke projekter du vælger, siger han.

Organisationer bør dyrlæge afhængigheder, især de mindre, enkeltstående pakker, bemandet af en- og to-personers teams, tilføjer Dimitri Stiliadis, Endors CTO og medstifter. De bør afgøre, om afhængigheder i deres miljø har passende sikkerhedskontrol, eller om en enkelt person begår al kode; om de har binære filer i deres depoter, som ingen kender til; eller endda hvis nogen aktivt vedligeholder projektet overhovedet, siger Stiliadis.

"Fokusér dine bestræbelser på at forbedre din reaktionseffektivitet - grundlæggende kontroller såsom vedligeholdelse af et modent softwarelager er fortsat et af de programmer af højeste værdi, du kan have på plads til hurtigt at identificere, udsende og reagere på softwarerisici, når de er identificeret," Scott rådgiver.

Softwaresammensætningsanalyseværktøjer, sårbarhedsscannere, EDR/XDR-systemer og SBOM'er kan også alle hjælpe organisationer med hurtigt at identificere sårbare og kompromitterede open source-komponenter.

Erkender truslen

"Afbødning af eksponering starter med fælles forståelse og anerkendelse i C-suiten og endda på bestyrelsesniveau, at omkring 70 % af ingredienserne i det gennemsnitlige softwareprodukt er open source-software, der historisk er skabt af for det meste ukompenserede bidragydere," siger Tidelifts Fischer.  

Nye regler og retningslinjer i finanssektoren, FDA og NIST vil forme, hvordan software udvikles i de kommende år, og organisationer skal forberede sig på dem nu. "Vindere her vil hurtigt tilpasse sig fra en reaktiv strategi til en proaktiv strategi til styring af open source-relateret risiko," siger han.

Fischer anbefaler, at organisationer får deres sikkerheds- og ingeniørteam til at identificere, hvordan nye open source-komponenter kommer ind i deres miljø. De bør også definere roller til overvågning af disse komponenter og proaktivt fjerne dem, der ikke passer til virksomhedens risikovillighed. "At reagere på problemer i de sene stadier er blevet en ineffektiv måde at håndtere omfanget af risikoen for virksomheden i løbet af de sidste mange år, og Den amerikanske regering signalerer den æra er ved at være slut,” siger han.

Tidsstempel:

Mere fra Mørk læsning