Forsømmelse af Open Source-udviklere sætter internettet i fare PlatoBlockchain Data Intelligence. Lodret søgning. Ai.

Forsømmelse af Open Source-udviklere sætter internettet i fare

Software er kernen i alle moderne virksomheder og er afgørende i alle aspekter af driften. Næsten enhver virksomhed vil bruge open source-software, bevidst eller på anden måde, da selv proprietær software afhænger af open source-biblioteker. OpenUK's Rapporten "State of Open" fra 2022 viste, at 89 % af virksomhederne var afhængige af open source-software, men ikke alle er klare over detaljerne i den software, de stoler på.

Virksomheder efterspørger i stigende grad mere information om deres driftskritiske software. Ansvarlige virksomheder interesserer sig detaljeret for deres softwareforsyningskæde og opretter en softwarestykliste (SBOM) for hver applikation. Dette informationsniveau er afgørende, så når sikkerhedsfejl identificeres i deres software, kan de straks være sikre på, hvilken software og versioner der er i brug, og hvilke systemer der er berørt. Viden er magt i disse situationer!

Afhængighed af frivillige

I slutningen af ​​2021 kaldte en sikkerhedssårbarhed Log4Shell blev identificeret i en udbredt Java-logningsramme, Log4j. Da dette er et meget brugt open source-bibliotek, blev sårbarheden godt publiceret, og rettelser forventedes. Imidlertid vedligeholdere af projektet var frivillige. De havde dagjob og var ikke på vagt til akutte sikkerhedsrettelser, selvom et stort antal systemer var berørt. Alene denne sårbarhed blev anslået til at have påvirket 93 % af virksomhedens cloud-miljøer.

På det tidspunkt var der noget negativ presse om open source, men sandheden er, at hvis dette var en lukket kildekode-komponent, var sårbarheden måske aldrig blevet offentligt kendt, hvilket efterlod organisationer åbne for angreb. Bibliotekets open source-karakter betød, at det kunne inspiceres, problemerne findes og rådgives af andre. Så ja, vedligeholderne var ikke tilkalde for sikkerhedsproblemer i deres frivillige projekt. Det store spørgsmål er så: Hvordan kom vi i en situation, hvor store virksomheder var afhængige af software, som var en persons ansvar, der gør noget andet for at betale deres regninger?

Forsømmelse af softwareafhængigheder er en risikabel forretning uanset licensen til softwaren, men når det er open source og meget udbredt, bliver det særligt farligt. At holde sig til historien om én sårbarhed; problemet havde eksisteret i kodebasen i årevis, men blev ikke opdaget. Værktøjet, der var så udbredt, var faktisk ikke så bredt understøttet - og hvad der derefter skete er historie.

Denne historie gentages igen og igen, på tværs af så mange virksomheder, der har kritiske afhængigheder, men som ikke foretager sig noget for at støtte hverken vedligeholderne eller selve projekterne. At have en SBOM for softwaren, der bruges af en virksomhed, betyder, at de har oplysningerne ved hånden. For organisationer, der leverer software til andre, er forventningen om at levere SBOM sammen med koden i stigende grad normen.

Kend afhængigheder til at vurdere risiko

At bringe viden om afhængighederne gør det lettere at vurdere risikoen forbundet med hver enkelt. Disse open source-projekter er de enkleste at vurdere: bliver der reageret på problemer, og har der været nogen udgivelser for nylig? At kunne se vedligeholdere og projektaktivitet for hvert projekt giver god indsigt i projektets sundhed.

Virksomheder kan spille deres rolle for at reducere risici ved at støtte de projekter, de er afhængige af. Nogle projekter accepterer sponsorering direkte via GitHub-sponsorordningen, andre vil måske i stedet sætte pris på tilbud om hosting eller en sikkerhedsrevision. Ethvert open source-projekt værdsætter bidrag. Hvis din virksomhed selv havde oprettet dette bibliotek, ville ingeniørerne i virksomheden selv skulle rette hver eneste fejl.

Open source er mere som en delt ejerskabsordning. Vi behøver ikke alle at bygge det samme gentagne gange, men kan snarere bidrage, hvilket både er en mindre indsats og fører til bedre kvalitet som resultat. En af de mest virkningsfulde ting, virksomheder kan gøre, er at bruge lidt af deres tekniske ressourcer og bidrage til fejlrettelser eller funktioner til projekter der er så kernen i forretningen.

Holde dine egne ingeniører involveret i et projekt har mange fordele. De lærer det at kende og kan holde øje med nye funktioner, eller når en ny udgivelse er tilgængelig. Det er afgørende, at virksomheden har indsigt i det afhængige projekts helbred og status og er en del af det, der holder det sundt, hvilket reducerer risikoen for virksomheden for et problem med en afhængighed. En række organisationer, herunder Aiven, har et OSPO (open source program office), med personale dedikeret til at bidrage til eller endda vedligeholde de projekter, som organisationen bruger. Disse afdelinger bidrager ofte til virksomhedens generelle tilstedeværelse i open source-økosystemet og gør det muligt for andre medarbejdere at engagere sig med open source.

En anden tilgang er at støtte de organisationer, der eksisterer, til at understøtte open source. Det OpenSSF (Open Source Security Foundation) arbejder for at forbedre sikkerheden i open source-projekter og er finansieret af de organisationer, der er afhængige af disse projekter. Den udgiver også fremragende læringsressourcer, så virksomheder kan uddanne sig selv om risiciene ved den software, de bruger. En anden lignende organisation er Tidevandsløft, som samarbejder med vedligeholdere for at sikre, at visse grundlæggende krav er opfyldt, igen finansieret af organisationerne. Tidelift leverer også værktøj og uddannelse til at hjælpe virksomheder med at administrere deres softwareforsyningskæde og vedtage bedste praksis på dette område.

Sikring af en sikrere softwarefremtid

Virksomheder er afhængige af software, og dette inkluderer open source-software, som er meget udbredt og typisk mere sikker end proprietære alternativer.

Dette er et smart træk, men et endnu smartere træk er at have klar viden om softwareforsyningskæden og dens afhængigheder. Når der opstår et problem, hjælper det enhver organisation afhængig af sunde projekter og at have detaljerne om din software til rådighed. Hvis hver organisation gjorde dette, reduceres risikoen for hændelser som Log4Shell-sårbarheden.

Tidsstempel:

Mere fra Mørk læsning