L'idea che il software open source sia intrinsecamente più sicuro del software closed source - o la nozione opposta - non ha senso. E quando le persone dicono qualcosa del genere spesso è solo FUD e non fa avanzare significativamente la discussione.

Per ragionare su questo devi limitare la discussione a un progetto specifico . Un software che elimina un prurito specifico, viene creato da un team specifico e ha un pubblico di destinazione ben definito. Per un caso così specifico potrebbe essere possibile ragionare sul fatto che l'open source o il closed source serviranno al meglio il progetto.

Il problema con la presentazione di tutte le implementazioni "open source" rispetto a tutte le implementazioni "closed source" è che non si stanno solo confrontando le licenze. In pratica, l'open source è favorito dagli sforzi di volontari obbligati e il closed source è più comune negli sforzi commerciali. Quindi stiamo effettivamente confrontando:

• Licenze.
• Accesso al codice sorgente.
• Strutture di incentivi molto diverse, per -profitto contro per divertimento.
• Situazioni di responsabilità legale molto diverse.
• Dimensioni del team e competenze del team differenti e molto variabili.
• ecc.

Per tentare di giudicare come funziona tutto questo per la sicurezza su tutto il software rilasciato come open / closed source semplicemente fallisce. Diventa una dichiarazione di opinione, non un fatto.

Il software mantenuto è più sicuro del software che non lo è. Lo sforzo di manutenzione è, ovviamente, relativo alla complessità di detto software e al numero (e all'abilità) di persone che lo stanno guardando. La teoria alla base della maggiore sicurezza dei sistemi opensource è che ci sono "molti occhi" che guardano al codice sorgente. Ma questo dipende molto dalla popolarità del sistema.

Ad esempio, nel 2008 sono stati scoperti in OpenSSL diversi buffer overflow, alcuni dei quali hanno portato all'esecuzione di codice in modalità remota. Questi bug erano presenti nel codice da diversi anni. Quindi, sebbene OpenSSL fosse opensource e avesse una base di utenti sostanziale (questa è, dopotutto, la libreria SSL principale utilizzata per i siti Web HTTPS), il numero e l'abilità dei revisori del codice sorgente non erano sufficienti per superare l'intrinseco complessità della decodifica ASN.1 (la parte di OpenSSL in cui si nascondevano i bug) e del codice sorgente di OpenSSL (francamente, questo non è il codice sorgente C più leggibile in assoluto).

I sistemi a sorgenti chiusi hanno, in media , molte meno persone a fare Q&A. Tuttavia, molti sistemi closed source hanno sviluppatori e tester pagati , che possono impegnarsi a tempo pieno nel lavoro. Questo non è realmente inerente alla domanda apri / chiudi; alcune aziende impiegano persone per sviluppare sistemi opensource e, presumibilmente, si potrebbe produrre un software closed source gratuitamente (questo è relativamente comune nel caso dei "freeware" per Windows). Tuttavia, esiste ancora una forte correlazione tra avere tester pagati ed essere closed source (la correlazione non implica la causalità, ma questo non significa nemmeno che le correlazioni debbano essere ignorate).

D'altra parte, essere closed source rende più facile nascondere i problemi di sicurezza, il che è male , ovviamente.

Esistono esempi di sistemi open source e closed source, con molti o pochissimi problemi di sicurezza. I sistemi operativi opensource * BSD ( FreeBSD, NetBSD e OpenBSD e pochi altri) hanno un ottimo track record per quanto riguarda la sicurezza. Così fa Solaris, anche quando era un sistema operativo closed source. D'altra parte, Windows ha (aveva) una pessima reputazione in questa materia.

Riepilogo: a mio parere, l'idea "opensource implica sicurezza" è sopravvalutata. Ciò che è importante è il tempo (e l'abilità) dedicato al monitoraggio e alla risoluzione dei problemi di sicurezza, e questo è per lo più ortogonale alla questione dell'apertura della fonte. Tuttavia , non vuoi solo un sistema sicuro, ma anche un sistema che conosci positivamente (non essere svaligiato è importante, ma essere in grado di dormire la notte anche). Per quel ruolo, i sistemi opensource hanno un leggero vantaggio: è più facile essere convinti che non ci sia un buco di sicurezza deliberatamente nascosto quando il sistema è opensource. Ma la fiducia è una cosa sfuggente, come è stato dimostrato con la recente tragicommedia intorno alle presunte backdoor in OpenBSD (per quanto ne so, si è rivelata una falsa pista, ma, concettualmente, non posso esserlo sicuro a meno che non controlli il codice da solo).

Penso che la versione più semplice e semplice di questo sia quella di ingegneria del software. L'argomento di solito segue: il software open source è più sicuro perché puoi vedere il sorgente !

Hai le conoscenze di ingegneria del software per comprendere il kernel dall'alto al basso? Certo, puoi guardare un driver del genere, ma hai una conoscenza completa di cosa sta succedendo per dire "ah sì, ci deve essere un bug lì"?

Ecco un esempio interessante: no molto tempo fa un bug di dereferenziazione del puntatore nullo è apparso in uno dei kernel beta che era una cosa abbastanza grande, scoperto dal ragazzo di grsecurity (patch PaX):

• Articolo LWN
• Copertura di Slashdot

È stato introdotto in un pezzo di codice come questo:

  pointer = struct->otherptr; if (pointer == NULL) {/ * gestione degli errori * /} / * il codice continua, dereferenziando quel puntatore che con il controllo ottimizzato può essere NULL. Problema. * /  

e il controllo pointer == NULL è stato ottimizzato dal compilatore, giustamente, poiché un puntatore null non può essere dereferenziato a una struttura contenente membri, non ha senso che il puntatore nella funzione sia mai nullo. Il compilatore quindi rimuove il controllo che lo sviluppatore dovrebbe essere presente.

Ergo, vis a vis, concordemente, il codice sorgente per un progetto così grande potrebbe sembrare corretto, ma in realtà non lo è.

Il problema è il livello di conoscenza necessario qui. Non solo devi avere una discreta dimestichezza (in questo caso) C, assembly, il particolare sottosistema del kernel, tutto ciò che va di pari passo con lo sviluppo dei kernel, ma devi anche capire cosa sta facendo il tuo compilatore.

Non fraintendermi, sono d'accordo con Linus sul fatto che con abbastanza occhi, tutti gli insetti sono superficiali. Il problema è la conoscenza nel cervello dietro gli occhi. Se stai pagando 30 ragazzini magri per sviluppare il tuo prodotto ma il tuo progetto open source ha solo 5 persone che hanno una reale conoscenza della base di codice, allora chiaramente la versione closed source ha una maggiore probabilità di meno bug, assumendo una complessità relativamente simile .

Chiaramente, questo è anche per ogni dato progetto transitorio nel tempo, come discute Thomas Pornin.

Aggiornamento modificato per rimuovere i riferimenti a gcc errati, poiché non lo era.

Penso che le premesse che la maggior parte usa per distinguere tra closed e open source siano abbastanza ben definite. Molti di questi sono elencati qui, entrambi hanno i loro sostenitori. Non sorprende che i fautori di Closed Source siano quelli che lo vendono. I sostenitori dell'Open Source l'hanno anche reso un affare carino e ordinato (oltre a pochi che l'hanno assunto come religione).

Il movimento Pro Open Source parla delle basi, e quando si tratta di sicurezza in generale ecco i punti che si adattano maggiormente alla discussione:

1. La premessa della personalizzazione
2. La premessa della gestione delle licenze
3. La premessa del formato aperto
4. La premessa di Many Eyes
5. La premessa di Quick Fix

Quindi, suddividendola per premessa, penso che le ultime due siano state trattate in modo piuttosto succinto da altri qui, quindi li lascio soli.

1. La premessa della personalizzazione
   Poiché si applica alla sicurezza, la premessa della personalizzazione offre alle aziende che adottano il software la possibilità di creare ulteriori controlli di sicurezza su una piattaforma esistente senza dover garantire una licenza o convincere un fornitore a riparare qualcosa di loro. Consente alle organizzazioni che hanno bisogno di, o vedono una lacuna, aumentare la sicurezza complessiva di un prodotto. SELinux è un esempio perfetto, puoi ringraziare la NSA per averlo restituito alla comunità.
   

2. La premessa per la gestione delle licenze
   Spesso si dice che se si utilizzano tecnologie F / OSS non è necessario gestire licenze tecnologiche con terze parti (o se lo si fa è molto meno), e questo può essere vero per ecosistemi interamente Open Source. Ma molte licenze (in particolare la GPL) impongono requisiti ai distributori e la maggior parte degli ambienti del mondo reale sono miscele eterogenee di tecnologie chiuse e open source. Quindi, anche se alla fine riduce la spesa per il software, la disponibilità della fonte può portare alcune aziende a violare le licenze OSS mantenendo la fonte privata quando hanno l'obbligo di rilasciarla. Ciò alla fine può trasformare la premessa di gestione delle licenze in una responsabilità (che è l'argomento closed source contro licenze come la GPL.)

3. Il Premessa di formato aperto
   Questa è una frase importante e con la quale tendo a essere d'accordo, quindi la terrò breve per evitare di predicare. Tra 30 anni voglio poter aprire un file che ho scritto. Se il file è "protetto" utilizzando controlli DRM proprietari e il software di cui ho bisogno per accedervi non viene più venduto, la difficoltà di accesso al contenuto mio è aumentata notevolmente. Se esiste un formato utilizzato per creare il mio documento che è aperto e disponibile in un prodotto open source di 30 anni fa, è probabile che sia in grado di trovarlo e di poterlo utilizzare legalmente. Alcune aziende stanno saltando sul carro del gruppo "Open Formats" senza saltare sul carrozzone dell'Open Source, quindi questo argomento penso sia piuttosto valido.

C'è un sesta premessa che non ho elencato, perché non è ben discussa. Tendo a rimanere bloccato su questo (chiamiamolo paranoia.) Penso che la sesta premessa sia il fiore all'occhiello dei dipartimenti della difesa di tutto il mondo. È stato spiegato al mondo quando una parte del sorgente di Windows 2000 è trapelata.

La premessa della responsabilità a fonte chiusa
Se un'azienda ha prodotto una libreria di codice sorgente chiusa o un'API attraverso più versioni nel corso dei decenni, piccoli gruppi di individui hanno avuto accesso a quella fonte durante la sua produzione. Alcuni di questi sono gruppi di controllo di terze parti e sviluppatori che sono passati ad altre società / governi. Se quel codice è sufficientemente statico, per mantenere la compatibilità è una premessa del vantaggio closed source, quindi alcuni punti deboli possono rimanere senza preavviso per molti anni. Coloro che hanno accesso a quel codice sorgente chiuso hanno la libertà di eseguire strumenti di analisi del codice per studiare questi punti deboli, i repository di bug di quei negozi di sviluppo software sono pieni di bug "minori" che potrebbero portare a exploit. Tutte queste informazioni sono disponibili a molte persone interne.

Gli aggressori lo sanno e vogliono queste informazioni per se stessi. Questo pone un obiettivo gigante sull'infrastruttura interna della tua azienda se sei uno di questi negozi. E così com'è, i tuoi processi di sviluppo diventano una responsabilità per la sicurezza. Se la tua azienda è abbastanza grande e la tua base di codice ben distribuita, puoi persino essere un obiettivo per gli sforzi di infiltrazione umana. A questo punto la tecnica di Charlie Miller: corrompere uno sviluppatore con abbastanza soldi e lui ti scriverà un bug non rilevabile diventa una possibilità concreta.

Ciò non significa che non entri nei prodotti OSS allo stesso modo. Significa solo che hai un set di dati, quindi quando rilasciato, può esporre punti deboli nella tua base di installazione. Mantenerlo privato ha creato un debito di codifica nei confronti dei sistemi installati dai clienti che non puoi rimborsare immediatamente.

Ti consigliamo di leggere questi documenti:

• Milk or Wine: la sicurezza del software migliora con l'età?
• Maggiore sicurezza grazie all'open source
• closed source e open source in un modello di dinamica dei bug del software
• sicurezza in open vs Sistemi chiusi
• Sistemi aperti e chiusi sono equivalenti

Il risultato è che aperto o chiuso è più o meno equivalente a seconda di come su di loro vengono eseguiti molti test. E per "test" non intendo ciò che fa il tuo "tester" aziendale medio di droni, ma piuttosto l'esperienza sul campo.

Siamo onesti qui, quando qualcuno afferma che l'open source è più sicuro del closed source, sta generalizzando su ciò che accade oggi nei sistemi operativi server / desktop, come Linux (open source) rispetto a Mac / Windows (proprietario, closed source ).

Perché è più probabile che il malware colpisca il secondo e non il primo? Per diversi motivi, per i quali ritengo il più importante sia il primo (preso in prestito da quest'altra risposta a una domanda contrassegnata come duplicata di questa):

1. Il software installato dall'utente nel caso di una distribuzione Linux (o altro sistema operativo open source), di solito è confezionato da un'organizzazione centralizzata (cioè, nel caso di Ubuntu, è fatto da Canonical e ospitato da esso), che ospita binari compilati da sorgenti curate / monitorate dalla comunità open source. Ciò significa che la probabilità che l'utente installi software infetto, o la probabilità che la comunità opensource accetti modifiche di codice dannoso, è molto inferiore rispetto al caso di Mac / Windows, dove l'utente installa solitamente software da molti posti diversi sul web o da molti fornitori diversi di AppStore. C'è anche il rischio che i server dell'organizzazione (ad esempio Canonical) vengano violati, ma questo rischio è minore perché queste organizzazioni impiegano esperti IT di prim'ordine per eseguire i propri server.
2. Linux (o altri sistemi operativi opensource) il numero di utenti è molto inferiore a quello degli utenti Windows / Mac , quindi i creatori di malware preferiscono non prenderli di mira (poiché il rapporto costi / benefici è inferiore in questo caso).
3. Linux, essendo solo un kernel, è disponibile in varie distribuzioni diverse tra cui puoi scegliere , quindi i creatori di malware dovrebbero dedicare uno sforzo maggiore per rendere il loro codice dannoso compatibile con molti di essi (quindi il rapporto costi / benefici è inferiore in questo caso).
4. I sorgenti di Linux (o altri sistemi operativi opensource) sono aperti a tutti da vedere / modificare. Ciò significa che quando viene rilevata una vulnerabilità di sicurezza, chiunque può scrivere una correzione per essa (non c'è alcun vincolo del fornitore, non sei legato a un'organizzazione specifica che devi aspettare per sviluppare una correzione), quindi in teoria il le patch di sicurezza vengono applicate prima che nei casi di software proprietario. (Tuttavia, in pratica, di solito non c'è differenza, perché le società che eseguono piattaforme proprietarie come Windows e MacOS, sono grandi società che sono abbastanza competenti.)

L'articolo di Jim Fruchterman su OpenSource.com " Il tuo software di sicurezza open source è meno sicuro?" fornisce un'ottima analogia per come l'open source, nonostante gli hacker sappiano come funziona, rende il software più sicuro per utenti finali:

pensa alla crittografia come a una combinazione bloccata sicura per i tuoi dati. Potresti essere l'unico ad avere la combinazione, oppure affidarla a pochi stretti collaboratori. L'obiettivo di una cassaforte è impedire a persone non autorizzate di accedere al suo contenuto. Potrebbero essere ladri che tentano di rubare preziose informazioni aziendali, dipendenti che cercano di apprendere informazioni riservate sullo stipendio dei loro colleghi o un truffatore che desidera ottenere informazioni riservate per perpetrare una truffa. In tutti i casi, vuoi che la cassaforte mantenga le tue cose al sicuro e tenga fuori le persone non autorizzate.

Ora diciamo che sto scegliendo una cassaforte per i miei oggetti di valore. Scelgo la cassaforte numero uno pubblicizzata per avere pareti in acciaio da mezzo pollice, una porta spessa un pollice, sei bulloni di chiusura e viene testata da un'agenzia indipendente per confermare che il contenuto sopravviverà per due ore in caso di incendio? Oppure scelgo Safe Number Two, una cassaforte che il venditore dice semplicemente di fidarsi, perché i dettagli di progettazione della cassaforte sono un segreto commerciale? Potrebbe essere Safe Number Two è realizzato in compensato e lamiera sottile. Oppure potrebbe essere più forte di Safe Number One, ma il punto è che non ne ho idea.

Immagina di avere i piani dettagliati e le specifiche della cassaforte numero uno, sufficienti per costruire una copia esatta di quella cassaforte se avessi i materiali e gli strumenti giusti. Questo rende Safe Number One meno sicuro? No non lo fa. La sicurezza di Safe Number One si basa su due protezioni: la forza del design e la difficoltà di indovinare la mia combinazione. Avere i piani dettagliati aiuta me, o esperti sicuri, a determinare quanto è buono il design. Aiuta a stabilire che la cassaforte non ha difetti di progettazione o una seconda combinazione "porta di servizio" diversa dalla combinazione scelta da me che apre la cassaforte. Tieni presente che un buon design sicuro consente all'utente di scegliere la propria combinazione a caso. Conoscere il design non dovrebbe affatto aiutare un utente malintenzionato a indovinare la combinazione casuale di una specifica cassaforte utilizzando quel design.