I dati del Project Zero dimostrano che la natura open source paga, anche dal punto di vista della sicurezza.
[ZEUS News - www.zeusnews.it - 21-02-2022]
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%.
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.
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».
Se questo articolo ti è piaciuto e vuoi rimanere sempre informato con Zeus News
ti consigliamo di iscriverti alla Newsletter gratuita.
Inoltre puoi consigliare l'articolo utilizzando uno dei pulsanti qui
sotto, inserire un commento
(anche anonimo)
o segnalare un refuso.
© RIPRODUZIONE RISERVATA |
|
|
||
|
Gladiator