Al giorno d'oggi i software liberi sono essenziali non solo nel settore delle tecnologie informatiche, ma la loro importanza si estende a tutte le aree in cui l'uso del software svolge un ruolo cruciale. La questione legata alla loro manutenzione è diventata gradualmente un argomento critico, al punto che il Congresso degli Stati Uniti ha introdotto un disegno di legge nel 2023: il "Securing Open Source Software Act". Ripercorriamo insieme le tappe evolutive dell'Open Source – da una trascrizione al Congresso degli Stati Uniti.
Il "Securing Open Source Software Act" mette l’argomento bene in chiaro fin dai primi paragrafi: "I software open source favoriscono lo sviluppo tecnologico e sono parte integrante della sicurezza informatica globale"; "Un ecosistema open source sicuro, sano, dinamico e resiliente è essenziale per garantire la sicurezza nazionale e la competitività economica degli Stati Uniti"; "I software open source costituiscono le fondamenta dell'infrastruttura digitale che sostiene un'Internet libera e aperta". "Senza i software open source, Internet come la conosciamo oggi non esisterebbe, anzi non sarebbe mai esistita…", riassume Yvan Vanhullebus, Technical Leader di Stormshield. Ma confondere i termini Software Libero e Open Source può risultare fastidioso per molti...
Senza i software open source, Internet come la conosciamo oggi non esisterebbe, anzi non sarebbe mai esistita…
Yvan Vanhullebus, Technical Leader di Stormshield
Le origini dell'Open Source
Inizialmente veniva utilizzato il termine free software e designava un concetto nato negli Stati Uniti negli anni '80 sotto la spinta di Richard Stallman. Sebbene volesse semplicemente stampare un documento, questo fervente difensore della cultura hacker passerà alla storia come l'uomo che si è opposto alla privatizzazione dei software e alla nascita di una legislazione sempre più restrittiva per gli utenti. Il Computer Software Copyright Act, ad esempio, è stato emanato nel 1980.
È in questo scenario che Richard Stallman diede vita nel 1985 alla Free Software Foundation, un'organizzazione senza scopo di lucro che stabilì i quattro fondamenti del software libero: il diritto di eseguire un programma per qualsiasi scopo; la libertà di studiarne il funzionamento e di adattarlo alle proprie esigenze; la libertà di ridistribuirne le copie; la libertà di migliorarlo e di pubblicarlo a beneficio dell'intera comunità. Di fronte alle possibili interpretazioni del termine "free", lo stesso Richard Stallman risponde nella sua biografia autorizzata: "Don’t think free as in free beer; think free as in free speech". È una questione di libertà, non di gratuità. Tuttavia, questo approccio etico al concetto era tutt'altro che unanime all'interno della comunità: per porre fine all'ambiguità linguistica, nel 1998 la scienziata americana Christine Peterson, allora direttore esecutivo del Foresight Institute, coniò il termine Open Source. Un'evoluzione lessicale necessaria, che l'autrice descrive in dettaglio in una lunga e appassionante relazione. Insieme a personalità del calibro di Eric Raymond e Bruce Perens, nello stesso anno ha partecipato alla creazione dell'Open Source Initiative (OSI). La terminologia originale di software libero venne dunque abbandonata a favore di software Open Source.
Don’t think free as in free beer; think free as in free speech.
Richard Stallman, programmatore e attivista del software libero
Quali sono le differenze tra "software libero" e "software open source"? Per quanto riguarda la definizione, software libero si riferisce alla possibilità di utilizzarlo, studiarlo, modificarlo o duplicarlo, mentre il termine software Open Source si riferisce a una strategia di sviluppo basata sul riutilizzo di tutto o parte del codice sorgente. I progetti Open Source sono generalmente supervisionati da uno o più gestori, ma si avvalgono di contributi esterni come l'aggiunta di nuove funzionalità, la segnalazione di bug (e la loro correzione) o il miglioramento della sicurezza. In altre parole, l'Open Source è un movimento di sviluppo collaborativo del software.
Open Source: un passo verso la collaborazione comunitaria
Per garantire che il software rimanesse aperto e libero, era importante definire un quadro giuridico. A tal fine, sono state introdotte diverse licenze d'uso. La più nota è la GNU GPL (General Public License), la cui prima versione è stata creata nel 1989 sulla base dei quattro principi ideati da Richard Stallman allo scopo di stabilire le giuste condizioni legali per la distribuzione di software liberi nell'ambito del progetto GNU. Seguiranno altre licenze, come Apache 2.0, MIT, BSD e Creative Common, con i propri livelli di autorizzazione e riutilizzo del codice.
Lo sviluppo di queste licenze ha portato alla nascita di numerosi progetti, come il lancio del kernel Linux nel 1991 e la licenza Open Source di Netscape Navigator nel 1998 (che è servita come base per la creazione della suite Mozilla). Nel 2001, Wikipedia diventerà uno dei progetti emblematici del movimento Open Source, con l'obiettivo di sfruttare l'intelligenza collettiva per creare la più grande raccolta di conoscenze su Internet. Successivamente, il lancio di Android da parte di Google nel 2008 e la creazione di GitHub nello stesso anno testimoniano la crescente integrazione dell'Open Source nelle tecnologie di consumo e nelle infrastrutture di sviluppo software. L'apice di questo processo di adozione, almeno in apparenza, arriverà nel 2014 con un discorso di Satya Nadella, CEO di Microsoft, in cui dichiarerà che "Microsoft ama Linux". Nella comunità Open Source, tuttavia, molti ricordano le parole del suo predecessore Steve Ballmer quando lo definì un "cancro che investe, in termini di proprietà intellettuale, tutto ciò che tocca".
Da un punto di vista commerciale, l'Open Source è un modello di business particolare. Infatti, se un progetto è Open Source, possono sorgere varianti che sfuggono al controllo aziendale; il modello di business ruota essenzialmente intorno ai servizi o alla manutenzione (tutto fuorché le licenze). È quindi nell'interesse finanziario di ogni azienda adottare sistemi o applicazioni Open Source, a patto di essere pienamente consapevoli dei vincoli imposti dalle singole licenze, come sottolinea David Gueluy, Responsabile R&S e Technical Advisor di Stormshield: "La licenza GPL è nota per esigere la ridistribuzione delle modifiche apportate al codice sorgente. Quest'obbligo ha determinato situazioni legali complesse per alcuni produttori, che si sono trovati a dover pubblicare l'intero codice sorgente, persino quando si trattava dell’integrazione di una minuscola porzione di codice GPL in un programma di più ampia portata...". Per contro, licenze come BSD, MIT o Apache offrono una maggiore flessibilità, consentendo alle aziende di modificare e utilizzare il codice senza dover condividere le modifiche. L'interesse delle aziende per l'utilizzo e lo sviluppo di progetti Open Source è confermato dalle statistiche di Microsoft, che mostrano come il 60% delle immagini ospitate sul cloud Azure sia basato sul kernel Linux o su software liberi. "Mi fa sorridere osservare come l'Open Source stia guadagnando sempre più importanza e sia sempre più diffuso in diversi ambiti - afferma divertito Yvan Vanhullebus - Si tratta davvero di una tendenza del momento o è piuttosto un fenomeno che abbiamo notato solo ora?" Il punto è che l'adozione dell'Open Source è una realtà sempre più diffusa in tutti i settori, compreso quello della progettazione e dello sviluppo di prodotti per la sicurezza informatica.
Mi fa sorridere osservare come l'Open Source stia guadagnando sempre più importanza e sia sempre più diffuso in diversi ambiti. Si tratta davvero di una tendenza del momento o è piuttosto un fenomeno che abbiamo notato solo ora?
Yvan Vanhullebus, Technical Leader di Stormshield
L'importanza di un'apertura protetta degli ecosistemi
Come per qualsiasi fenomeno, anche l'Open Source attrae estimatori e detrattori. Tra questi ultimi, numerosi sono gli aspetti che generano lunghi e accesi dibattiti. Il primo, che risale ormai a circa trent'anni fa, riguardava la reale possibilità che l'approccio Open Source potesse funzionare. "Fin dai primi progetti siamo stati in grado di rispondere in maniera affermativa e di risolvere il dibattito in tempi piuttosto brevi", afferma Yvan Vanhullebus. “Poco dopo ne è sorto un secondo, che vedeva gli strumenti Open Source utilizzati solo da nerd occhialuti..." Tale credenza persiste ancora, a seconda dell'ambiente e del settore, ma si è notevolmente attenuata con il riavvicinamento tra Open Source e UX. Infine, il terzo dibattito riguarda più specificamente il mondo della cybersecurity: un prodotto di sicurezza informatica basato su sistemi Open Source può essere ritenuto affidabile? Il timore è che un criminale informatico scopra una vulnerabilità e la mantenga celata con l'intenzione di sfruttarla come vulnerabilità come Heartbleed nel progetto OpenSSL scoperta nel 2012, o Log4J scoperta nel 2021. Un argomento sollevato dai detrattori riguarda la possibilità che i malintenzionati possano contribuire a progetti Open Source, introducendo vulnerabilità che possono essere erroneamente assimilate a semplici bug. In un rapporto del 2020, GitHub ha affermato che il 17% dei bug software presenti sulla piattaforma sono stati inseriti intenzionalmente nel codice da soggetti malevoli. La recente scoperta della compromissione della libreria XZ, elemento base utilizzato in ambiente Linux, ne è un esempio significativo. Alla fine di marzo 2024, un dipendente Microsoft ha lanciato un security allert alla comunità Open Source dopo aver riscontrato un'anomalia del codice all’interno dei pacchetti XZ. Indicato nella CVE-2024-3094, i cyber criminali attraverso combinate tecniche di ingegneria sociale e preparazione a lungo termine (da diversi mesi a diversi anni), erano riusciti ad inserire gradualmente e discretamente del codice malevolo “offuscato”, in grado di eludere il rilevamento da parte delle attività di revisioni del codice, e che permetteva di sfruttare una backdoor per eseguire comandi arbitrari che di fatto, permettevano di assumere il controllo dell’intero sistema bersaglio. Un potenziale attacco su larga scala alla “supply chain”, sventato appena in tempo...
Ma l'Open Source gode anche (e soprattutto) di estimatori, convinti che questo modello migliori la sicurezza informatica grazie alla trasparenza e alla collaborazione della comunità. Il motivo è che l'accesso al codice sorgente rende più facile individuare le vulnerabilità e correggerle il più rapidamente possibile, rispetto a un approccio "a scatola nera" in cui la visibilità è limitata. David Gueluy concorda: "Uno degli aspetti più significativi legati alla sicurezza dei progetti Open Source è la possibilità di verificare da soli eventuali errori nel codice, l'assenza di backdoor o, per lo meno, la possibilità di correggere da soli eventuali anomalie".
Uno degli aspetti più significativi legati alla sicurezza dei progetti Open Source è la possibilità di verificare da soli eventuali errori nel codice, l'assenza di backdoor o, per lo meno, la possibilità di correggere da soli eventuali anomalie.
David Gueluy, Responsabile R&S e Technical Advisor di Stormshield
E questo è proprio il caso di Heartbleed, Log4J e della compromissione della libreria XZ: la reattività e la collaborazione della comunità Open Source sono state determinanti per risolverli. E’ importante notare che nonostante il rumore fatto intorno alla compromissione della libreria XZ, è fondamentale specificare che non si tratta di un fenomeno nuovo né specifico del mondo dell'Open Source. Alla fine del 2020 il malware Sunburst è stato introdotto nella catena di sviluppo del software Orion dell’azienda SolarWinds. In totale, più di 18.000 aziende e istituzioni in tutto il mondo sono state colpite da questo attacco. Un episodio che dimostra chiaramente come anche le soluzioni non Open Source rimangano sensibili alle vulnerabilità.
Questo approccio all’Open Source è sostenuto anche da enti pubblici come l'ANSSI in Francia. L'agenzia francese è coinvolta in numerosi progetti Open Source, sia attraverso i contributi dei suoi agenti che con la pubblicazione di diversi strumenti. Questo investimento "risponde a una vera sfida di sicurezza e sovranità, per proteggere i beni comuni e investire in tecnologie e soluzioni per il futuro". Inoltre, svolge un ruolo attivo nello sviluppo di software liberi, collaborando a progetti come Linux, Debian e Suricata, data l'ampia presenza e il sostegno a progetti Open Source in questo settore. David Gueluy cita ad esempio Vault, "una delle soluzioni offerte da HashiCorp, un'azienda fondata proprio sui principi dell'Open Source, che consente di archiviare segreti in modo sicuro", KeePass (gestore di password), TheHive (piattaforma di risposta agli incidenti), Metasploit Framework (strumento di test delle intrusioni) e MISP (piattaforma di condivisione delle informazioni sulle minacce informatiche); tutti strumenti che dimostrano come l'Open Source abbia un impatto significativo sullo sviluppo di solide soluzioni di sicurezza informatica. OpenSSL, ad esempio, classificato tra i primi 10 dall'Open Source Security Index, è uno dei principali progetti dedicati alla sicurezza delle comunicazioni, impiegato sia in prodotti commerciali che in soluzioni Open Source. "Il vantaggio di OpenSSL per le aziende consiste nell'avere accesso a una libreria crittografica già collaudata e ampiamente validata dalla comunità, senza dover partire da zero", spiega David Gueluy. È proprio questo il nocciolo della questione: la creazione di un nuovo prodotto non basato su alcuna tecnologia Open Source sarebbe illusoria, se non come prodotto di nicchia, in quanto richiederebbe ingenti investimenti per (ri)sviluppare soluzioni già disponibili e che hanno richiesto anni per essere implementate. Solo dopo aver preso atto di questo stato di cose sarà possibile instaurare un circolo virtuoso, verificando le versioni dei componenti Open Source alla ricerca di potenziali vulnerabilità, pubblicando rapidamente le patch una volta scoperte e contribuendo ai vari progetti (patch, funzionalità, finanziamenti...).
In conclusione, l'Open Source, con il suo approccio di trasparenza e collaborazione, si sta dimostrando una forza trainante per l'innovazione nella sicurezza informatica. Occorre tuttavia prestare attenzione alla nuova sfida normativa europea sulla resilienza informatica, posta dal Cyber Resilience Act (CRA), che entrerà in vigore nel 2024. L'obiettivo è vincolare gli sviluppatori ad assumersi la responsabilità in caso di falle di sicurezza nel proprio codice: un passo necessario nella lotta contro l'approccio "a scatola nera", ma che non soddisfa ancora del tutto la comunità… to be continued.
