Negli ultimi anni, i dipartimenti IT ricorrono sempre più frequentemente al software open-source di terze parti per accelerare lo sviluppo interno di codice proprietario e portare più velocemente al business le applicazioni richieste. Tuttavia, l’open-source impone di bilanciare correttamente rischi e opportunità, cercando un compromesso tra velocità di sviluppo, qualità del codice e soprattutto sicurezza del software.
Popolarità e sicurezza dell’open-source
Secondo l’ultimo report di Sonatype, nel 2021 gli sviluppatori hanno scaricato oltre 2,2 trilioni di pacchetti o componenti open-source di terze parti, considerando i quattro principali ecosistemi Java, Javascript, Python e .NET. Il numero di download effettuati ha registrato un aumento del 73% rispetto all’anno precedente. Le versioni dei componenti open-source sono in crescita esponenziale: le community ne condividono attualmente oltre 37 milioni, di cui 6 introdotte lo scorso anno.
Se l’open-source acquista popolarità perché semplifica il lavoro degli sviluppatori accelerando l’innovazione, bisogna però chiedersi quanto sia effettivamente sicuro. Nel quadro preoccupante della cybersecurity, gli ultimi eventi accendono il campanello d’allarme sull’affidabilità dell’open-source.
Nel dicembre 2021, è stata scoperta una vulnerabilità zero day nella libreria Java Apache log4j, che mette a repentaglio tantissime aziende a livello globale, minando servizi come Minecraft, iCloud, Twitter. Sempre nello scorso anno, è stata trovata una vulnerabilità di escalation dei privilegi di root, che sfrutta un bug del servizio polkit, installato di default su molte distribuzioni Linux.
Il software open source è davvero sicuro?
Più i componenti open-source si diffondono, più diventano un obiettivo appetibile per gli attaccanti. Il mito della sicurezza open-source, da sempre considerato più affidabile del codice proprietario, è destinato a cadere? Secondo Mark Driver, analista di Gartner, la questione va affrontata secondo una prospettiva più ampia.
Come sostengono in molti, l’open-source dovrebbe consentire un codice migliore in virtù del modello trasparente e collaborativo (ovvero, grazie alla base di co-developer e beta-tester più ampia e diversificata). Secondo Eric Steven Raymond, tra massimi esponenti del movimento open-source, il fattore differenziale consiste nel maggiore “numero di occhi” coinvolti nei progetti, che permette di rilevare e risolvere i problemi con maggiore efficacia e rapidità. Driver nota invece che la qualità e la sicurezza del software open-source derivano soprattutto dalla governance e dalle best practice di ogni singolo progetto.
Se la collaborazione può giocare un ruolo nella sicurezza, c’è tuttavia differenza tra iniziative open-source che attraggono pochi sviluppatori oppure decine o centinaia. Non tutti i progetti hanno la potenza di fuoco per implementare, monitorare e manutenere la qualità del software. Per integrare la sicurezza e identificare le vulnerabilità oggi servono competenze specializzate, non sempre disponibili nelle comunità.
Oltre alle osservazioni di Driver, ci sono altre perplessità circa la sicurezza del software open-source. La trasparenza del modello potrebbe essere un’arma a doppio taglio, sfruttata dagli attaccanti per individuare le vulnerabilità. Nella moderna supply-chain del software, sempre più complessa e automatizzata, un bug non identificato in una libreria può essere per esempio distribuito in migliaia di programmi, attraverso la pipeline CI/CD (continuous integration/continuous deployment).
La sicurezza dipende anche dal recepimento degli aggiornamenti: secondo un’indagine di Veracode, in quasi l’80% dei casi, le librerie open-source di terze parti non vengono mai aggiornate dagli sviluppatori, una volta incluse in una base di codice.
Come evolve la sicurezza open-source
L’attuale contesto della cybersecurity obbliga al ripensamento della supply-chain applicativa. Serve un approccio sistemico alla sicurezza open-source, che non può essere semplicemente demandata allo zelo degli sviluppatori o all’interesse delle aziende utenti.
Gli Sbom per la visibilità sulle componenti
Oggi la maggioranza dei programmi software include componenti di terze parti, open- e closed- source, che devono essere tracciate e manutenute per evitare l’obsolescenza e gli errori del codice. Molte delle vulnerabilità open-source infatti derivano proprio da dipendenze indirette.
Gli Sbom (Software Bills of Materials) rappresentano un passo in avanti, fornendo agli sviluppatori l’elenco delle componenti e delle dipendenze contenute in un pezzo di software, con una serie di informazioni base (per esempio, la versione e il numero di licenza).
Aumentando la visibilità sul software, gli Sbom accelerano la scoperta e la risoluzione delle vulnerabilità, prima che possano entrare in produzione. Inoltre, permettono di identificare facilmente le parti di codice che hanno raggiunto il fine vita (quindi potenzialmente rischiose perché rimaste prive di aggiornamenti) oppure che duplicano la stessa funzione (aumentando inutilmente il numero dei componenti da manutenere e quindi la superficie di attacco).
L’approccio sistemico dell’Alpha-Omega Project
Tra le maggiori iniziative per la sicurezza del codice sorgente aperto, la Open Source Security Foundation (OpenSSF) ha avviato l’Alpha-Omega Project che agisce su due direttrici.
Il primo obiettivo è intervenire sui progetti (o sugli ecosistemi) open-source più importanti, con team di sicurezza dedicati che prestano supporto diretto agli sviluppatori della singola iniziativa. Il secondo è offrire assistenza sui progetti meno critici, ma ampiamente diffusi attraverso strumenti automatizzati per l’analisi del codice, gruppi condivisi di security analyst, procedure standard per il reporting delle vulnerabilità rilevate.
L’Alpha-Omega Project ha raccolto il favore di Big Player come Microsoft e Google, che hanno contribuito all’iniziativa con un investimento di cinque milioni di dollari. Tuttavia, il successo è legato al raggiungimento di una massa critica di progetti certificati.
Gli investimenti in bug bounty
Il tentativo di mettere in sicurezza servizi e applicazioni conduce anche a strategie meno convenzionali, che nel mondo della cyber security sono ormai estremamente diffuse. Tra queste, il bug bounty.
Con i programmi di bug bounty, le aziende offrono agli sviluppatori un compenso in denaro per la segnalazione di vulnerabilità e altre anomalie del codice sorgente. Così i bachi possono essere isolati e risolti prima che diventino di dominio pubblico, causando danni all’immagine e perdite economiche.
Diversi colossi di Internet, tra cui Facebook, Yahoo e Google, hanno sottoscritto accordi bug bounty, con un’attenzione particolare verso componenti open-source come, per esempio, il web server Apache oppure il linguaggio di programmazione Ruby.
Uno sforzo collettivo per la sicurezza
La sicurezza open-source insomma costa cara (e la spesa è destinata al rialzo) ma deve diventare una priorità effettiva in qualsiasi iniziativa di sviluppo applicativo. Il mercato del software dovrebbe elaborare un piano condiviso e supportare sistematicamente i developers, perché progettino, realizzino e soprattutto manutengano i progetti open-source su cui costruire nuove applicazioni e l’innovazione del business.
In realtà, le stesse organizzazioni open-source pagano profumatamente i professionisti della cybersecurity (per esempio, di recente, Linux Foundation ha dichiarato di finanziare direttamente gli esperti e le attività di sicurezza, raggiungendo cifre mai spese prima).
Tuttavia, serve un approccio coordinato, che metta a fattore comune strumenti software basati su intelligenza artificiale per automatizzare la ricerca e la risoluzione delle vulnerabilità, effettuare programmi di formazione (uno sviluppatore non è necessariamente un esperto di sicurezza), pagare adeguatamente gli sviluppatori e i manutentori.
FONTI
- Securing open-source code isn’t going to be cheap
- Sonatype, 2021 STATE OF THE SOFTWARE SUPPLY CHAIN REPORT
- Quick Answer: Is Open Source Software More or Less Secure Than Proprietary Software?
- Glaring Gap In Open Source Security, 80 Percent Of Libraries Used In Software Are Never Updated: Veracode Report
