Un interessante studio commissionato dalla Linux Foundation (consultabile a questo indirizzo) tra chi contribuisce con il suo tempo e il suo lavoro ai progetti Foss (Free Open Source Software) ha evidenziato come in media questi sviluppatori abbiano dedicato meno del 3% del loro tempo all’analisi e alla soluzione di problemi collegati alla sicurezza dei software, e soprattutto abbiano mostrato scarsissimo desiderio di impegnarsi maggiormente su questo fronte. I ricercatori hanno proposto una serie di domande per cercare di comprendere meglio come i partecipanti alle community open source impieghino il loro tempo.
Il risultato più eclatante riguarda proprio lo scarso interesse verso le problematiche relative alla sicurezza, che alcuni intervistati hanno bollato come “un compito che prosciuga l’anima” o “un impaccio insopportabilmente noioso”. Più della metà dei partecipanti al sondaggio è stata in qualche modo retribuita per il lavoro svolto nella community, ma il denaro non è una motivazione determinante. Infatti chi collabora a progetti open source è spinto molto più spesso dal desiderio che il suo contributo venga riconosciuto e apprezzato dai colleghi; gli sviluppatori vogliono creare nuove funzioni e trovare soluzioni brillanti ai problemi aperti.
Come chiunque abbia scritto anche solo qualche riga di codice sa bene, la ricerca e la correzione dei bug è un’attività faticosa, spesso frustrante e indubbiamente noiosa. Gli sviluppatori non vogliono trasformarsi in analisti di sicurezza incaricati di effettuare auditing sul loro stesso codice; vorrebbero invece ricevere i risultati di queste analisi, che nei loro desideri dovrebbero essere svolte da altre figure. D’altro canto, da molti anni ormai è chiaro a chiunque si trovi a coordinare un progetto open source che le problematiche legate alla sicurezza e alla robustezza del codice hanno invece assunto una rilevanza cruciale, poiché molte aziende e interi comparti economici si affidano, in maniera sempre crescente, a progetti, strumenti e librerie open source.
I ricercatori hanno proposto diverse possibili vie d’uscita da questo vicolo cieco: innanzitutto, le organizzazioni dovrebbero allocare più risorse, umane ed economiche, per la ricerca e la soluzione dei problemi legati alla sicurezza. Si potrebbe anche pensare di riscrivere intere porzioni di codice poco robusto, invece di tentare di individuare e correggere gli errori specifici: una prospettiva probabilmente meno efficiente ma più appagante per chi lavora su base volontaria. Inoltre, abbandonando i linguaggi di programmazione “memory unsafe”, che consentono cioè di scrivere nella memoria senza controlli e restrizioni (i più diffusi sono C e C++), si potrebbero evitare in maniera automatica intere categorie di vulnerabilità, come il classico ma sempre attuale buffer overflow.