Come valutare le librerie Open Source?

Logiche dannose e backdoor. Non è probabile che tu trovi uno strumento automatico per rilevare automaticamente cose come backdoor, logica dannosa, timebomb, ecc. Queste sono troppo difficili da rilevare con le tecniche attuali; è troppo facile nascondere una backdoor che le attuali tecniche di analisi non sono in grado di trovare. (Questo vale sia per l'analisi statica che per l'analisi dinamica). Inoltre, questi tipi di backdoor sono molto rari, probabilmente non abbastanza comuni da giustificare investimenti significativi nella costruzione di tale strumento.

Penso che dovresti preoccuparti di più delle vulnerabilità e degli errori piuttosto che delle backdoor mal posizionate. Sono molto più comuni. E, se ci si trova in un ambiente critico per la sicurezza in cui si ritiene che vi sia una minaccia significativa che una terza parte potrebbe tentare di inserire deliberatamente una backdoor in una particolare parte di codice che si sta utilizzando, beh, non si dovrebbe usare quel pezzo di codice a meno che non ti fidi del fornitore.

Oggi, le difese più efficaci in termini di tempo di sviluppo contro backdoor e timebomb dannosi sono le seguenti:

• Controlla gli sviluppatori. Scegli gli sviluppatori di cui ti fidi. Normalmente, vorrai che siano i tuoi dipendenti. Se utilizzi fornitori esterni, dovrai controllarli attentamente.

• Revisione obbligatoria del codice. Tutto il codice dovrebbe essere esaminato da una seconda persona, diversa dallo sviluppatore. Il flusso di lavoro e il repository di sviluppo del software dovrebbero essere progettati per tracciare e applicare questa politica. Questo fornisce il controllo in due persone: nessuna persona può introdurre il codice che non viene esaminato, e quindi se tutti prendono sul serio i requisiti della revisione del codice, questo processo dovrebbe rendere più difficile per un singolo individuo introdurre una backdoor senza essere rilevato.

  Vedi anche Come rivedere il codice per le backdoor? per la discussione correlata.

• Repository di software sicuro. Blocca il repository del codice sorgente e crea processi per garantire che nessun singolo insider possa introdurre codice dannoso nel file binario.

Tuttavia, queste tecniche rimangono limitate nella loro efficacia. Penso che dovresti considerare anche altre difese, come il trasferimento del rischio, l'isolamento e il sandboxing e il monitoraggio; Elaboro su questo altrove in questo sito .

Bug e vulnerabilità. Suggerirei che, per la maggior parte degli scopi, dovresti essere più preoccupato per bug e vulnerabilità (inavvertitamente introdotto da sviluppatori ben intenzionati ma fallibili). Esistono molti strumenti commerciali e open source per la scansione del codice sorgente per rilevare bug e vulnerabilità. Per gli strumenti commerciali, consultare la stampa specializzata; controlla, ad esempio, Fortify, IBM Appscan, Veracode e i loro concorrenti. Gli strumenti commerciali sono generalmente migliori degli strumenti open source.

Se si utilizza una libreria open source di terze parti, suggerisco anche di controllare il database di vulnerabilità CVE per i report di vulnerabilità passati e aperti. Cerca di vedere quante vulnerabilità sono state segnalate, quanto rapidamente sono state segnalate e se il progetto ha dettagli tecnici sulla natura della vulnerabilità. Questo dovrebbe darti un'idea della posizione di sicurezza del progetto.

Se vuoi un aspetto più approfondito, puoi consultare il database Coverity Scan per vedere se hanno scannerizzato la libreria . Puoi anche consultare il bug tracker della libreria per vedere come hanno gestito i problemi di sicurezza in passato. È possibile verificare se hanno un processo di segnalazione dei bug di sicurezza chiaramente indicato o un luogo in cui segnalare bug di sicurezza. Questi ti daranno un senso della maturità del processo di sviluppo del software del progetto e del suo atteggiamento nei confronti della sicurezza.

Potresti anche trovare il seguente white paper di settore: La sfortunata realtà delle librerie non protette .

Open source. La tua domanda sembra suggerire che potresti pensare che backdoor e timebomb siano una minaccia maggiore nel codice open source rispetto al codice sorgente chiuso. Mentre quello potrebbe essere vero, non sono a conoscenza di alcuna prova per tale asserzione. Se sei preoccupato per backdoor e timebomb, probabilmente dovresti esserne preoccupato in tutto il codice che stai usando, open source o closed source.

Un altro repository open source per informazioni sulla sicurezza e sui difetti che ho trovato è quello di Coverity , ma ci sono molti librerie open source usate nelle varie distribuzioni linux e un bel po 'di librerie usate nello sviluppo.

Una lista nera di componenti open source "non sicuri" sarebbe molto apprezzata, ma non sono riuscito a trovarne uno.

È possibile limitare ciò che il software Java può fare creando una politica di sicurezza con lo Strumento criteri e impostandola come criterio per la macchina virtuale Java. Questo è il meccanismo di sicurezza utilizzato per le applet Java.

Hai detto "open source". Ciò implica che hai il codice Java in mano. Quindi puoi andare oltre creando test automatici per il software Java usando un framework come JUnit e una quantità considerevole di codice a mano. È possibile ottenere una certa quantità di codice automatizzato per i test da strumenti come Quickcheck. Finalmente puoi usare uno strumento come Cobertura per verificare che tutte le linee e le diramazioni del codice siano esercitate dai test.

Se il test ha esito positivo all'interno della tua politica di sicurezza, hai verificato che il software non si allontana mai dalle tue restrizioni. Potresti non voler ancora rimuovere le restrizioni della tua politica di sicurezza per non leggere il codice. Ad esempio, se non sei riuscito a testare il 100% dei rami del software (che è spesso difficile da fare), c'è ancora la possibilità che il software rilevi la tua politica di sicurezza, JUnit o Cobertura e riduca di conseguenza il suo comportamento .