Problemi di dipendenza: risolvere il problema di sicurezza del software open source mondiale

image_pdfimage_print

di John Speed Meyers, Zack Newman, Tom Pike e Jacqueline Kazil

L’idea di un programmatore solitario che si affidasse al proprio genio e acume tecnico per creare il prossimo grande software era sempre una forzatura. Oggi è un mito più che mai. Le forze di mercato competitive significano che gli sviluppatori di software devono fare affidamento sul codice creato da un numero imprecisato di altri programmatori. Di conseguenza, la maggior parte del software è meglio concepita come bricolage: componenti diversi, solitamente open source, spesso chiamati dipendenze, uniti a bit di codice personalizzato in una nuova applicazione.

Questo paradigma dell’ingegneria del software – i programmatori riutilizzano componenti software open source anziché duplicare ripetutamente gli sforzi degli altri – ha portato a enormi guadagni economici. Secondo la migliore analisi disponibile, i componenti open source ora costituiscono il 90% della maggior parte delle applicazioni software. E l’elenco dei componenti open source economicamente importanti e ampiamente utilizzati – il framework di deep learning di Google TensorFlow o il suo concorrente sponsorizzato da Facebook PyTorch, l’onnipresente libreria di crittografia OpenSSL o il software di gestione dei container Kubernetes – è lungo e si allunga. Anche la comunità militare e dell’intelligence dipendono da software open source: programmi come Palantir sono diventati cruciali per le operazioni di antiterrorismo, mentre l’F-35 contiene milioni di righe di codice.

Il problema è che la catena di fornitura del software open source può introdurre punti deboli della sicurezza sconosciuti, possibilmente intenzionali. Un’analisi precedente di tutte le compromissioni della catena di fornitura del software segnalate pubblicamente ha rivelato che la maggior parte degli attacchi dannosi prendeva di mira il software open source. In altre parole, gli attacchi alla catena di fornitura di software che includono i titoli dei software proprietari, come SolarWinds, costituiscono in realtà la minoranza dei casi. Di conseguenza, fermare gli attacchi è ora difficile a causa dell’immensa complessità del moderno albero delle dipendenze del software: componenti che dipendono da altri componenti che dipendono da altri componenti all’infinito. Sapere quali sono le vulnerabilità nel tuo software è un lavoro a tempo pieno e quasi impossibile per gli sviluppatori.

Per fortuna c’è speranza. Raccomandiamo tre passaggi che i produttori di software e le autorità di regolamentazione del governo possono intraprendere per rendere più sicuro il software open source. In primo luogo, produttori e consumatori dovrebbero abbracciare la trasparenza del software, creando un ecosistema verificabile in cui il software non è semplicemente costituito da blob misteriosi passati su una connessione di rete. In secondo luogo, i produttori di software e i consumatori dovrebbero adottare strumenti di analisi e integrità del software per consentire una gestione informata del rischio della catena di approvvigionamento. In terzo luogo, le riforme del governo possono aiutare a ridurre il numero e l’impatto dei compromessi del software open source.

La strada per la dipendenza

I resoconti convenzionali dell’ascesa dei componenti software riutilizzabili spesso lo fanno risalire agli anni ’60. Esperti di software come Douglas McIlroy dei Bell Laboratories avevano notato l’enorme spesa per la creazione di nuovo software. Per semplificare il compito, McIlroy ha chiesto la creazione di una sottoindustria di “componenti software” per la produzione di massa di componenti che sarebbero ampiamente applicabili su macchine, utenti e applicazioni – o in altre parole, esattamente ciò che il moderno open source offre.

Quando l’open source è iniziato, inizialmente si è fuso attorno a comunità tecniche che fornivano supervisione, gestione e controllo di qualità. Ad esempio, Debian, il sistema operativo basato su Linux, è supportato da una rete globale di sviluppatori di software open source che mantengono e implementano standard su quali pacchetti diventeranno e non diventeranno parte della distribuzione Debian. Ma questa supervisione relativamente stretta ha lasciato il posto a un sistema di registri dei pacchetti più a ruota libera, probabilmente più innovativo, organizzato in gran parte dal linguaggio di programmazione. Pensate a questi registri come app-store per sviluppatori di software, che consentono allo sviluppatore di scaricare componenti open source gratuiti da cui creare nuove applicazioni. Un esempio è il Python Package Index, un registro di pacchetti per il linguaggio di programmazione Python che consente a chiunque, da un volontario idealista a un dipendente aziendale a un programmatore malintenzionato, di pubblicare codice su di esso. Il numero di questi registri è sbalorditivo, e ora ogni programmatore è virtualmente obbligato a usarli.

L’efficacia di questo modello software rende gran parte della società dipendente dal software open source. I sostenitori dell’open source si affrettano a difendere il sistema attuale invocando la legge di Linus: “Dato un numero sufficiente di occhi, tutti i bug sono superficiali”. Cioè, poiché il codice sorgente del software è libero di ispezionare, gli sviluppatori di software che lavorano e condividono il codice online troveranno problemi prima che influiscano sulla società e, di conseguenza, la società non dovrebbe preoccuparsi troppo della sua dipendenza dal software open source perché questo esercito invisibile lo proteggerà. Questo potrebbe essere stato vero, se strizziamo gli occhi, nel 1993. Ma molto è cambiato da allora. Nel 2022, quando saranno centinaia di milioni di nuove righe di codice open source scritte, ci sono troppo pochi occhi e i bug saranno profondi. Ecco perché nell’agosto 2018 ci sono voluti due mesi interi per scoprire che un codice per il furto di criptovalute era stato inserito in un software scaricato oltre 7 milioni di volte.

Flusso di eventi

La storia è iniziata quando lo sviluppatore Dominic Tarr ha trasferito i diritti di pubblicazione di un pacchetto JavaScript open source chiamato “event-stream” a un’altra parte conosciuta solo dall’handle “right9ctrl”. Il trasferimento è avvenuto su GitHub, una popolare piattaforma di code hosting frequentata da decine di milioni di sviluppatori di software. L’utente right9ctrl si era offerto di mantenere il flusso degli eventi, che a quel punto veniva scaricato quasi due milioni di volte a settimana. La decisione di Tarr è stata sensata e insignificante. Aveva creato questo software open source gratuitamente con una licenza permissiva – il software era fornito così com’è – ma non lo usava più lui stesso. Ha anche già mantenuto diverse centinaia di pezzi di altri software open source senza compenso. Quindi, quando right9ctrl, chiunque fosse, ha richiesto il controllo, Tarr ha accolto la richiesta.

Il trasferimento del controllo di un pezzo di software open source a un’altra parte avviene sempre senza conseguenze. Ma questa volta c’è stata una svolta maligna. Dopo che Tarr ha trasferito il controllo, right9ctrl ha aggiunto un nuovo componente che ha cercato di rubare bitcoin dal computer della vittima. Milioni e milioni di computer hanno scaricato questo pacchetto software dannoso fino a quando lo sviluppatore Jayden Seric ha notato un’anomalia nell’ottobre 2018.

Event-stream era semplicemente il canarino nella miniera di codice. Negli ultimi anni, i ricercatori di sicurezza informatica hanno trovato aggressori che utilizzano una serie di nuove tecniche. Alcuni stanno imitando lo squatting del nome di dominio: ingannando gli sviluppatori di software che scrivono erroneamente il nome di un pacchetto per scaricare software dannoso (dajngo vs. Django). Altri attacchi sfruttano le configurazioni errate degli strumenti software che inducono gli sviluppatori a scaricare i pacchetti software dal registro dei pacchetti sbagliato. La frequenza e la gravità di questi attacchi sono in aumento nell’ultimo decennio. E questi conteggi non includono nemmeno i casi probabilmente più numerosi di vulnerabilità di sicurezza non intenzionali nel software open source. Più di recente, la vulnerabilità involontaria del pacchetto software log4j ampiamente utilizzato ha portato a un vertice della Casa Bianca sulla sicurezza del software open source. Dopo che questa vulnerabilità è stata scoperta, un giornalista ha intitolato un articolo, con solo una leggera esagerazione, “Internet è in fiamme”.

Il piano in tre fasi

Per fortuna, ci sono diversi passaggi che i produttori di software e i consumatori, incluso il governo degli Stati Uniti, possono intraprendere per consentire alla società di ottenere i vantaggi del software open source riducendo al minimo questi rischi. Il primo passo, che ha già ricevuto il sostegno del Dipartimento del Commercio degli Stati Uniti e anche dell’industria, consiste nel rendere il software trasparente in modo che possa essere valutato e compreso. Questo è iniziato con gli sforzi per incoraggiare l’uso di una distinta base del software. Questa fattura è un elenco completo o un inventario dei componenti di un software. Con questo elenco, il software diventa più facile cercare i componenti che potrebbero essere compromessi.

A lungo termine, questo disegno di legge dovrebbe andare oltre il semplice elenco di componenti per includere informazioni su chi ha scritto il software e come è stato creato. Per prendere in prestito la logica dalla vita di tutti i giorni, immagina un prodotto alimentare con ingredienti chiaramente specificati ma sconosciuti e non analizzati. Quell’elenco è un buon inizio, ma senza un’ulteriore analisi di questi ingredienti, la maggior parte delle persone ci passerà sopra. I singoli programmatori, i giganti della tecnologia e le organizzazioni federali dovrebbero adottare un approccio simile ai componenti software. Un modo per farlo sarebbe abbracciare i livelli della catena di approvvigionamento per gli artefatti del software, una serie di linee guida per le catene di approvvigionamento del software delle organizzazioni a prova di manomissione.

Il passaggio successivo coinvolge le società di sicurezza del software e i ricercatori che creano strumenti che, in primo luogo, firmano e verificano il software e, in secondo luogo, analizzano la catena di fornitura del software e consentono ai team di software di effettuare scelte informate sui componenti. Il progetto Sigstore, una collaborazione tra la Linux Foundation, Google e una serie di altre organizzazioni, è uno di questi sforzi incentrati sull’utilizzo delle firme digitali per rendere trasparente e verificabile la catena di custodia del software open source. Questi approcci tecnici sono l’equivalente digitale di un sigillo a prova di manomissione. Il team software Platform One del Dipartimento della Difesa ha già adottato elementi di Sigstore. Inoltre, potrebbe essere utile anche un “osservatorio” della filiera del software che raccoglie, cura e analizza la filiera mondiale del software con l’obiettivo di contrastare gli attacchi. Un osservatorio, potenzialmente gestito da un consorzio universitario, potrebbe contemporaneamente aiutare a misurare la prevalenza e la gravità delle compromissioni del software open source, fornire i dati sottostanti che consentono il rilevamento, e confrontare quantitativamente l’efficacia di diverse soluzioni. Il Software Heritage Dataset fornisce i semi di un tale osservatorio. I governi dovrebbero aiutare a sostenere questa e altre iniziative simili incentrate sulla sicurezza. Le aziende tecnologiche possono anche abbracciare vari progetti di “etichetta nutrizionale”, che forniscono una panoramica a colpo d’occhio della “salute” della catena di approvvigionamento di un progetto software.

Questi sforzi relativamente tecnici trarrebbero vantaggio, tuttavia, da più ampie riforme del governo. Ciò dovrebbe iniziare con la correzione della struttura degli incentivi per l’identificazione e la divulgazione delle vulnerabilità open source. Ad esempio, le “clausole DeWitt” comunemente incluse nelle licenze software richiedono l’approvazione del fornitore prima di pubblicare determinate valutazioni della sicurezza del software. Ciò riduce la conoscenza della società su quali pratiche di sicurezza funzionano e quali no. I legislatori dovrebbero trovare un modo per vietare questa pratica anticoncorrenziale. Il Dipartimento per la sicurezza interna dovrebbe anche prendere in considerazione il lancio di un fondo senza scopo di lucro per le ricompense dei bug del software open source, che premia i ricercatori per aver trovato e corretto tali bug. Infine, come proposto dalla recente Cyberspace Solarium Commission, un ufficio di statistiche informatiche potrebbe tracciare e valutare i dati di compromissione della catena di approvvigionamento del software. Ciò garantirebbe che le parti interessate non siano bloccate nella creazione di set di dati duplicati e idiosincratici.

Senza queste riforme, il software moderno assomiglierà al mostro di Frankenstein, una sgraziata raccolta di parti sospette che alla fine si rivolge al suo creatore. Con la riforma, tuttavia, l’economia statunitense e le infrastrutture di sicurezza nazionale possono continuare a beneficiare del dinamismo e dell’efficienza creati dalla collaborazione open source.

Traduzione a cura di Alessandro Napoli

Foto: Idee&Azione

21 maggio 2022