Il software open source è diventato l'asse portante dell'IT aziendale. E in effetti di qualsiasi espressione della nostra vita digitale. Che passa per qualche servizio cloud ed è supportata, quindi, da qualche piattaforma open source. Partendo da questo assunto, la robustezza del software open source diventa una questione fondamentale. Con una difficoltà in più rispetto al software completamente proprietario: la catena dello sviluppo è molto complessa.

Nello sviluppo open source è normale affidarsi a ciò che la community ha già creato. Quindi un generico ambiente open source si basa su diversi componenti altrettanto open. Che a loro volta possono basarsi su altri componenti del software libero. Questa catena di interdipendenze non è sempre visibile totalmente a chi sviluppa. E introduce il rischio di vulnerabilità a catena se la cyber security di ciascun componente non è in qualche modo verificabile.

Sinora, di fatto, non lo è stata. Software house e sviluppatori cercano di creare software open source sicuro. Ma hanno comunque dei limiti. Spesso fanno fatica a tenere traccia dei componenti open source che usano. I quali possono ad un certo punto dover essere aggiornati dopo la scoperta di una vulnerabilità. O dovrebbero essere sostituiti quando non sono più manutenuti. Solo che non sempre lo si fa. È un problema ben noto, sottolineato periodicamente da qualche indagine.
L'idea di una iniziativa centralizzata per verificare l'affidabilità del software open source non è del tutto in linea con il concetto di community. Questo ha portato ad una frammentazione delle iniziative in campo cyber security. Tra quelle "certificate" - come la Core Infrastructure Initiative della Linux Foundation o la Open Source Security Coalition di GitHub - a quelle che molte software house o istituzioni hanno messo in campo da sole.

Ora proprio la Linux Foundation prova a mettere ordine tra questi sforzi, con la formazione della Open Source Security Foundation (OpenSSF). Che al momento è uno sforzo organizzativo più che tecnico. Il tentativo di mettere a fattor comune il lavoro e le best practice in campo sicurezza dei suoi membri fondatori. Tra cui troviamo in particolare GitHub, Google, IBM, Microsoft, Red Hat.

È uno sforzo non banale. Perché anche nell'affrontare lo stesso problema generico della cyber security ogni azienda usa approcci diversi. Il campo di gioco può essere già comune, ma le regole del gioco non lo sono. Per questo, spiega proprio la OpenSSF, "dobbiamo arrivare ad un accordo sui problemi che intendiamo affrontare insieme e poi decideremo come risolverli al meglio cooperando come una unica fondazione".

Obiettivi e primi passi della OpenSSF

La strategia complessiva della OpenSSF è migliorare la sicurezza del software open source coordinando in maniera mirata varie iniziative della community. L'obiettivo generico è "mettere in sicurezza la open source security supply chain". Per questo però serve un meccanismo che permetta ai ricercatori della sicurezza di muoversi in maniera collaborativa. La OpenSSF deve in pratica definire, e in parte diventare essa stessa, questo meccanismo.

Si parte ovviamente dalle basi. Dal definire un linguaggio comune per quanto riguarda metriche di cyber security, strumenti, best practice, standard per le vulnerability disclosure. Fatto questo, in prospettiva futura c'è l'idea di focalizzare di volta in volta le risorse coordinate dalla OpenSSF sui software open source giudicati più critici.
Per ora la OpenSSF parte con due iniziative guida - le già citate CII e OSSC - affiancate da cinque gruppi di lavoro. Uno riguarda le vulnerability disclosure: passa troppo tempo tra la comunicazione di una vulnerabilità software e il momento in cui viene risolta. Questo anche perché il processo è quasi del tutto manuale. L'idea è invece definire un formato standard per le segnalazioni e una serie di API che automatizzino gli interventi sulle vulnerabilità scoperte.

Un altro gruppo di lavoro si dedica di fatto a un monitoraggio dei progetti open source, definendo alcune metriche chiave in funzione delle quali valutare il loro "stato" di cyber security. Questa valutazione viene resa pubblica e comunicata anche via API, in modo che sia sempre possibile avere una visione concreta della "security posture" dei componenti open source che si vogliono adottare.