Security dell’open-source: cosa c’è da sapere

pittogramma Zerouno

Prospettive

Security dell’open-source: cosa c’è da sapere

Con le componenti open-source sempre più diffuse in qualsiasi software, è indispensabile investire sistematicamente per mettere in sicurezza la supply chain

30 Mag 2022

di Arianna Leonardi

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.

WEBINAR
WEBINAR con il Prof. Mariano Corso: le opportunità del digitale per il Made in Italy di eccellenza
Blockchain
CIO

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

WHITEPAPER
Cosa serve per risparmiare davvero sull’energia? L’IoT da solo non basta!

Arianna Leonardi

Giornalista

Collaboratrice e redattrice per numerose pubblicazioni tecniche, specializzate in Informatica, Automazione ed Elettronica, Arianna Leonardi ha maturato una significativa esperienza anche nel campo della fotografia, dell’industria video e dei media online. In ambito giornalistico, segue principalmente le tematiche legate alla digitalizzazione delle imprese, con un focus su cloud transformation, big data analytics e intelligenza artificiale. Iscritta all’Ordine dei Giornalisti dal 2008 e all’Associazione Nazionale dei Fotografi Professionisti, lavora con ZeroUno dal 2013.

Articolo 1 di 4