Quando emerge una falla in un software a licenza libera - come Log4j, libreria distribuita sotto licenza Apache - parte immediatamente il coro di quanti si affrettano a ricordare che l'essere open source, per un software, non garantisce l'assenza di bug (ed è ovvio) e che anche questo modello di sviluppo si lascia sfuggire dettagli importanti.

L'obiezione è diretta contro quella che è una delle motivazioni più usate per sottolineare la maggiore sicurezza teorica del codice aperto rispetto al codice chiuso, ossia il fatto che un codice liberamente disponibile gode potenzialmente di un numero maggiore di occhi che lo controllano e che possono quindi individuare le varie falle. Se si scopre che un software open source contiene un bug che per anni non è stato individuato, ciò significa - sostengono gli obiettori - che l'assunto non è vero.

Si potrebbe essere tentati di credere a questo ragionamento, ma poi appaiono dati come quelli pubblicati dal Project Zero di Google, dai quali emerge che, nel complesso, l'efficienza e la velocità dimostrate dagli sviluppatori di software open source nel correggere i bug è maggiore di quella dei loro colleghi che lavorano sul software closed source.

Tra il gennaio 2019 e il dicembre 2021, il Project Zero ha individuato 84 vulnerabilità di sicurezza in prodotti Apple, 80 in prodotti Microsoft, 56 in prodotti Google, 25 in Linux. Nei 90 giorni successivi alla scoperta, Apple ha sistemato l'87% di quelle falle, Microsoft il 76%, Google il 95% e gli sviluppatori di Linux il 96%.

Non perderti anche:

2022, fuga dall'open source

Microsoft regala macchine virtuali con Windows 11

Microsoft scopre due serie falle in Linux

Windows 11, i PC non supportati mostreranno un fastidioso messaggio

Gli stessi dati mostrano che, se Microsoft ha bisogno in media di 83 giorni per rilasciare una patch, a Apple ne bastano 69, a Google 44, e agli sviluppatori di LInux soltanto 25.

Pare proprio, insomma, che una certa differenza tra il software open source e quello closed source ci sia davvero, ma che non sia svantaggiosa per il primo: anzi, sebbene nessun software sia immune da bug, l'essere parte di un grande progetto a sorgente aperto sembra essere benefico per la rapidità di risoluzione dei problemi.

Proposte di lettura:

L'app che blocca gli aggiornamenti indesiderati di Windows

Firefox e Chrome 100, millennium bug in miniatura

Bug in Firefox consente di ottenere privilegi di sistema

Log4j, stavolta ci è andata bene

Per quanto riguarda infine l'elevato numero di giorni che Microsoft impiega per rilasciare una patch, il Project Zero stesso spiega di sospettare che tale lungo tempo sia «conseguenza della cadenza mensile degli aggiornamenti del Patch Tuesday, che può rendere più difficile per i team di sviluppo rispettare la scadenza» di 90 giorni oltre la quale le falle scoperte dal progetto di Google vengono rivelate, scadenza alla quale spesso Microsoft si avvicina parecchio e alle volte supera.

«Speriamo» - scrive il Project Zero - «che Microsoft consideri l'adozione di una frequenza maggiore per il rilascio delle patch relative alla sicurezza, o che trovi un modo per semplificare i processi interni al fine di distribuire il codice più rapidamente».

Sullo stesso tema:

L'insostenibile debolezza del middleware: log4j

Microsoft ammette: SSD più lenti con Windows 11

Seccato con Microsoft, sviluppatore rivela una falla in Windows

Intel, due nuove falle nei processori