Tuttavia questa forma di controllo incrociato può non bastare a prevenire bug e imperfezioni nel ramo stabile. Dunque bisogna accettare il fatto che anche dopo numerose revisioni, eseguite da diversi developer, è sempre possibile che l'utente finale si ritrovi con dei bug all'interno dell'applicazione ritenuta stabile. Anche se la revisione del codice dovrebbe essere uno dei processi "core" di un team di sviluppo e di un'azienda, è frequente rilevare errori e sbavature di diversa entità.

Gran parte dei team di sviluppo adotta licenze open source e questo apre le porte ai revisori del codice indipendenti che esaminano il prodotto e segnalano bug. Tuttavia considerare a priori i software open source come esenti da bug è sbagliato, nessun processo di sviluppo può considerarsi perfetto.

A secondo del tipo di progetto le persone all'interno della propria community che sono realmente qualificate per esaminarlo e capirlo a fondo possono essere davvero poche, ad esempio non è detto che siano disponibili developer competenti in merito ai protocolli di sicurezza, quindi la loro implementazione e revisione ricade unicamente sugli sviluppatori ufficiali che ovviamente non sono infallibili.

La soluzione non sta però nell'uso di licenze proprietarie né in modelli di sviluppo chiusi, anzi i software open source sono tendenzialmente più sicuri perché una volta scoperta una falla viene di solito creata un patch in minor tempo rispetto alla controparte proprietaria. Con il closed source le possibilità che un bug o una vulnerabilità non vengano mai scoperti, e dunque mai risolti, sono elevate.

Per migliore i processi di code review le aziende e le università dovrebbe investire maggiormente nella formazione sui protocolli di sicurezza, cosi da formare dei developer attenti a questi aspetti e dotati di una solida security perspective.

Via Mike Bursell (Red Hat)

CommentaDi' la tua

Il tuo indirizzo email non sarà mostrato pubblicamente. I campi obbligatori sono contrassegnati da *