Un’analisi su larga scala della storia dello sviluppo del kernel Linux ha portato alla luce un fenomeno che merita attenzione: una parte significativa dei bug rimane inosservata per lunghi periodi, con una media di oltre due anni prima che vengano individuati e corretti. Lo studio, condotto su più di 125.000 difetti registrati nella cronologia Git dal 2005 al 2026, mostra che circa il 20% degli errori rimane nel codice per più di cinque anni, mentre alcuni casi eccezionali superano i vent’anni di permanenza. Il dato più eclatante riguarda un bug nel network stack rimasto attivo per 20,7 anni prima di essere scoperto e risolto.

Questa ricerca si basa sull’analisi del tag “Fixes:” utilizzato dagli sviluppatori del kernel per collegare un commit correttivo al commit originale che ha introdotto il problema. Attraverso questo metodo è stato possibile ricostruire la vita di ogni bug, confrontando la data di introduzione con quella della correzione. Il risultato è un quadro dettagliato della longevità dei difetti e delle differenze tra le varie aree del kernel.

Differenze tra sottosistemi e tempi di rilevamento dei bug

Lo studio evidenzia come la velocità di individuazione dei bug vari sensibilmente a seconda del sottosistema coinvolto. I driver della rete CAN mostrano un tempo medio di scoperta di oltre quattro anni, mentre il protocollo SCTP presenta una permanenza simile. Al contrario, i problemi relativi ai driver GPU vengono identificati molto più rapidamente, con una media di circa un anno e mezzo. La sottosezione BPF si distingue per la rapidità con cui vengono rilevati i difetti, con un tempo medio di poco superiore a un anno.

Queste differenze sono attribuite al livello di utilizzo, alla complessità del codice e all’attenzione che la comunità dedica a ciascun componente. Le parti del kernel più attivamente sviluppate e testate tendono a mostrare una maggiore velocità di individuazione dei problemi, mentre quelle meno utilizzate o più complesse possono nascondere difetti per periodi molto più lunghi.

Il ruolo delle correzioni incomplete e dell’intelligenza artificiale

Un altro elemento emerso dall’analisi riguarda la frequenza delle correzioni incomplete. In diversi casi gli sviluppatori intervengono solo sui sintomi del problema senza risolvere la causa profonda, lasciando spazio a nuove vulnerabilità o a modi alternativi per aggirare la patch. Un esempio citato riguarda una modifica al netfilter introdotta nel 2024, che un ricercatore di sicurezza è riuscito ad aggirare l’anno successivo, costringendo a un ulteriore intervento.

Per affrontare questa complessità è stato sviluppato un modello di intelligenza artificiale chiamato VulnBERT, progettato per analizzare i commit e prevedere la probabilità che introducano vulnerabilità. Lo strumento offre un supporto utile per individuare cambiamenti potenzialmente rischiosi e migliorare la qualità del codice, fornendo alla comunità un nuovo approccio per affrontare la crescente mole di modifiche che caratterizza lo sviluppo del kernel.