Det har gått över tre år sedan Log4Shell, en kritisk sårbarhet i ett föga känt bibliotek med öppen källkod, upptäcktes. Med ett CVSS-poäng på 10 pekade dess relativa spridning och lätthet att utnyttja det ut som ett av decenniets allvarligaste mjukvarubrister. Men även år efter det att det korrigerades är mer än en av 10 nedladdningar av det populära verktyget av sårbara versioner. Något är helt klart fel någonstans.

En ny rapport från Linux Foundation har en viss användbar insikt i de systemiska utmaningar som ekosystemet med öppen källkod och dess användare står inför. Tyvärr finns det inga enkla lösningar, men slutanvändare kan åtminstone mildra några av de vanligaste riskerna genom branschens bästa praxis.

En katastrofal fallstudie

Programvarukomponenter med öppen källkod finns överallt – även utvecklare av egen kod förlitar sig på dem för att påskynda DevOps-processer. Enligt en uppskattning, 96 % av alla kodbaser innehåller komponenter med öppen källkod, och tre fjärdedelar innehåller sårbarheter med öppen källkod med hög risk. Med tanke på att det närmar sig sju biljoner komponenter laddades ner 2024, utgör detta en enorm potentiell risk för system över hela världen.

Log4j är en utmärkt fallstudie av vad som kan gå fel. Den belyser en stor synlighetsutmaning i och med att programvaran inte bara innehåller "direkta beroenden" – dvs komponenter med öppen källkod som ett program uttryckligen refererar till – utan också transitiva beroenden. De senare importeras inte direkt till ett projekt utan används indirekt av en mjukvarukomponent. I själva verket är de beroenden av direkta beroenden. Som Google förklarade vid den tiden var detta anledningen till att så många Log4j-instanser inte upptäcktes.

"Ju djupare sårbarheten är i en beroendekedja, desto fler steg krävs för att den ska åtgärdas", noterade den.

Sonatypes CTO Brian Fox förklarar att "dålig beroendehantering" i företag är en viktig källa till cybersäkerhetsrisk med öppen källkod.

"Log4j är ett bra exempel. Vi fann att 13 % av Log4j-nedladdningarna är av sårbara versioner, och detta är tre år efter att Log4Shell patchades”, säger han till ISMS.online. "Detta är inte ett problem som är unikt för Log4j heller - vi beräknade att under det senaste året hade 95 % av de sårbara komponenterna som laddades ner en fast version redan tillgänglig."

Risk med öppen källkod handlar dock inte bara om potentiella sårbarheter som dyker upp i svåra att hitta komponenter. Hotaktörer planterar också aktivt skadlig programvara i vissa komponenter med öppen källkod, i hopp om att de kommer att laddas ner. Sonatype upptäckte 512,847 2024 skadliga paket i de viktigaste ekosystemen med öppen källkod 156, en årlig ökning på XNUMX %.

Systemiska utmaningar

Log4j var bara toppen av isberget på många sätt, som en ny Linux-rapport avslöjar. Det pekar på flera betydande branschövergripande utmaningar med projekt med öppen källkod:

Äldre teknik: Många utvecklare fortsätter att förlita sig på Python 2, även om Python 3 introducerades 2008. Detta skapar problem med bakåtkompatibilitet och mjukvara för vilka patchar inte längre finns tillgängliga. Äldre versioner av mjukvarupaket finns också kvar i ekosystemen eftersom deras ersättningar ofta innehåller ny funktionalitet, vilket gör dem mindre attraktiva för användarna.

En brist på standardiserat namnschema: Namnkonventioner för programvarukomponenter är "unika, individualiserade och inkonsekventa", vilket begränsar initiativ för att förbättra säkerhet och transparens.

En begränsad pool av bidragsgivare:

"Vissa mycket använda OSS-projekt underhålls av en enda individ. När man granskade de 50 bästa projekten utanför npm hade 17 % av projekten en utvecklare och 40 % hade en eller två utvecklare som stod för minst 80 % av åtagandena, säger OpenSSFs chef för öppen källkodssäkerhet, David Wheeler. ISMS.online.

”Ett projekt med en enda utvecklare har en större risk att senare överges. Dessutom har de en större risk för försummelse eller skadlig kodinsättning, eftersom de kan sakna regelbundna uppdateringar eller peer reviews.”

Molnspecifika bibliotek: Detta kan skapa beroenden av molnleverantörer, möjliga döda vinklar för säkerhet och leverantörslåsning.

"Den största fördelen är att öppen källkod fortsätter att öka i kritikalitet för mjukvaran som driver molninfrastrukturen", säger Sonatypes Fox. "Det har skett en "hockeyklubba"-tillväxt när det gäller användning av öppen källkod, och den trenden kommer bara att fortsätta. Samtidigt har vi inte sett stöd, vare sig ekonomiskt eller på annat sätt, för underhållare av öppen källkod växa för att matcha denna konsumtion.”

Minnesosäkra språk: Antagandet av det minnessäkra Rust-språket växer, men många utvecklare föredrar fortfarande C och C++, som ofta innehåller minnessäkerhetssårbarheter.

Hur ISO 27001 kan hjälpa

As Red Hat-bidragsgivaren Herve Beraud konstaterar, borde vi ha sett Log4Shell komma eftersom själva verktyget (Log4j) inte hade genomgått regelbundna säkerhetsrevisioner och endast underhållits av ett litet volontärteam, en risk som lyfts fram ovan. Han menar att utvecklare måste tänka mer noggrant på komponenterna med öppen källkod de använder genom att ställa frågor om RoI, underhållskostnader, laglig efterlevnad, kompatibilitet, anpassningsförmåga och, naturligtvis, om de regelbundet testas för sårbarheter.

Experter rekommenderar också verktyg för analys av mjukvarusammansättning (SCA) för att förbättra insynen i komponenter med öppen källkod. Dessa hjälper organisationer att upprätthålla ett program för kontinuerlig utvärdering och patchning. Ännu bättre, överväg ett mer holistiskt tillvägagångssätt som också täcker riskhantering över proprietär programvara. ISO 27001-standarden tillhandahåller ett strukturerat ramverk för att hjälpa organisationer att förbättra sin säkerhetsställning med öppen källkod.

Detta inkluderar hjälp med:

  • Riskbedömningar och begränsningar för programvara med öppen källkod, inklusive sårbarheter eller brist på support
  • Upprätthålla en inventering av programvara med öppen källkod för att säkerställa att alla komponenter är uppdaterade och säkra
  • Åtkomstkontroller så att endast behöriga teammedlemmar kan använda eller modifiera programvara med öppen källkod
  • Säkerhetspolicyer och rutiner för användning, övervakning och uppdatering av komponenter
  • Hantering av leverantörsrelationer för att säkerställa att mjukvaruleverantörer med öppen källkod följer säkerhetsstandarderna och -praxis
  • Kontinuerlig patchhantering för att åtgärda säkerhetssårbarheter i programvara med öppen källkod
  • Incidenthanteringsprocesser, inklusive upptäckt och svar på sårbarheter eller intrång som härrör från öppen källkod
  • Främjande av en ständig förbättringskultur för att förbättra effektiviteten av säkerhetskontroller
  • Utbildning och medvetenhet för anställda för att förstå riskerna med öppen källkod

Det finns mycket mer som också kan göras, inklusive statliga program för buggar, utbildningsinsatser och samhällsfinansiering från teknikjättar och andra stora företagsanvändare av öppen källkod. Detta problem kommer inte att lösas över en natt, men hjulen har åtminstone börjat snurra.