Sikring af Open Source i 2025 og videre: En køreplan for fremskridt
Indholdsfortegnelse:
Det er over tre år siden Log4Shell, en kritisk sårbarhed i et lidet kendt open source-bibliotek, blev opdaget. Med en CVSS-score på 10 fremhævede dens relative allestedsnærværelse og lette udnyttelse det som en af de mest alvorlige softwarefejl i årtiet. Men selv år efter, at det blev patchet, er mere end én ud af 10 downloads af det populære værktøj af sårbare versioner. Der er tydeligvis noget galt et eller andet sted.
En ny rapport fra Linux Foundation har en nyttig indsigt i de systemiske udfordringer, som open source-økosystemet og dets brugere står over for. Desværre er der ingen nemme løsninger, men slutbrugere kan i det mindste mindske nogle af de mere almindelige risici gennem industriens bedste praksis.
Et katastrofalt casestudie
Open source-softwarekomponenter er overalt - selv proprietære kodeudviklere er afhængige af dem for at accelerere DevOps-processer. Ifølge et skøn, 96 % af alle kodebaser indeholder open source-komponenter, og tre fjerdedele indeholder højrisiko open source-sårbarheder. Da det nærmer sig syv billioner komponenter blev downloadet i 2024, udgør dette en massiv potentiel risiko for systemer over hele kloden.
Log4j er et glimrende casestudie af, hvad der kan gå galt. Det fremhæver en stor synlighedsudfordring, idet softwaren ikke kun indeholder "direkte afhængigheder" - dvs. open source-komponenter, som et program eksplicit refererer til - men også transitive afhængigheder. Sidstnævnte importeres ikke direkte til et projekt, men bruges indirekte af en softwarekomponent. Faktisk er de afhængigheder af direkte afhængigheder. Som Google forklarede på det tidspunkt var dette grunden til, at så mange Log4j-forekomster ikke blev opdaget.
"Jo dybere sårbarheden er i en afhængighedskæde, jo flere trin kræves der for at blive rettet," bemærkes det.
Sonatype CTO Brian Fox forklarer, at "dårlig afhængighedsstyring" i virksomheder er en vigtig kilde til open source cybersikkerhedsrisiko.
“Log4j er et godt eksempel. Vi fandt, at 13 % af Log4j-downloads er af sårbare versioner, og det er tre år efter, at Log4Shell blev patchet,” siger han til ISMS.online. "Dette er heller ikke et problem unikt for Log4j - vi beregnede, at i det sidste år havde 95 % af de sårbare komponenter, der blev downloadet, en fast version allerede tilgængelig."
Open source-risiko handler dog ikke kun om potentielle sårbarheder, der dukker op i komponenter, der er svære at finde. Trusselaktører planter også aktivt malware i nogle open source-komponenter i håb om, at de vil blive downloadet. Sonatype opdagede 512,847 ondsindede pakker i de vigtigste open source-økosystemer i 2024, en årlig stigning på 156 %.
Systemiske udfordringer
Log4j var på mange måder kun toppen af isbjerget, som en ny Linux-rapport afslører. Det peger på flere væsentlige brancheomspændende udfordringer med open source-projekter:
Ældre teknologi: Mange udviklere er fortsat afhængige af Python 2, selvom Python 3 blev introduceret i 2008. Dette skaber problemer med baglæns inkompatibilitet og software, som patches ikke længere er tilgængelige for. Ældre versioner af softwarepakker fortsætter også i økosystemer, fordi deres erstatninger ofte indeholder ny funktionalitet, hvilket gør dem mindre attraktive for brugerne.
Manglende standardiseret navngivningsskema: Navnekonventioner for softwarekomponenter er "unikke, individualiserede og inkonsekvente", hvilket begrænser initiativer til at forbedre sikkerhed og gennemsigtighed.
En begrænset pulje af bidragydere:
"Nogle udbredte OSS-projekter vedligeholdes af en enkelt person. Når man gennemgik de 50 bedste ikke-npm-projekter, havde 17 % af projekterne én udvikler, og 40 % havde en eller to udviklere, der stod for mindst 80 % af tilsagnene, siger OpenSSF-direktør for open source-forsyningskædesikkerhed, David Wheeler. ISMS.online.
”Et projekt med en enkelt udvikler har større risiko for senere at blive opgivet. Derudover har de en større risiko for forsømmelse eller ondsindet kodeindsættelse, da de kan mangle regelmæssige opdateringer eller peer reviews.”
Sky-specifikke biblioteker: Dette kan skabe afhængigheder af cloud-leverandører, mulige blinde vinkler for sikkerhed og leverandørlåsning.
"Den største takeaway er, at open source fortsætter med at stige i kritikalitet for den software, der driver cloud-infrastruktur," siger Sonatypes Fox. "Der har været 'hockey stick' vækst i form af open source-brug, og den tendens vil kun fortsætte. Samtidig har vi ikke set støtte, hverken økonomisk eller på anden måde, til open source-vedligeholdere vokse til at matche dette forbrug."
Hukommelsesusikre sprog: Indførelsen af det hukommelsessikre Rust-sprog vokser, men mange udviklere foretrækker stadig C og C++, som ofte indeholder hukommelsessikkerhedssårbarheder.
Hvordan ISO 27001 kan hjælpe
As Red Hat-bidragyder Herve Beraud bemærker, burde vi have set Log4Shell komme, fordi selve hjælpeprogrammet (Log4j) ikke havde gennemgået regelmæssige sikkerhedsrevisioner og kun blev vedligeholdt af et lille frivilligt team, en risiko fremhævet ovenfor. Han argumenterer for, at udviklere skal tænke mere omhyggeligt over de open source-komponenter, de bruger, ved at stille spørgsmål om RoI, vedligeholdelsesomkostninger, lovoverholdelse, kompatibilitet, tilpasningsevne og, selvfølgelig, om de regelmæssigt testes for sårbarheder.
Eksperter anbefaler også værktøjer til analyse af softwaresammensætning (SCA) for at øge synligheden af open source-komponenter. Disse hjælper organisationer med at opretholde et program med løbende evaluering og patching. Endnu bedre, overvej en mere holistisk tilgang, der også dækker risikostyring på tværs af proprietær software. ISO 27001-standarden leverer en struktureret ramme til at hjælpe organisationer med at forbedre deres open source-sikkerhedsposition.
Dette inkluderer hjælp til:
- Risikovurderinger og begrænsninger for open source-software, herunder sårbarheder eller manglende support
- Vedligeholdelse af en beholdning af open source-software for at sikre, at alle komponenter er opdaterede og sikre
- Adgangskontroller, så kun autoriserede teammedlemmer kan bruge eller ændre open source-software
- Sikkerhedspolitikker og procedurer for brug, overvågning og opdatering af komponenter
- Administration af leverandørforhold for at sikre, at open source-softwareudbydere overholder sikkerhedsstandarderne og -praksis
- Kontinuerlig patch-administration for at løse sikkerhedssårbarheder i open source-software
- Hændelseshåndteringsprocesser, herunder opdagelse og reaktion på sårbarheder eller brud, der stammer fra open source
- Fremme af en kontinuerlig forbedringskultur for at øge effektiviteten af sikkerhedskontrollen
- Uddannelse og bevidsthed for medarbejdere til at forstå de risici, der er forbundet med open source-software
Der er meget mere, der også kan gøres, herunder offentlige bug-bounty-programmer, uddannelsesindsatser og fællesskabsfinansiering fra teknologigiganter og andre store virksomhedsbrugere af open source. Dette problem bliver ikke løst fra den ene dag til den anden, men i det mindste er hjulene begyndt at dreje.
