Puoi farlo da solo o fidarti di qualcun altro
Come per la maggior parte delle cose nella vita, devi farlo tu stesso o fidarti di qualcun altro. Qui trusting copre sia l'assenza di intenti dannosi sia la capacità di eseguire correttamente l'attività.
Ad esempio, puoi presentare le tue tasse te stesso o fiducia a un consulente fiscale per farlo (che non solo non dovrebbe tentare di frodare te, ma anche sapere come file le tasse!).
Se sei un'azienda, da solo verrà effettivamente eseguita da uno o più dei tuoi dipendenti, che a loro volta devono essere considerati attendibili.
La terza parte di cui ti fidi, non ha bisogno di essere una singola persona. Potrebbe essere il Microsoft Windows Development Team , o gli sviluppatori principali di Wordpress .
Sulla sicurezza del codice sorgente, vuoi che l'esperto non solo sia ben intenzionato, ma sia anche ben informato per codificare il programma in modo sicuro / trovare potenziali problemi di sicurezza che potrebbero esserci.
(più alcuni sistemi di bordo aggiuntivi quando sono trattati nel suo insieme, ad esempio si desidera che il loro codice non venga compromesso mentre lo hanno caricato nel repository o l'email del dipendente che afferma che i risultati vengono sostituiti da un hacker malintenzionato all'interno della tua rete per dire che l'applicazione andava bene)
Dovrai valutare le tue opzioni, valutare il rischio associato a ciascuna di esse e scegliere il percorso che meglio si adatta ai tuoi interessi (e al budget!).
Se dovessi controllare la sicurezza del codice sorgente di un blog che utilizzava Wordpress, in genere confido che il codice originale fosse corretto1¹ e controlla le differenze tra la versione ufficiale e quella usata . Se il sito web è stato compromesso, ciò renderebbe molto più facile scoprirlo.
¹ Ovviamente controllando il registro delle modifiche delle versioni successive se ne è stato utilizzato uno obsoleto.
Tuttavia, se fosse stato sviluppato dal nipote del proprietario, mi aspetterei di trovare molte vulnerabilità lì e raccomanderei un controllo approfondito di tutto.
Nel tuo caso, dovresti valutare il rischio e il costo dello sviluppo dell'equivalente di quella libreria (prendi in considerazione che la possibilità di problemi nel tuo prodotto interno non è zero, e dipenderà - tra le altre cose - da la qualità delle persone coinvolte) rispetto al rischio e al costo dell'auditing e dell'utilizzo di tale libreria.
Ora, ci possono essere fattori attenuanti che semplificano il controllo. Ad esempio, se il codice non affidabile può essere eseguito in una macchina virtuale isolata, ciò potrebbe essere sufficiente per non richiedere ulteriori controlli (anche in questo caso, si sta attendendo l'implementazione della VM). Oppure può essere considerato sufficiente per controllare le parti di quel programma eseguite come root.
Per l'auditing di una libreria, gli analizzatori di codice possono aiutare a individuare parti problematiche (come indicato), ma per considerarlo pulito dovrei avere qualcuno che legge e capisce il codice, anche se superficialmente.
Ad esempio, la possibilità di rimuovere file arbitrari non è dannosa di per sé . Devi capire il programma per sapere se ha senso.
Ancora una volta, è una questione di minacce e rischi per quello che stai facendo. Se si preoccupa solo che la libreria esfiltrizzi i dati, il filtraggio delle connessioni al firewall potrebbe essere sufficiente. Se si è interessati alla libreria che elimina file importanti (e per qualche strana ragione non si può negare tale autorizzazione), si potrebbe semplicemente scorrere un gruppo di codice che eseguiva solo calcoli matematici. Se quella libreria calcola i parametri per lanciare un razzo ... beh, è meglio che anche quei calcoli siano corretti!