Företag som använder öppen källkod – som är inbäddad i en stor majoritet av företagsmjukvara – behöver en fullskalig inventering av dess existens. Det saknas i många företags IT-register.
Utan en detaljerad redovisning av öppen källkod som körs i deras programvara har företag inget sätt att övervaka programvarupolicyer, licenser, sårbarheter och versioner. Det betyder att IT-avdelningar har aning om den övergripande hälsan hos komponenterna med öppen källkod de använder.
Problemet är att många företag är säkra på att de inte använder öppen källkod, så de behöver inte oroa sig för att hålla säkerhetskorrigeringar och koduppgraderingar aktuella. Den missuppfattningen leder vanligtvis till nätverksintrång som leder till skadlig programvara och ransomware-attacker.
2022 Synopsys Öppen källkod Säkerhet och riskanalys (OSSRA) Rapport som släpptes förra månaden visade en all-time high för öppen källkod som körs i programvara. Problemet med att använda öppen källkod har ökat konsekvent år efter år.
Öppen källkod är utbredd i programvarupaket från affärsapplikationer till nätverks- och serverprocesser. Om inte företag gör en samlad ansträngning för att katalogisera och övervaka hur deras organisationer använder utdrag med öppen källkod, går även kända sårbarheter obevakade.
Att åtgärda problemen som rapporten lyfter fram är en fråga om ägande, enligt Tim Mackey, huvudsäkerhetsstrateg på Synopsys SIG.
Resultaten tyder på en tyst insikt om att programvaran som driver företag kanske inte är under deras chefers kontroll. Det signalerar också att öppen källkod i kommersiella produkter kanske inte uppfyller de standarder som de håller sina egna team ansvariga för.
“Med tanke på OSSRAs källdata kommer från tekniska due diligence-insatser relaterade till fusioner och förvärvsaktiviteter, och inte en undersökning, är OSSRA-rapporten en återspegling av det nuvarande tillståndet för programvaruanvändning och inte åsikten om vad det kan vara,” Mackey berättade för LinuxInsider.
Hårda sanningar avslöjade
OSSRA-rapporten 2022 granskade anonymiserade resultat från över 2 400 kommersiella kodbaser i 17 branscher. Sammanfattningsresultaten i den här bilden är en väckarklocka till företagets IT-övervakare.
Källa: 2022 års säkerhets- och riskanalysrapport med öppen källkod (kredit: Synopsys)
Rapporten fungerar som en krisvarning, särskilt i ljuset av den pågående effekten av Log4J-sårbarheten som dök upp i slutet av förra året.
Av de 2 400 kommersiella kodbaserna i 17 branscher innehöll 2 097 säkerhets- och operativa riskbedömningar. Tillväxten av antalet kodbaser som Synopsys granskade är 64 procent större än förra årets. Mycket av den ökningen berodde på fusioner och förvärv under 2021.
Säkerhetshoten till följd av Log4j var en betydande anledning till att president Biden i slutet av förra året drev sin verkställande order om cybersäkerhet, noterade Mackey.
Det var också nyckeln för OSSRA-rapporten att motivera företagschefer för informationssäkerhet, vice verkställande direktörer och tekniska chefer att analysera deras användning av programvara med öppen källkod och se hur väl OSSRA-data mappar till deras egna processer och styrning.
“OSSRA-rapporten har konsekvent belyst att problemet med öppen källkod inte ligger i själva koden med öppen källkod, utan i hur människor använder den”, tillade han. “Fritt nedladdningsbar kod är underbart för plånboken, men det betyder inte att den kan hanteras med samma processer som du kan hitta för kommersiell programvara.”
SBOM Ingen Universal Fix
En nyckelsats i OSSRA-rapporten är att risker kan härröra från ohanterad användning av öppen källkod. Skillnaden är betydande mellan brist på öppen källkodshantering och det faktum att öppen källkod i sig inte är problemet, avslutas rapporten.
Öppen källkod är nu grunden för kommersiell programvara, konstaterade forskare. Det finns i 97 procent av kommersiell programvara. Trots dess universella användning kvarstår missuppfattningen att öppen källkod på något sätt är farligt.
Till skillnad från Microsoft och Apples produkter, där programvaruleverantörer proaktivt kan skicka uppdateringar och patchar till kända användare, har öppen källkod ingen sådan leverantör för att hantera riskhanteringsproblem, observerade Mackey.
“Befintliga patchhanteringslösningar är ofta inriktade på en uppdateringsmodell,” tillade han. “Programvara som är fritt nedladdningsbar innebär att mjukvarutillverkaren inte vet vilka kunderna är eller ens om de använder programvaran de laddade ner.
Patchprocessen och dess antaganden går vilse när människor fokuserar på ämnen som Programvarulista (SBOM) är en silverkula för hantering av öppen källkod, enligt Mackey. Att åtgärda problemet kräver att man går längre än SBOM.
SBOM är helt enkelt ett verktyg för att förbättra processer som är designade för en annan typ av mjukvarukonsumtion, sa han. Dessutom måste industrier fokusera på att identifiera och övervaka komponenter med öppen källkod i den kommersiella programvara de använder. Det är vad som måste hända för att rätta till det som OSSRA-rapporten visar är problem, sa Mackey.
Fixa det som är fixbart
Att använda föråldrade komponenter med öppen källkod kräver att företag antar en process för att övervaka när deras komponenter blir inaktuella. Men det är inte bara att uttryckligen deklarera beroenden eller välja godkända leverantörer. Mackey ser problemet som mer djupt rotat i försörjningskedjan.
“Log4Shell-upplevelsen är ett perfekt exempel på en grundläggande komponent som få visste fanns. Men när Log4j väl blev framme på grund av effekten av Log4Shell-sårbarheten, [it] tvingade team att skynda sig och ta reda på hur man bäst hanterar det”, påpekade han.
Det är lösningen företagsanvändare av kommersiell programvara måste göra. Inventera förekomsten av komponenter med öppen källkod. Sedan upprätta och exekvera övervakning och patchning och uppdatering.
“Oavsett processer som dessa team använde för att framgångsrikt hantera sin Log4j-upplevelse i stor skala bör tillämpas på andra komponenter. Med andra ord, använd Log4j-upplevelsen för att bygga en mer skalbar lösning för din organisation”, uppmanade Mackey.