OpenSSF lancia l'iniziativa Alpha-Omega Project: garantire la solidità del codice open source con attività di test e certificazione indipendenti. Perché tutelare il codice è interesse di tutti.
Autore: f.p.
Il software open source oggi è, di fatto, la base tecnologica fondante dell'IT di qualsiasi azienda. Una evoluzione che mette in primissimo piano la questione sicurezza dei progetti open source. La promessa di una sicurezza "intrinseca" del codice aperto e verificabile non si è completamente mantenuta. O perlomeno non regge in uno scenario in cui la criminalità informatica è organizzata e pronta a identificare e sfruttare rapidamente qualsiasi vulnerabilità del software. L'approccio comunitario è la forza dell'open source ma può diventare anche una sua debolezza, in quanto a sicurezza. A chi delegare la solidità del codice? Chi la garantisce?
Di un approccio sistemico alla sicurezza dell'open source si parla già da qualche tempo. Di solito però in maniera un po' vaga e, viene da dire, anche astratta. I grandi repository raccolgono decine e decine di migliaia di progetti popolari ma curati da sviluppatori con poche risorse e che per la sicurezza fanno quello che possono. Da parte loro, le aziende che usano software open source mediamente non brillano per lo sforzo che fanno nel controllare l'affidabilità del codice che adottano (e modificano) e nel tenere traccia di quello che hanno, negli anni, integrato nei loro progetti.
Serve mettere ordine in tutto questo, ora la Open Source Security Foundation (OpenSSF) cerca di farlo con un nuovo progetto battezzato Alpha-Omega Project. Che ha l'obiettivo di migliorare decisamente la "security posture" dell'open source agendo su due direttrici parallele. Da cui anche il nome del progetto: Alpha e Omega sono due attività distinte e complementari.
Omega è la componente del progetto per molti versi più ambiziosa. L'obiettivo è identificare un buon numero di progetti open source - "almeno diecimila", si spiega - che non sono critici come quelli del filone Alpha ma sono comunque molto diffusi. Sono troppi per pensare a personale e attività dedicate, motivo per cui l'idea è garantire la sicurezza del loro codice attraverso una combinazione di tre elementi: strumenti automatizzati per l'analisi del codice, team condivisi di security analyst che facciano triage dei risultati di queste analisi, processi standardizzati per il reporting confidenziale di eventuali vulnerabilità trovate nel tempo.
Qui diventa chiave una attività relativamente nuova per gli sviluppatori: la continua ottimizzazione dei test automatizzati da parte di un team dedicato di sviluppatori e analisti. Una operazione ciclica necessaria per fare in modo che i test non producano (troppi) falsi positivi ma scovino anche vecchie e nuove vulnerabilità. Anche la maggiore attenzione alla comunicazione delle vulnerabilità trovate è importante. Le "open disclosure" che la community open source apprezza sono giuste in principio ma rischiose nella pratica, sostiene di fatto OpenSSF. Vengono sfruttate immediatamente dai criminali per sviluppare exploit mirati, mentre gli utenti normali non sono abbastanza rapidi nel tappare le loro falle.
Non è immediato valutare la portata di Alpha-Omega Project. Di primo acchito appare una iniziativa simile ad altre già proposte e che si sono bloccate di fronte a un medesimo ostacolo: la scala del problema. L'open source è fatto da una miriade di progetti distinti che sono o potrebbero essere interessanti e utili alle imprese. Anche a voler essere selettivi, il lavoro per la messa in sicurezza di tutto questo è enorme.
Qui la questione chiave diventa la massa critica, dei nomi in gioco come dei progetti coinvolti. L'iniziativa può avere successo se a verificare la sicurezza dell'open source sono i grandi nomi dell'IT, che lo usano e su cui basano i loro prodotti o servizi. Per ora in prima fila ci sono Microsoft e Google, disposte a metterci sia investimenti (partono con 5 milioni di dollari) sia personale. Di OpenSSF fanno però parte aziende altrettanto importanti (AWS, Dell, Facebook/Meta, IBM, Oracle, Red Hat, VMware solo per citarne alcune) che al lancio di Alpha-Omega Project sono, per così dire, restate in disparte. Volendo essere un po' cinici, non è un buon segnale.
Parallelamente, Alpha-Omega Project è efficace se il numero di progetti open source certificati aumenta rapidamente. È scontato che i progetti chiave - pensiamo ad esempio a tutto il mondo della virtualizzazione o dei database - siano al centro dell'attenzione di tutti. La questione critica è andare a intervenire sulla "coda lunga" dei progetti open source che non sono sempre agli onori della cronaca ma che hanno i loro utenti. O che potrebbero diventare mainstream improvvisamente.
Questa - come ha sottolineato Eric Brewer, VP of Infrastructure in Google - sarà la parte più difficile. Richiederà "non solo investimenti e applicazione notevoli" ma anche tecnologie "di automazione estesa per individuare e idealmente risolvere le vulnerabilità" su una scala di decine e anche centinaia di migliaia di progetti. Anche per questo, spiega OpenSSF, servono finanziamenti e personale "per aumentare il numero di progetti open source che Alpha-Omega può raggiungere". La buona volontà c'è, resta da vedere se ci sarà anche questo auspicato riscontro da parte del mondo IT in generale.