La sicurezza informatica open source è una bomba a orologeria

A marzo, un bug del software ha minacciato di far deragliare vaste aree del web. Si è scoperto che XZutils , uno strumento di compressione open source incorporato in una miriade di prodotti software e sistemi operativi, è stato impiantato con una backdoor.

La backdoor, un punto di ingresso clandestino nel software, avrebbe consentito a una persona con il codice richiesto di prendere il controllo delle macchine che lo eseguivano e di impartire comandi come amministratore. Se la backdoor fosse stata ampiamente diffusa, sarebbe stato un potenziale disastro per milioni di persone.

Per fortuna, prima che l'aggiornamento dannoso potesse essere diffuso su vasta scala, un ingegnere informatico di Microsoft ha notato delle irregolarità nel codice e l'ha segnalato. Il progetto è stato successivamente requisito dalle parti responsabili e da allora è stato risolto.

Sebbene il disastro sia stato evitato per un pelo, l’episodio ha messo in luce le attuali passività nel modello di sviluppo open source che sono di lunga data e non facilmente risolvibili. L'episodio di XZ non è certo il primo in cui un bug open source ha minacciato di far deragliare vaste aree del web. Certamente non sarà l'ultimo. Comprendere i fastidiosi dilemmi di sicurezza informatica posti dal software open source richiede un tour attraverso il suo ecosistema bizantino e non del tutto intuitivo. Ecco, per chi non lo sapesse, il nostro tentativo di offrirvi quel tour.

Il Web funziona su FOSS

Oggi, la stragrande maggioranza delle basi di codice si basa su codice open source. Si stima che dal 70 al 90 per cento di tutti gli “ stack ” software ne siano composti. Con ogni probabilità, la stragrande maggioranza delle app del tuo telefono sono state progettate con esso e, se sei una dei 2,5 miliardi di persone al mondo che utilizzano Android, il sistema operativo del tuo dispositivo è una versione modificata del software che ha avuto origine con il kernel Linux , il più grande progetto open source al mondo.

Quando le persone parlano di “ catene di fornitura ” del software, ovvero l’impalcatura digitale che supporta i nostri prodotti e servizi web preferiti, gran parte di quel codice è costituito da componenti open source. La sua ubiquità ha portato gli osservatori a riferirsi all’open source come all’“ infrastruttura critica ” di Internet, una sostanza proteiforme che è allo stesso tempo indispensabile e incredibilmente potente.

Tuttavia, per quanto importante, il software open source rimane un argomento non ampiamente compreso dalla maggior parte delle persone al di fuori del settore tecnologico. La maggior parte delle persone non ne ha mai nemmeno sentito parlare.

Perché utilizzare l'Open Source?

Per chi non lo sapesse, una rapida spiegazione potrebbe essere questa: a differenza del software “chiuso” o proprietario, il software libero e open source, o FOSS, è ispezionabile pubblicamente e può essere utilizzato o modificato da chiunque. Il suo utilizzo è determinato da una serie di accordi di licenza e, cosa piuttosto unica, i componenti sono spesso gestiti da volontari, sviluppatori non retribuiti che trascorrono il loro tempo libero mantenendo il software aggiornato e in buone condizioni di funzionamento.

I progetti open source possono iniziare praticamente come qualsiasi cosa. Spesso si tratta di piccoli progetti per armeggiatori digitali che vogliono semplicemente costruire qualcosa di nuovo. Alla fine, alcuni progetti diventeranno popolari e le aziende private inizieranno a incorporarli nei loro codici base commerciali. In molti casi, quando un team di sviluppo aziendale decide di creare una nuova applicazione, la costruirà utilizzando una vasta gamma di componenti software più piccoli e già esistenti, costituiti da centinaia o addirittura migliaia di righe di codice. Al giorno d'oggi, la maggior parte di questi componenti proviene dalla comunità open source.

Può essere difficile immaginare come funzioni questa strana relazione tra software commerciale ed ecosistema open source. Fortunatamente, diversi anni fa l’ artista del webcomic Randall Munroe creò quello che oggi è un meme ben noto che aiuta a visualizzare questa dinamica controintuitiva:

Ci sono molte ragioni per cui le aziende si rivolgono all'open source per le loro esigenze di sviluppo. A parte il fatto che è gratuito, FOSS consente anche di creare software con efficienza e velocità. Se un programmatore non deve preoccuparsi degli elementi fondamentali del codice di un'applicazione, può concentrarsi sugli elementi più commerciabili del software. In un ambiente competitivo come la Silicon Valley, dove un rapido time to market è un vantaggio fondamentale, l’open source è praticamente un imperativo DevOps.

Ma con la velocità e l’agilità arriva la vulnerabilità. Se il FOSS è un elemento onnipresente del software moderno, ci sono anche problemi strutturali con l’ecosistema che mettono a rischio enormi quantità di software. Questi problemi possono diventare piuttosto complicati molto rapidamente, spesso con risultati disastrosi.

Insetti dall'inferno

L'episodio di XZ non si è concluso con un disastro, ma avrebbe potuto facilmente. Un caso in cui gli utenti web non sono stati così fortunati è stato il famigerato incidente “log4shell”. Tre anni fa, nel novembre 2021, è stata scoperta una vulnerabilità del codice nell'allora popolare programma open source log4j. Una libreria di registrazione , programmi come log4j vengono regolarmente integrati nelle app, dove i programmatori li utilizzano per registrare e valutare i processi interni di un programma. Log4j, gestito dall'organizzazione open source Apache , era ampiamente utilizzato al momento della scoperta del bug ed era incorporato in milioni di applicazioni in tutto il mondo.

Sfortunatamente, il bug di log4j, soprannominato " log4shell ", era piuttosto grave . Come il bug XZ, prevedeva l'esecuzione di codice remoto. Ciò significava che un hacker poteva facilmente iniettare il proprio codice “arbitrario” in un programma interessato, consentendogli di dirottare la macchina che lo eseguiva. A causa della popolarità di log4j, la portata del bug era enorme. Sono state colpite le principali aziende multimiliardarie. Centinaia di milioni di dispositivi erano vulnerabili. Nei giorni successivi alla scoperta della falla, gli esperti stimavano che le vulnerabilità fossero una bomba a orologeria e che i criminali informatici stessero già cercando di sfruttarle.

La scoperta del bug mandò le multinazionali americane nel panico totale e spaventò i più alti livelli del governo federale. Alcune delle più grandi aziende del mondo erano a rischio , rendendo la situazione una questione di sicurezza nazionale. Diverse settimane dopo la scoperta del bug, Anne Neuberger, uno dei principali consulenti per la sicurezza informatica del presidente Joe Biden, ha convocato un vertice della Casa Bianca sulla sicurezza open source, invitando dirigenti di Microsoft, Meta, Google, Amazon, IBM e altri grandi nomi, oltre a influenti organizzazioni open source come Apache, Linux Foundation e Linux's Open Source Security Foundation o OSSF. L’ incontro era meno concentrato su come porre rimedio a questa vulnerabilità infernale che su come impedire che questo genere di cose si ripeta.

Non molto tempo dopo l’incontro, i massimi dirigenti della Linux Foundation, compreso l’allora direttore generale dell’OSSF Brian Behlendorf, iniziarono a formulare un cosiddetto “piano di mobilitazione” per proteggere meglio l’intero ecosistema FOSS. Il governo federale, nel frattempo, ha iniziato a sviluppare le proprie strategie per regolamentare ulteriormente il settore tecnologico. In particolare, il piano di sicurezza informatica del presidente Biden , pubblicato lo scorso anno, ha cercato di dare priorità a una serie di nuove misure di salvaguardia per prevenire l’emergere di nuovi bug altamente distruttivi.

Tuttavia, come dimostrano i pericoli che circondano la vulnerabilità XZ, FOSS è ancora un ambiente che, ai suoi livelli più alti, è vulnerabile a bug che potrebbero avere implicazioni catastrofiche a livello di sistema per Internet. Comprendere i rischi del FOSS, tuttavia, non è facile. Richiede una deviazione nell'ecosistema unico che produce gran parte del software mondiale.

Closed Source non significa più sicuro

Prima di andare oltre, sarebbe utile chiarire una cosa: solo perché un programma software è "closed source" o proprietario non significa che sia più sicuro. In effetti, gli esperti di sicurezza e i sostenitori del FOSS sostengono che è vero il contrario. Riprenderemo l'argomento più tardi ma, per il momento, mi limiterò a indirizzare la vostra attenzione su una piccola azienda chiamata Microsoft. Questa azienda, nonostante sia un importante colosso aziendale closed-source, ha subito attacchi hacker alla sua base di prodotti innumerevoli volte , a volte con effetti disastrosi. Molte aziende che mantengono chiusi i propri prodotti hanno precedenti simili e, a differenza dei software open source, i loro problemi di sicurezza sono spesso tenuti segreti, poiché nessuno tranne l’azienda ha accesso al codice.

I manutentori

Se vuoi parlare dei rischi per la sicurezza nel software open source, devi iniziare parlando delle persone dietro il codice. Nell’ecosistema open source, queste persone sono conosciute come “ manutentori ” e, come ci si potrebbe aspettare, sono incaricate di mantenere la qualità del software.

Spiegare il ruolo del manutentore è un po’ complicato. I manutentori potrebbero essere giustamente paragonati agli operai edili che, nel mondo reale, costruiscono le nostre strade e i nostri ponti. Oppure gli ingegneri che li progettano. O entrambi. In breve, un manutentore è il custode (e spesso il creatore) di un particolare progetto open source ma, in molti casi, lavora insieme ai “contributori”, ovvero gli utenti del software che desiderano apportare miglioramenti al codice.

I manutentori ospitano i loro progetti open source su repository pubblici, il più popolare dei quali è Github . Questi repository includono meccanismi interattivi che sono in ultima analisi controllati dal manutentore. Ad esempio, quando un collaboratore desidera aggiungere qualcosa a un progetto, potrebbe inviare una " richiesta pull " su GitHub, che include il nuovo codice che spera di aggiungere. Al manutentore viene quindi assegnato il compito di approvare una “fusione”, che aggiornerà il progetto per riflettere le modifiche del contributore. È attraverso questo processo collaborativo che i progetti open source crescono e si trasformano continuamente.

In qualità di controllore principale di questi progetti viventi e iterativi, il lavoro del manutentore spesso richiede un'enorme quantità di lavoro: tutto, dalla corrispondenza continua con utenti e contributori, alla firma di commit di codice, alla creazione di guide di " documentazione " che mostrano come tutto all'interno del il software funziona davvero. Eppure, nonostante tutto questo lavoro, molti manutentori non sono pagati particolarmente bene. La maggior parte non viene pagata affatto . L'open source dovrebbe essere gratuito, ricordi? Nel mondo FOSS, il duro lavoro viene ripagato con poco più che la consapevolezza che il tuo codice viene messo a frutto.

La situazione del manutentore è peculiare ed è molto legata alla complicata storia dell'open source, così come al suo rapporto non del tutto semplice con le aziende che utilizzano il suo codice.

Una storia flash di FOSS

È utile considerare che, all'inizio, l'open source non aveva molto a che fare con il corporativismo o il denaro. In realtà, era esattamente il contrario.

FOSS è nato da un movimento hacker idealista degli anni '80 chiamato movimento del "software libero" . A tutti gli effetti, quel movimento ebbe inizio con Richard Stallman, un eccentrico informatico che somiglia un po’ a Jerry Garcia e che da tempo sposa una forma audace di idealismo cibernetico. Nel 1983, mentre lavorava al Laboratorio di Intelligenza Artificiale del MIT, Stallman fondò GNU , un archivio di software libero. L'idea alla base della collezione era il controllo dell'utente. Stallman era contrario all’idea che le aziende private potessero tenere il software dietro un giardino recintato. Riteneva che gli utenti del software avessero bisogno della capacità di controllare i programmi che utilizzavano, di vedere come funzionavano e di cambiarli o modificarli se lo desideravano. In quanto tale, Stallman postulò l’idea di software “libero”, commentando notoriamente che intendeva libero “come la libertà di parola, non come la birra gratis”. Ciò significa che Stallman non è contrario al pagamento degli sviluppatori, ma il loro codice dovrebbe essere aperto e visibile a tutti per futuri miglioramenti.

Nel 1991, Linus Torvalds, uno studente finlandese di programmazione informatica allora ventunenne, stimolò la successiva grande innovazione nella storia dell'open source. Secondo quanto riferito , per noia , Torvalds creò un nuovo sistema operativo e gli diede il nome di se stesso, chiamandolo "Linux". Fondamentalmente, Torvalds ha creato il “kernel” Linux, il componente vitale all'interno di qualsiasi sistema operativo che governa l'interfaccia tra l'hardware di un computer e i suoi processi digitali. All'epoca non era chiaro ma Linux sarebbe diventato il progetto open source più grande e popolare al mondo . Oggi esistono centinaia di distribuzioni Linux (o “distro”) che utilizzano il kernel creato da Torvalds.

Nel 1998, un piccolo ma influente gruppo all'interno della comunità del software libero decise di voler staccarsi dalle radici idealistiche del movimento e prendere il mainstream del software. Si è tenuto un summit a Mountain View, in California, dove i partecipanti hanno cercato di discutere come “rinominare” il software libero in qualcosa che “il mondo aziendale si affretterebbe ad acquistare”, scrive Eric Raymond, un noto programmatore e uno dei i partecipanti alla riunione. "Open source" è stato presentato come un "termine di marketing", inventato con lo scopo di catturare l'immaginazione dei titani tecnologici americani e allontanarli dalla terminologia più vaga e più adiacente al comunismo di "libero", spiega Raymond. La speranza era che gli uomini d'affari dimenticassero l'atteggiamento hippy-dippy di Stallman e accettassero il termine dal suono più pragmatico.

Si scopre che l'hanno comprato. Era la bolla delle Dot Com , la Silicon Valley era in piena espansione e le imprese private erano affamate di nuovi modi per liberare i profitti. A molte aziende, l’open source, che presentava un pool condiviso di manodopera gratuita e un modello industriale per l’innovazione, sembrava una buona idea . Il movimento “open source” si è quindi in gran parte separato dal movimento “libero”, diventando un organismo autonomo, promosso dalle multinazionali, che, col tempo, ha assunto uno spazio sempre maggiore all’interno dell’industria del software. Linux divenne onnipresente , Torvalds divenne famoso e Stallman continuò a fare quello che aveva sempre fatto: difendere le sue libertà digitali e denigrare i giganti del software aziendale. Oggi il mondo funziona “open source”, anche se è ancora un termine che Stallman rifiuta categoricamente . Preferisce ancora il termine software “libero”.

Codice per niente

Il software open source è diventato una risorsa onnipresente per le aziende, ma gli sviluppatori responsabili della creazione e del mantenimento di quel materiale vitale non hanno sempre visto il supporto, finanziario o di altro tipo, che meritano. In effetti, molte aziende si accontentano spesso di accaparrarsi il codice e scat, sfruttando essenzialmente il lavoro gratuito senza restituire nulla ai progetti o ai loro creatori.

Negli ultimi anni, la società Tidelift ha pubblicato un sondaggio basato su interviste a centinaia di manutentori open source. Ogni anno, il sondaggio mostra più o meno la stessa cosa: i manutentori sono oberati di lavoro, sottovalutati ed esauriti. I risultati del sondaggio hanno dimostrato che più della metà dei manutentori open source non vengono pagati affatto per il loro lavoro. Analogamente, un sondaggio condotto dalla Linux Foundation del 2020 tra i contributori ha rilevato che più della metà degli intervistati, ovvero circa il 51,65%, ha affermato di non essere retribuito.

Il burnout del manutentore è stato accusato dell'incidente di XZ . In effetti, il manutentore originale del progetto software ha riferito di sentirsi “indietro” e alla fine ha ceduto la responsabilità a un utente chiamato “Jia Tan”. Alla fine questo utente è stato la persona che ha introdotto la backdoor nel componente software.

Da tempo si chiede al settore privato di fare di più per sostenere l’ecosistema FOSS ma, nella maggior parte dei casi, tali appelli sono caduti nel vuoto. È vero che, negli ultimi anni, le grandi aziende tecnologiche hanno investito denaro in alcuni settori dell'ecosistema open source, ma spesso solo nei luoghi in cui è vantaggioso per loro farlo.

Per la stragrande maggioranza dei programmatori FOSS, il mantenimento dei progetti comporta ancora un compenso minimo o nullo, e spesso è meno un hobby divertente o un lavoro vero e proprio che un impegno ingrato: pensa all'economia dei creatori con il codice. Su Reddit puoi trovare thread dopo thread in cui gli sviluppatori discutono i modi per avviare il finanziamento FOSS. Alcuni suggeriscono di rivolgersi a Liberapay, una piattaforma di crowdfunding open source nota per distribuire denaro agli sviluppatori a corto di soldi. Altri pensano che Patreon sia una buona opzione . Almeno una persona incoraggia le persone a contattare Gitcoin, una startup Web3 che utilizza sovvenzioni in criptovaluta per sponsorizzare progetti FOSS. Molti sviluppatori incorporano semplicemente portali di donazione nelle pagine dei loro progetti Github, con collegamenti a cose come Stripe, PayPal o Comprami un caffè. Come per la maggior parte degli sforzi creativi, chiedere l’elemosina finisce per essere il modo più sicuro per guadagnare soldi.

Sangue

Probabilmente puoi immaginare i problemi di sicurezza che possono sorgere dall'avere un software immensamente popolare mantenuto tramite contributi di tipo OnlyFans. Gli studi hanno dimostrato che la stragrande maggioranza delle app commerciali contiene componenti open source che non vengono più aggiornati o sono stati abbandonati dai loro manutentori.

I pericoli inerenti alla costruzione di un’infrastruttura digitale aziendale sulle spalle di un pool di manodopera decentralizzato e talvolta volubile sono subito evidenti se si conosce la storia di Heartbleed.

Scoperto nel 2014, il bug Heartbleed era una vulnerabilità critica in OpenSSL , un protocollo di crittografia open source che, all'epoca, era responsabile di gran parte della programmazione delle comunicazioni sicure sul web. Grandi aziende come Google, Facebook, Netflix e Yahoo lo hanno utilizzato, così come un vasto assortimento di altre applicazioni e servizi, dalle VPN alle piattaforme di messaggistica istantanea e di posta elettronica. Naturalmente, la scoperta del bug, che ha consentito a un utente malintenzionato di ingannare i server vulnerabili inducendoli a consegnare dati sensibili come nomi utente e password, ha scatenato il panico in gran parte di Internet.

"Abbiamo scoperto che una cosa che tutti usavano era supportata solo da un paio di persone che non venivano pagate per niente", ha detto Jon Callas, esperto di crittografia e ingegnere del software, ricordando il caos scoppiato in quel momento . Callas non lavorava nel team OpenSSL, ma conosceva le persone che lo facevano e all'epoca lavorava su un progetto simile.

Come allude Callas, il problema con OpenSSL sembrava inevitabilmente ritornare ai manutentori. In effetti, verrebbe fuori che OpenSSL, responsabile della protezione della privacy e dei servizi di sicurezza per moltissime delle principali aziende blue chip, era in realtà gestito da un piccolo team di 11 persone, tra cui un team "principale" di quattro persone e un solo dipendente a tempo pieno.

"È un vero problema", ha detto Callas, a proposito dei problemi di manutenzione dell'open source. Callas ha una certa esperienza in merito, essendo stato uno degli architetti chiave dietro OpenPGP , uno standard aperto di crittografia PGP ampiamente utilizzato su Internet. "Capire come i pacchetti software, che sono fondamentalmente infrastrutture [digitali], vengano supportati e mantenuti è un grosso problema."

Heartbleed ha messo in luce un problema reale con quello che fino a quel momento era stato il paradigma operativo per la sicurezza open source. Per anni, il mondo FOSS è stato guidato da una dottrina secondo cui il software open source era più sicuro del software commerciale. Il ragionamento è che la trasparenza di FOSS, con il suo codice aperto all'intero web, ha consentito una maggiore visibilità dei suoi difetti e, quindi, maggiori opportunità di risolverli. Questo è ciò che è noto come l’ argomento “più occhi” . Quindi si pensava che il software commerciale avesse solo un team di sviluppo a cui prestare attenzione ai bug; l’open source aveva l’intera Internet.

C’è una logica elegante in questo argomento, ma presenta anche dei difetti. L’argomento “più occhi” funziona in un mondo ideale, in cui i progetti FOSS ottengono tutto ciò di cui hanno bisogno. Naturalmente, nel mondo reale, l’open source è sicuro quanto lo sono le risorse e le persone destinate alla sua manutenzione. Nella maggior parte dei casi, i progetti FOSS hanno meno occhi di quelli di cui hanno bisogno, non di più. Oppure potrebbero essere guardati con gli occhi sbagliati, come quelli di un criminale informatico.

È innegabile che un certo numero di progetti FOSS siano incredibilmente sicuri. Si dice che il kernel Linux sia stato studiato attentamente da circa 14.000 diversi contributori dal 2005. La Linux Foundation impiega circa 150 persone e lo scorso anno ha generato entrate stimate per 262,6 milioni di dollari, la maggior parte dei quali proveniva da contributi aziendali e privati. In molti modi, è grazie a questo supporto e trasparenza che gli spettatori sono riusciti a catturare Jia Tan, l'apparente progenitore della vulnerabilità XZ. Ma il problema con l’utilizzo di Linux come esempio di sicurezza open source è abbastanza ovvio: la maggior parte dei progetti open source non sono Linux e non ricevono supporto a livello di Linux.

La collezione di coltelli del pugnalatore alle spalle

Quando si verificò Heartbleed, fu considerato un “ campanello d’allarme ” per la comunità del software. L'incidente ha fondamentalmente focalizzato per la prima volta l'attenzione delle multinazionali americane sulle questioni di sicurezza che circondano l'open source. Ha inoltre costretto la Linux Foundation a creare la Core Infrastructure Initiative , che cercava di identificare progetti open source di vitale importanza che necessitavano di ulteriore supporto (è stata sostituita dall’OSSF nell’ottobre del 2021).

Tuttavia, se Heartbleed era un canarino nella miniera di carbone digitale, alla fine non era uno di quelli a cui tutti prestavano attenzione. In effetti, dal 2014 il panorama delle minacce è diventato solo più complesso, poiché FOSS è diventato una parte più ampia e integrante del web. Oggi i problemi non si limitano a qualche bug catastrofico occasionale. In effetti, sono molto più complicati di così.

Nel nostro mondo moderno, il software commerciale è ovunque. Le nostre vite sono più digitali e interconnesse che mai e praticamente tutto ciò che possiedi, dall'aspirapolvere alle attrezzature per esercizi allo spazzolino da denti, viene fornito con un'app. Di conseguenza, la possibilità che il software che esegue tutte queste app venga compromesso è aumentata notevolmente. Oggi, i cosiddetti “attacchi alla catena di fornitura” del software sono relativamente comuni . Tali attacchi prendono di mira componenti software particolarmente deboli, consentendo talvolta ai criminali informatici di sfruttare un pezzo debole per impossessarsi o corrompere un intero prodotto o sistema. Nella maggior parte dei casi, i componenti che consentono l'accesso iniziale alle catene di approvvigionamento sono FOSS . Esistono così tanti modi per hackerare componenti open source all'interno delle catene di approvvigionamento che il catalogo delle vulnerabilità è stato soprannominato la "collezione di coltelli delle pugnalate alle spalle" in un importante articolo del 2020.

Una persona che conosce bene questo complesso panorama delle minacce è Dan Lorenc. Professionista esperto della sicurezza con esperienza in FOSS, Lorenc ha trascorso quasi un decennio lavorando presso Google e almeno tre anni lavorando nei dettagli di sicurezza informatica per Google Cloud. Lorenc ora possiede l'azienda di sicurezza della catena di fornitura Chainguard, che gestisce molti degli stessi problemi emersi durante il suo periodo con Google.

“Penso che l’open source debba affrontare alcune sfide uniche, soprattutto proprio a causa della natura decentralizzata [del suo sviluppo]. Non puoi necessariamente fidarti di tutti coloro che scrivono il codice", ha detto Lorenc. "Chiunque su Internet può contribuire al codice open source, ma non tutti su Internet sono brave persone."

Sì, la triste verità è che l'episodio di XZ non è certo la prima volta in cui un manutentore o un collaboratore di FOSS ha introdotto software dannoso in un progetto. Un rapporto del 2020 ha rilevato che mentre la maggior parte dei bug nel FOSS sono semplicemente errori di codifica, circa il 17% (o circa un quinto) erano bug introdotti in modo dannoso, o ciò che i ricercatori chiamavano “bugdoor”. Un noto esempio di ciò si è verificato nel 2018, quando lo sviluppatore di un popolare programma open source chiamato event-stream era stanco di mantenere il progetto e ha deciso di cedere il controllo a un altro sviluppatore, un utente web pseudonimo chiamato “Right9ctrl”. L'unico problema è stato che "Right9ctrl" si è rivelato un criminale informatico che ha successivamente introdotto nel software un aggiornamento dannoso. L'aggiornamento ha consentito al criminale di hackerare una determinata marca di portafogli di criptovaluta e di rubarne i fondi. Il codice dannoso, scaricato circa 8 milioni di volte, è passato inosservato per circa due mesi.

Anche la tendenza degli sviluppatori FOSS a sabotare i propri progetti è in aumento. Nell'ottobre del 2021, il manutentore di un popolare set di librerie npm, un uomo di nome Marak Squires, le ha inspiegabilmente distrutte con una serie di bizzarri aggiornamenti. Gli aggiornamenti hanno fatto sì che il software rigurgitasse un flusso di parole incoerenti che di fatto hanno rovinato qualunque progetto stesse eseguendo il software. Si stima che questo atto di auto-immolazione digitale abbia portato alla distruzione di “migliaia” di progetti software che facevano affidamento sulle librerie di codifica per avere successo.

Lorenc dice anche che ci sono sicuramente più "log4j" là fuori: progetti critici che semplicemente non ricevono l'attenzione o la manutenzione che meritano. In realtà, questo tipo di situazione si presenta “di continuo”, ha detto.

Nei casi in cui tali progetti esplodono in faccia agli utenti aziendali, la colpa spesso viene attribuita ai manutentori. Le persone insinuano che "non svolgono il proprio lavoro in modo professionale, [o] non ci dedicano abbastanza tempo", ha detto Lorenc. “Ma, davvero, è un problema complicato. Loro [i manutentori] mettono qualcosa là fuori gratuitamente e poi la gente inizierà a costruire sopra un gigantesco pezzo di infrastruttura di produzione critica e si lamenterà in seguito quando verranno trovati dei bug.

Fare l'inventario

Quindi che si fa? Come si regola uno spazio tecnologico che è, per sua stessa natura, profondamente decentralizzato, afflitto dall’anonimato e strutturalmente resistente a qualsiasi ingerenza da parte di un’autorità sovrastante?

Questa domanda ha tenuto sveglie molte persone la notte. In diversi momenti dopo la debacle di log4j, ho contattato i dirigenti di OpenSSF, la filiale di sicurezza di Linux, per discutere i progressi del suo "piano di mobilitazione", che, se ricorderete, è stato messo insieme per creare nuove salvaguardie per l'ambiente FOSS dopo che è stato scoperto il bug log4shell. Quando inizialmente proposto, il piano conteneva molte parti in movimento e non era esattamente chiaro quali avrebbero avuto la priorità. Nel 2022, ho parlato con l'amministratore delegato di OpenSSF Brian Behlendorf, il quale mi ha detto che ci sono almeno un paio di proposte all'interno del piano di mobilitazione pronte per essere attuate, quelle che ha definito "pala pronta". Una delle soluzioni più promettenti è anche la più ovvia: costringere le aziende a inventariare il codice che utilizzano.

Per quanto strano possa sembrare, molte aziende non lo fanno. L’OSSF ha affermato che le aziende spesso “non hanno un inventario delle risorse software che distribuiscono e spesso non hanno dati sui componenti del software che hanno acquisito”. Non molto attraente, vero? È un po' come un'impresa edile che costruisce un grattacielo ma non ha idea di cosa siano fatte le fondamenta. Vorresti vivere o lavorare in un edificio del genere?

Il piano di mobilitazione prevedeva l'adozione diffusa di controlli di codice di terze parti, noti nel settore come "distinta base software" o SBOM. Tali strumenti forniscono un inventario di un particolare pezzo di software, raccolto tramite algoritmo. Comunicando all'utente cosa c'è all'interno del proprio programma, le SBOM consentono ai fornitori di software di verificare se quei singoli componenti sono interessati o meno da rischi per la sicurezza.

"Il modo migliore di pensarlo è come un elenco di ingredienti sul lato di una confezione di cibo", ha affermato Tim Mackey, che lavora con la società di sicurezza Synopsys, una delle numerose società che offrono servizi SBOM. "La distinta base del software consiste nel dirti cosa c'è dentro e da dove proviene."

Le SBOM esistono da anni, ma sono state utilizzate principalmente per eliminare i rischi legali . Poiché l'utilizzo di FOSS è legato a una serie contorta di accordi di licenza, le aziende hanno spesso utilizzato le SBOM per determinare i contenuti di una codebase e, quindi, quali accordi legali devono essere rispettati per evitare di essere citati in giudizio . Ora, tuttavia, vedono l’adozione per mitigare un tipo di rischio completamente diverso.

Nel maggio del 2021, l'amministrazione Biden ha emesso un ordine esecutivo che, tra le altre cose, imponeva che tutti gli appaltatori di software che collaborano con il governo federale utilizzino le SBOM. Mackey ha detto che, da quando l'ordine è stato approvato, il suo settore ha visto un'esplosione di interesse. "È stata una spinta incredibile per gli affari", ha detto. “Crescita fantastica”.

Ma anche se le SBOM rappresentano un passo nella giusta direzione, in definitiva non rappresentano una soluzione strutturale ai più ampi problemi di sicurezza posti dal FOSS. In realtà, non fanno nulla per mitigare i rischi presenti nel codice. "In realtà, sono solo una sorta di inventario accurato delle risorse", ha affermato l'ex sviluppatore di Google Dan Lorenc, sottolineando che è "folle" che la maggior parte delle aziende non lo disponga già. “Loro [SBOM] non risolvono i bug, non prevengono i bug, non impediscono agli aggressori di manomettere le cose. Ti danno semplicemente una buona base di partenza.

Cory Doctorow, membro di lunga data della comunità open source, afferma che attualmente non esistono incentivi per le aziende per creare software sicuro. Quando si verificano attacchi alla catena di fornitura, i manutentori dell’open source vengono incolpati, ma le aziende che utilizzano il codice sono in realtà quelle colpevoli. “Siamo in questa zona in cui, non solo le aziende non hanno alcun dovere affermativo di assicurarsi che il loro software sia buono e che i loro manutentori si sentano supportati, ma i volontari che si mettono in fila per avvisare” quelle aziende e i loro clienti “dei difetti” possono essere "messo a tacere da un'azienda se ritiene che stai danneggiando la loro immagine pubblica". Infatti, Doctorow afferma che non è raro che le aziende tecnologiche facciano causa ai ricercatori di sicurezza che cercano di rivelare bug nei loro prodotti.

La totale mancanza di azione da parte delle aziende lascia gran parte del duro lavoro della sicurezza del software ai singoli manutentori e alle organizzazioni open source come la Linux Foundation. A loro merito, queste organizzazioni hanno lavorato duramente per trovare nuove soluzioni ai problemi di sicurezza posti da FOSS. Oltre a incoraggiare l'adozione di SBOM, OpenSSF ha portato avanti una serie di altre iniziative di sicurezza negli ultimi anni. Questi programmi includono lo sviluppo di applicazioni di sicurezza gratuite, come GUAC , un meccanismo di tracciamento del software gratuito che consente ai programmatori di cercare componenti problematici nel loro codice, e Sigstore , una firma crittografica per verificare la validità del software di uno sviluppatore.

Se questi sforzi sembrano promettenti, è fondamentale notare che si stanno svolgendo in un contesto di crescenti attacchi alla catena di fornitura , di costante esaurimento da parte dei manutentori e di una sensazione generale che la posizione di sicurezza dell’ambiente open source non sia cambiata molto dai tempi di log4j. . Alcuni sostengono che solo una revisione a livello di sistema potrà proteggere Internet. Matthew Hodgson, il co-fondatore del protocollo crittografato Matrix, ha recentemente sostenuto che FOSS dovrebbe essere un servizio finanziato con fondi pubblici, un servizio che, proprio come l'infrastruttura fisica americana, riceve finanziamenti e sostegno federali continui.

Naturalmente, la probabilità che una trasformazione così drastica avvenga effettivamente sembra marginale, il che lascia coloro che mantengono l’ecosistema open source con un compito di Sisifo. Dalla scorsa estate, Brian Behlendorf è passato a un'altra posizione all'interno della Linux Foundation, passando il testimone della sicurezza all'ex ingegnere di Google Cloud Omkhar Arasaratnam, che ora ricopre il ruolo di direttore generale di OpenSSF. Arasaratnam descrive il suo lavoro come “proteggere Internet”, un compito che ammette essere “incredibilmente difficile”. Un descrittore migliore potrebbe essere “impossibile”. Tuttavia, ammette che, sebbene non ci siano soluzioni miracolose, non può fare a meno di essere fiducioso a causa della posta in gioco. “Se lo facciamo nel modo giusto, aiuteremo 8 miliardi di persone”, afferma.