Beveilig Oopbron in 2025 en verder: 'n Padkaart vir vordering

Dit is meer as drie jaar sedert Log4Shell, 'n kritieke kwesbaarheid in 'n min bekende oopbron-biblioteek, ontdek is. Met 'n CVSS-telling van 10, het sy relatiewe alomteenwoordigheid en gemak van uitbuiting dit uitgesonder as een van die ernstigste sagtewarefoute van die dekade. Maar selfs jare nadat dit reggemaak is, is meer as een uit elke 10 aflaaie van die gewilde nut van kwesbare weergawes. Iets is duidelik iewers verkeerd.

'N nuwe verslag van die Linux Foundation het 'n paar nuttige insig in die sistemiese uitdagings wat die oopbron-ekosisteem en sy gebruikers in die gesig staar. Ongelukkig is daar geen maklike oplossings nie, maar eindgebruikers kan ten minste sommige van die meer algemene risiko's versag deur die beste praktyke in die bedryf.

'n Katastrofiese gevallestudie

Oopbronsagtewarekomponente is oral - selfs eie kode-ontwikkelaars maak daarop staat om DevOps-prosesse te versnel. Volgens een skatting, 96% van alle kodebasisse bevat oopbronkomponente, en driekwart bevat hoërisiko oopbronkwesbaarhede. Gegewe dat nader sewe triljoen komponente is in 2024 afgelaai, dit hou 'n massiewe potensiële risiko vir stelsels regoor die wêreld in.

Log4j is 'n uitstekende gevallestudie van wat verkeerd kan gaan. Dit beklemtoon 'n groot sigbaarheidsuitdaging deurdat sagteware nie net "direkte afhanklikhede" bevat nie - dit wil sê oopbronkomponente waarna 'n program uitdruklik verwys - maar ook oorganklike afhanklikhede. Laasgenoemde word nie direk in 'n projek ingevoer nie, maar word indirek deur 'n sagtewarekomponent gebruik. In werklikheid is hulle afhanklikhede van direkte afhanklikhede. Soos Google verduidelik dit was destyds die rede waarom soveel Log4j-gevalle nie ontdek is nie.

"Hoe dieper die kwesbaarheid in 'n afhanklikheidsketting is, hoe meer stappe is nodig om dit reg te stel," het dit opgemerk.

Brian Fox, uitvoerende hoof van Sonatype, verduidelik dat "swak afhanklikheidsbestuur" in firmas 'n groot bron van oopbron-kuberveiligheidsrisiko is.

“Log4j is 'n goeie voorbeeld. Ons het gevind dat 13% van Log4j-aflaaie van kwesbare weergawes is, en dit is drie jaar nadat Log4Shell reggemaak is,” vertel hy aan ISMS.online. "Dit is ook nie 'n kwessie uniek aan Log4j nie - ons het bereken dat in die afgelope jaar, 95% van kwesbare komponente wat afgelaai is, 'n vaste weergawe reeds beskikbaar gehad het."

Oopbronrisiko gaan egter nie net oor potensiële kwesbaarhede wat in moeilik-om-te-vind komponente voorkom nie. Bedreigingsakteurs plant ook aktief wanware in sommige oopbronkomponente, met die hoop dat dit afgelaai sal word. Sonatype het in 512,847 2024 156 kwaadwillige pakkette in die belangrikste oopbron-ekosisteme ontdek, 'n jaarlikse toename van XNUMX%.

Sistemiese uitdagings

Log4j was in baie opsigte net die punt van die ysberg, soos 'n nuwe Linux-verslag onthul. Dit wys op verskeie beduidende uitdagings in die hele bedryf met oopbronprojekte:

Ouderwetse tegnologie: Baie ontwikkelaars maak steeds op Python 2 staat, al is Python 3 in 2008 bekendgestel. Dit skep probleme met terugwaartse onverenigbaarheid en sagteware waarvoor pleisters nie meer beskikbaar is nie. Ouer weergawes van sagtewarepakkette bly ook in ekosisteme voortbestaan ​​omdat hul vervangings dikwels nuwe funksionaliteit bevat, wat hulle minder aantreklik vir gebruikers maak.

'n Gebrek aan gestandaardiseerde naamskema: Naamkonvensies vir sagtewarekomponente is "uniek, geïndividualiseerd en inkonsekwent", wat inisiatiewe beperk om sekuriteit en deursigtigheid te verbeter.

'n Beperkte poel bydraers:

“Sommige wydgebruikte OSS-projekte word deur 'n enkele individu onderhou. By die hersiening van die top 50 nie-npm-projekte, het 17% van die projekte een ontwikkelaar gehad, en 40% het een of twee ontwikkelaars gehad wat verantwoordelik was vir ten minste 80% van die verpligtinge,” sê OpenSSF se direkteur van oopbronvoorsieningskettingsekuriteit, David Wheeler. ISMS.aanlyn.

''n Projek met 'n enkele ontwikkelaar het 'n groter risiko om later te laat vaar. Daarbenewens het hulle 'n groter risiko van verwaarlosing of kwaadwillige kode-invoeging, aangesien hulle nie gereelde opdaterings of portuurbeoordelings kan hê nie.

Wolk-spesifieke biblioteke: Dit kan afhanklikhede van wolkverkopers skep, moontlike blindekolle vir sekuriteit en toesluit van verskaffers.

"Die grootste wegneemete is dat oopbron steeds meer kritiek word vir die sagteware wat wolkinfrastruktuur aandryf," sê Sonatype se Fox. “Daar was 'hokkiestok'-groei in terme van oopbrongebruik, en daardie neiging sal net voortduur. Terselfdertyd het ons nie gesien dat ondersteuning, finansieel of andersins, vir oopbrononderhouers groei om by hierdie verbruik te pas nie.”

Geheue-onveilige tale: Die aanvaarding van die geheue-veilige Rust-taal groei, maar baie ontwikkelaars is steeds voorstander van C en C++, wat dikwels geheueveiligheidskwesbaarhede bevat.

Hoe ISO 27001 kan help

As Red Hat-bydraer Herve Beraud merk op, moes ons Log4Shell sien kom het omdat die nutsprogram self (Log4j) nie gereelde sekuriteitsoudits ondergaan het nie en slegs deur 'n klein vrywilligerspan onderhou is, 'n risiko wat hierbo uitgelig is. Hy voer aan dat ontwikkelaars noukeuriger moet dink oor die oopbronkomponente wat hulle gebruik deur vrae te vra oor RoI, onderhoudskoste, wetlike nakoming, versoenbaarheid, aanpasbaarheid, en natuurlik of hulle gereeld vir kwesbaarhede getoets word.

Kenners beveel ook sagtewaresamestelling-analise (SCA)-nutsgoed aan om sigbaarheid in oopbronkomponente te verbeter. Dit help organisasies om 'n program van deurlopende evaluering en pleister te handhaaf. Beter nog, oorweeg 'n meer holistiese benadering wat ook risikobestuur oor eie sagteware dek. Die ISO 27001-standaard lewer 'n gestruktureerde raamwerk om organisasies te help om hul oopbron-sekuriteitsposisie te verbeter.

Dit sluit hulp in met:

• Risikobepalings en versagtings vir oopbronsagteware, insluitend kwesbaarhede of gebrek aan ondersteuning
• Die handhawing van 'n voorraad oopbronsagteware om te verseker dat alle komponente op datum en veilig is
• Toegangskontroles sodat slegs gemagtigde spanlede oopbronsagteware kan gebruik of wysig
• Sekuriteitsbeleide en -prosedures oor die gebruik, monitering en opdatering van komponente
• Verskafferverhoudingbestuur om te verseker dat oopbronsagtewareverskaffers aan die sekuriteitstandaarde en -praktyke voldoen
• Deurlopende pleisterbestuur om sekuriteitskwesbaarhede in oopbronsagteware aan te spreek
• Insidentbestuursprosesse, insluitend opsporing en reaksie op kwesbaarhede of oortredings wat voortspruit uit oopbron
• Bevordering van 'n deurlopende verbeteringskultuur om die doeltreffendheid van sekuriteitskontroles te verbeter
• Opleiding en bewustheid vir werknemers om die risiko's wat verband hou met oopbronsagteware te verstaan

Daar is baie meer wat ook gedoen kan word, insluitend die regering se fout-prysgeldprogramme, opvoedingspogings en gemeenskapsbefondsing van tegnologiereuse en ander groot ondernemingsgebruikers van oopbron. Hierdie probleem sal nie oornag opgelos word nie, maar die wiele het darem begin draai.