Eric Raymond nel suo libro “The Cathedral and the Bazaar” scrisse:
“Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.”
Oggi sappiamo che tutto ciò non è vero.

Il software prodotto dalla comunità open source non è sicuro dagli attacchi!
Per l’autore del libro, il concetto di Eric Raymond risulta fallimentare in due punti:
1.       Non si conoscono le motivazioni di chi riguarda il codice.
2.       Non si conoscono le capacità tecniche di chi è alla ricerca di bugs.
 
Motivazione
Il primo punto e facilmente riassumibile.
Uno sviluppatore è un creativo e creare nuovo codice e affrontare nuovi problemi è ciò che lo incentiva di più (come dicevamo nell’introduzione).
Michael Howard ammette d’aver lavorato con migliaia di sviluppatori ed ha insegnato loro come controllare e ridisegnare il proprio codice affinchè non vi fossero problemi di sicurezza; e quello che ha imparato è che gli sviluppatori non si divertono a cercare bugs e vulnerabilità.
Il numero di bugs è proporzionale alla grandezza del codice che si sta controllando.
Ciò non significa che più codice abbiamo da controllare più persone abbiamo di bisogno; ma significa solamente che avremo bisogno di persone più motivate e con una conoscenza più ampia di ciò che stanno facendo.
Capacità tecniche
Avere una conoscenza tecnica sulla sicurezza e sulle vulnerabilità dei sistemi informatici è un punto critico su cui si basa tutta SDL.
Sembra ovvio ma se le persone addette al controllo del codice non capiscono un’H di sicurezza, difficilmente sapranno trovare qualcosa nel vostro codice.
Open source
Evitando inutili battaglie di opinioni, andremo ad analizzare ciò che è accaduto a due prodotti di maggior impatto nella comunità open source e nella comunità non open: Microsoft Internet Information Services (IIS) 5 e 6, Apache 1.3.x e Apache 2.0.x.
“IIS6 has had substantially fewer security bugs than IIS5, but Apache 2.0.x had more than Apache 1.3.x” (Howard 2004)
E giusto per riportare altri commenti:
“Experience shows this simply isn’t true,”  the research firm states, calling it “the myth of more eyes,” citing case after case where no one spotted critical flaws in open source code. (Network World, citing a Burton Group report (Burton 2005)
Now, I’m not going to throw any of that “many eyeballs” nonsense at you-much of the code we use never gets audited. Jay Beale, Bastille Linux (Beale 2002)
Tutto ciò evidenzia che avere più occhi alla ricerca di bugs non crea software più sicuro; ecco, giusto per gradire, un elenco di software open source i quali bugs tarchiato la sicurezza per anni:
·         Sendmail e-mail server (CVE-2003-0161): 15 anni!
·         MIT’s Kerberos authentication protocol (CVE-2003-0060): 10 anni
·         SAMBA file and print (CVE-2003-0085): 7 anni
·         MIT’s Kerberos authentication protocols (CVE-2005-1689): 5 anni
·         Eric Raymond’s Fetchmail e-mail server (CVE-2002-0146): 5 anni e mezzo
 
Metodi proprietari
Molte aziende hanno il loro metodo di sviluppo:
·         Waterfall (Wikipedia 2002a)
·         Spiral (Wikipedia 2002b)
·         Capability Maturity Model Integration (Carnegie Mellon 2000)
·         Team Software Process (Carnegie Mellon 2003)
·         Personal Software Process (Carnegie Mellon 2003)
·         Agile
Attualmente non si è ancora in grado di stabilire se i metodi elencati sopra possono essere migliori rispetto a metodologie utilizzate da aziende come: IBM, Oracle, Sun e Symantec.
L’unica cosa che sappiamo è che spesso si richiede all’utente di scaricare patch o cambiare configurazioni.
Metodo Agile
Il metodo Agile, eXtreme Programming, è stato applicato da Wikipedia 2006, permettendo di sviluppare codice in maniera veloce e affidabile.
Microsoft ha sviluppato Microsoft Solutions Framework per i metodi Agili il quale aggiunge una checklists per la sicurezza e un modello per le minacce.
Certo, non è abbastanza, ma tra non avere niente e aver qualcosa, meglio aver qualcosa.

 

Tags: