Avoimen lähdekoodin turvaaminen vuonna 2025 ja sen jälkeen: etenemissuunnitelma

On kulunut yli kolme vuotta siitä, kun Log4Shell, kriittinen haavoittuvuus vähän tunnetussa avoimen lähdekoodin kirjastossa, löydettiin. CVSS-pistemäärä 10, sen suhteellinen yleisyys ja helppokäyttöisyys nostivat sen yhdeksi vuosikymmenen vakavimmista ohjelmistovirheistä. Mutta jopa vuosia sen korjauksen jälkeen, enemmän kuin yksi kymmenestä suositun apuohjelman latauksesta on haavoittuvia versioita. Jotain on selvästi vialla jossain.

Uusi raportti aiheesta Linux-säätiö on hyödyllistä tietoa avoimen lähdekoodin ekosysteemin ja sen käyttäjien kohtaamista systeemisistä haasteista. Valitettavasti helppoja ratkaisuja ei ole, mutta loppukäyttäjät voivat ainakin lieventää joitain yleisimmistä riskeistä alan parhaiden käytäntöjen avulla.

Katastrofaalinen tapaustutkimus

Avoimen lähdekoodin ohjelmistokomponentteja on kaikkialla – jopa patentoidun koodin kehittäjät luottavat niihin nopeuttaessaan DevOps-prosesseja. Mukaan yksi arvio, 96 % kaikista koodikannoista sisältää avoimen lähdekoodin komponentteja ja kolme neljäsosaa sisältää riskialttiita avoimen lähdekoodin haavoittuvuuksia. Ottaen huomioon, että lähestyy seitsemän biljoonaa komponentit ladattiin vuonna 2024, mikä aiheuttaa valtavan mahdollisen riskin järjestelmille kaikkialla maailmassa.

Log4j on erinomainen tapaustutkimus siitä, mikä voi mennä pieleen. Se korostaa suurta näkyvyyshaastetta siinä, että ohjelmisto ei sisällä vain "suoria riippuvuuksia" – eli avoimen lähdekoodin komponentteja, joihin ohjelma nimenomaisesti viittaa – vaan myös transitiivisia riippuvuuksia. Viimeksi mainittuja ei tuoda suoraan projektiin, vaan ohjelmistokomponentti käyttää niitä epäsuorasti. Itse asiassa ne ovat riippuvuuksia suorista riippuvuuksista. Kuten Google selitti tuolloin tämä oli syy siihen, miksi niin monia Log4j-esiintymiä ei löydetty.

"Mitä syvemmällä haavoittuvuus on riippuvuusketjussa, sitä enemmän vaiheita tarvitaan sen korjaamiseen", se huomautti.

Sonatypen teknologiajohtaja Brian Fox selittää, että yritysten "huono riippuvuuden hallinta" on merkittävä avoimen lähdekoodin kyberturvallisuusriskin lähde.

”Log4j on hyvä esimerkki. Löysimme, että 13 % Log4j-latauksista on haavoittuvia versioita, ja tämä on kolme vuotta Log4Shellin korjauksen jälkeen”, hän kertoo ISMS.online-sivustolle. "Tämä ei myöskään ole Log4j:n ainutlaatuinen ongelma - laskemme, että viime vuonna 95 prosentilla ladatuista haavoittuvista komponenteista oli jo saatavilla kiinteä versio."

Avoimen lähdekoodin riski ei kuitenkaan liity vain mahdollisiin haavoittuvuuksiin, joita esiintyy vaikeasti löydettävissä komponenteissa. Uhkatoimijat istuttavat myös aktiivisesti haittaohjelmia joihinkin avoimen lähdekoodin komponentteihin toivoen, että ne ladataan. Sonatype löysi 512,847 2024 haittapakettia tärkeimmistä avoimen lähdekoodin ekosysteemeistä vuonna 156, mikä on XNUMX %:n vuosikasvu.

Systeemiset haasteet

Log4j oli vain jäävuoren huippu monella tapaa, kuten uusi Linux-raportti paljastaa. Se viittaa useisiin merkittäviin alan laajuisiin haasteisiin avoimen lähdekoodin projekteissa:

Vanha tekniikka: Monet kehittäjät luottavat edelleen Python 2:een, vaikka Python 3 esiteltiin vuonna 2008. Tämä aiheuttaa taaksepäin yhteensopivuusongelmia ja ohjelmistoja, joihin ei ole enää saatavilla korjaustiedostoja. Myös ohjelmistopakettien vanhemmat versiot säilyvät ekosysteemeissä, koska niiden korvaamiset sisältävät usein uusia toimintoja, mikä tekee niistä vähemmän houkuttelevia käyttäjille.

Standardoidun nimiskeeman puute: Ohjelmistokomponenttien nimeämiskäytännöt ovat "ainutlaatuisia, yksilöllisiä ja epäjohdonmukaisia", mikä rajoittaa turvallisuutta ja läpinäkyvyyttä parantavia aloitteita.

Rajoitettu joukko osallistujia:

”Joitakin laajalti käytettyjä OSS-projekteja ylläpitää yksi henkilö. Kun tarkasteltiin 50 parasta ei-npm-projektia, 17 prosentissa projekteista oli yksi kehittäjä ja 40 prosentissa yksi tai kaksi kehittäjää, joiden osuus sitoumuksista oli vähintään 80 prosenttia”, OpenSSF:n avoimen lähdekoodin toimitusketjun turvallisuuden johtaja David Wheeler kertoo. ISMS.online.

”Yhden kehittäjän projektissa on suurempi riski myöhemmin luopumisesta. Lisäksi heillä on suurempi riski laiminlyönnistä tai haitallisen koodin lisäämisestä, koska heiltä saattaa puuttua säännöllisiä päivityksiä tai vertaisarviointeja."

Pilvikohtaiset kirjastot: Tämä voi luoda riippuvuuksia pilvitoimittajista, mahdollisia suojauksen kuolleita kulmia ja toimittajan lukkiutumista.

"Suurin huomio on se, että avoimen lähdekoodin kriittisyys pilviinfrastruktuuria käyttävälle ohjelmistolle kasvaa jatkuvasti", sanoo Sonatype's Fox. ”Avoimen lähdekoodin käytössä on ollut ”hockeymail”-kasvua, ja tämä trendi vain jatkuu. Samaan aikaan emme ole nähneet avoimen lähdekoodin ylläpitäjien taloudellisen tai muun tuen kasvavan vastaamaan tätä kulutusta.

Muistille vaaralliset kielet: Muistiturvallisen Rust-kielen omaksuminen yleistyy, mutta monet kehittäjät suosivat edelleen C- ja C++-kieliä, jotka sisältävät usein muistin turvallisuushaavoittuvuuksia.

Miten ISO 27001 voi auttaa?

As Red Hatin avustaja Herve Beraud huomauttaa, meidän olisi pitänyt nähdä Log4Shell tulossa, koska itse apuohjelmalle (Log4j) ei ollut tehty säännöllisiä tietoturvatarkastuksia ja sitä ylläpiti vain pieni vapaaehtoistiimi, mikä on edellä korostettu riski. Hän väittää, että kehittäjien on harkittava tarkemmin käyttämiään avoimen lähdekoodin komponentteja esittämällä kysymyksiä sijoitetun pääoman tuotosta, ylläpitokustannuksista, lainmukaisuudesta, yhteensopivuudesta, sopeutumisesta ja tietysti siitä, testataanko ne säännöllisesti haavoittuvuuksien varalta.

Asiantuntijat suosittelevat myös ohjelmiston koostumusanalyysin (SCA) työkaluja avoimen lähdekoodin komponenttien näkyvyyden parantamiseksi. Nämä auttavat organisaatioita ylläpitämään jatkuvaa arviointi- ja korjausohjelmaa. Vielä parempi, harkitse kokonaisvaltaisempaa lähestymistapaa, joka kattaa myös riskienhallinnan kaikissa patentoiduissa ohjelmistoissa. ISO 27001 -standardi tarjoaa rakenteellisen kehyksen, joka auttaa organisaatioita parantamaan avoimen lähdekoodin tietoturva-asentoaan.

Tämä sisältää apua:

• Avoimen lähdekoodin ohjelmistojen riskinarvioinnit ja lievennykset, mukaan lukien haavoittuvuudet tai tuen puute
• Avoimen lähdekoodin ohjelmistojen luettelon ylläpitäminen varmistaaksesi, että kaikki komponentit ovat ajan tasalla ja turvallisia
• Pääsyn hallinta, jotta vain valtuutetut tiimin jäsenet voivat käyttää tai muokata avoimen lähdekoodin ohjelmistoja
• Komponenttien käyttöä, valvontaa ja päivitystä koskevat tietoturvakäytännöt ja -menettelyt
• Toimittajasuhteiden hallinta varmistaa, että avoimen lähdekoodin ohjelmistotoimittajat noudattavat turvallisuusstandardeja ja -käytäntöjä
• Jatkuva korjaustiedostojen hallinta avoimen lähdekoodin ohjelmistojen tietoturva-aukkojen korjaamiseksi
• Tapahtumanhallintaprosessit, mukaan lukien avoimesta lähdekoodista peräisin olevien haavoittuvuuksien tai rikkomusten havaitseminen ja niihin reagoiminen
• Jatkuvan parannuskulttuurin edistäminen turvavalvonnan tehokkuuden parantamiseksi
• Koulutus ja tietoisuus työntekijöille avoimen lähdekoodin ohjelmistoihin liittyvien riskien ymmärtämiseksi

On myös paljon muuta, mitä voidaan tehdä, mukaan lukien hallituksen bugipalkkioohjelmat, koulutustoimet ja yhteisön rahoitus teknologiajättiläisiltä ja muilta avoimen lähdekoodin suurilta yrityksiltä. Tämä ongelma ei ratkea yhdessä yössä, mutta ainakin pyörät ovat alkaneet pyöriä.