Unsafe and Unused? A History of Utility Code in Mature Open Source Projects
Attraverso uno studio longitudinale di estrazione dati su sette progetti open-source maturi, questo articolo rivela che i file denominati con "util" hanno una probabilità significativamente maggiore di essere coinvolti in vulnerabilità e spesso rimangono inutilizzati, evidenziando la necessità per gli sviluppatori di riesaminare nel tempo la sicurezza e la manutenzione di tale codice di utilità.
Articolo originale dedicato al pubblico dominio sotto CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Immagina una città enorme e vivace dove migliaia di architetti e costruttori stanno costantemente costruendo e ristrutturando un grattacielo gigante e condiviso. Questo grattacielo è un progetto software open source. In questa città esiste una regola speciale: ogni volta che un costruttore crea uno strumento o una funzione che potrebbe essere utile a tutti—come una chiave inglese universale o un passpartout—è incoraggiato a metterlo in una stanza specifica e chiaramente etichettata chiamata "Util" (abbreviazione di "Utility").
L'idea è ottima: invece di far sì che ogni costruttore realizzi la propria chiave inglese, tutti ne prendono una dalla stanza "Util". Questo fa risparmiare tempo e mantiene le cose ordinate.
Ma un team di ricercatori del Rochester Institute of Technology ha posto una domanda semplice: Cosa succede effettivamente a queste stanze "Util" nel tempo? Rimangono sicure e utili, o diventano pericolose, disordinate e ignorate?
Per scoprirlo, hanno studiato sette famosi "grattacieli" (progetti software come il Kernel Linux, Django e Apache Tomcat) su un periodo di 147 anni di sviluppo combinato. Hanno esaminato la storia di ogni file, ogni rinominazione e ogni correzione di sicurezza. Ecco cosa hanno scoperto, spiegato in modo semplice:
1. Le stanze "Util" sono ovunque (ma non sempre utilizzate)
I ricercatori hanno scoperto che le stanze "Util" sono molto comuni. In alcuni progetti, quasi il 20% di tutte le stanze dell'edificio è etichettato come "Util".
- La buona notizia: Queste stanze sono molto utilizzate. In alcuni progetti, gli strumenti all'interno della stanza "Util" vengono prelevati e utilizzati 7 volte più spesso rispetto agli strumenti nelle stanze normali.
- Il rovescio della medaglia: Solo perché una stanza è etichettata "Util" non significa che venga utilizzata in modo efficiente. A volte, i costruttori creano una nuova stanza "Util", solo per rinominarla in seguito perché non era effettivamente utile, o la abbandonano completamente.
2. Le stanze "Util" sono più disordinate (più complesse)
Se una stanza normale è un semplice armadio, una stanza "Util" è spesso un laboratorio caotico pieno di cavi aggrovigliati e macchinari complessi.
- Lo studio ha rilevato che in 6 progetti su 7, i file "Util" erano significativamente più complessi dei file normali.
- Perché? Perché tutti riversano i propri strumenti "comuni" lì dentro. Nel tempo, questi file si ingrossano con troppe funzionalità, rendendoli più difficili da comprendere e più difficili da mantenere sicuri.
3. Le stanze "Util" sono uno sforzo di squadra (ma caotico)
Potresti pensare che se un file è "Util", tutti sappiano come usarlo. Lo studio ha esaminato chi stava lavorando su questi file.
- Hanno scoperto che spesso, la persona che ha costruito uno strumento nella stanza "Util" non è la stessa persona che lo utilizza.
- In effetti, nei dati più recenti, oltre il 57% delle persone che lavoravano su questi file si occupava solo di costruirli o solo di utilizzarli, ma raramente faceva entrambe le cose. È come una fabbrica dove le persone che costruiscono le macchine non le operano mai realmente, e le persone che le operano non le riparano mai. Questa disconnessione può portare a confusione.
4. Le stanze "Util" sono zone di pericolo (rischi per la sicurezza)
Questa è la scoperta più critica. I ricercatori hanno trattato le "vulnerabilità" (buchi di sicurezza) come crepe nelle fondamenta dell'edificio.
- Il grande picco: Nei primi giorni di un progetto, quando ci sono pochissimi file, un file "Util" ha fino a 10 volte più probabilità di avere una crepa di sicurezza rispetto a un file normale.
- Nel lungo termine: Anche man mano che i progetti maturano, i file "Util" rimangono più rischiosi. Lo studio ha rilevato che i file "Util" hanno 2,75 volte più probabilità di essere coinvolti in una correzione di sicurezza rispetto ai file non "Util".
- Il problema del "recidivo": Quando un buco di sicurezza viene riparato in un file "Util", è molto probabile che accada di nuovo. È come riparare una perdita in un tubo, solo per vedere lo stesso tubo esplodere di nuovo dopo pochi mesi. Questo suggerisce che il team non sta imparando dall'errore, forse perché il file è troppo complesso da riparare correttamente.
5. Il Kernel Linux è l'eccezione
I ricercatori hanno notato che il Kernel Linux (un progetto molto stabile e massiccio) si comportava diversamente dagli altri.
- Non seguiva le tendenze usuali. I suoi file "Util" non erano necessariamente più pericolosi e non venivano rinominati così spesso.
- I ricercatori sospettano che questo sia dovuto al fatto che il Kernel Linux è così vecchio e stabile che aveva già consolidato le sue abitudini "Util" prima ancora che iniziasse il periodo di dati che hanno studiato. È come un vecchio edificio che è stato ristrutturato così tante volte che i progetti originali sono da tempo scomparsi, ma la struttura è solida.
La conclusione
Il documento conclude che, sebbene l'idea di una stanza "Util" sia buona (per evitare che le persone reinventino la ruota), nella pratica queste stanze spesso diventano insicure e sottoposte a scarsa manutenzione.
- Diventano troppo complesse.
- Accumulano troppi buchi di sicurezza.
- Le persone che le costruiscono e le persone che le utilizzano spesso non parlano tra loro.
Il consiglio per i costruttori:
Non limitatevi a etichettare un file come "Util" e sperare nel meglio. Se siete un project manager, dovete:
- Documentare cosa significa effettivamente "Util" per il vostro team.
- Fare attenzione affinché questi file non diventino troppo complessi.
- Essere estremamente cauti con i controlli di sicurezza su questi file, perché la storia mostra che sono i più propensi a rompersi.
In breve: Nominare un file "Util" non lo rende una soluzione magica; a volte, lo rende semplicemente un bersaglio ad alto rischio.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.