Controllo del codice sorgente e build finti

Tutto dipende dallo scopo dell'audit.

Se l'audit è puramente del codice (ovvero fornisce al revisore una copia del codice, lo controlla e restituisce un rapporto), potrebbe essere molto facile manometterlo dopo il fatto.

Se l'audit è un po 'più completo e include le procedure di sviluppo, test e promozione del codice in ambiente live, dovresti essere in grado di escludere la maggior parte delle opportunità di manomissione.

Se verifichi ulteriormente il processo di gestione delle modifiche in corso ed esegui regolarmente verifiche di conferma sul codice live, ti dai un livello ancora maggiore di sicurezza che il codice in diretta sia il codice sviluppato e testato, e che sia appropriato per scopo.

Questo è il motivo per cui gli audit dell'ambito limitato possono essere essenzialmente inutili, oltre a ottenere un segno di spunta nella casella (che potrebbe essere utile ...)

Tutto dipende da dove si trova il tuo limite di fiducia. Consiglierei di leggere Reflections on Trusting Trust di Ken Thompson [ 1 ].

Si spera che gli auditor forniscano una firma o un hash del file o della fonte che viene controllata; in questo modo puoi almeno verificare che stai effettivamente eseguendo lo stesso codice che è stato revisionato.

Tuttavia, anche se non ti fidi degli auditor e lo compili tu stesso dalla fonte che sai essere valida (fingeremo di essere davvero bravo a individuare le minacce nel codice che è probabilmente progettato per nasconderle), tu devo ancora fidarmi del tuo compilatore. Oppure, nel caso in cui tu stia scaricando una versione compilata dai revisori, il loro compilatore.

Sebbene questo sia probabilmente sicuro da fare, è bene riconoscere che compilarlo da solo non è infallibile. Non puoi mai completamente fidarti di nulla; devi impostare un limite di fiducia e decidere a che punto vuoi accettare qualcosa di sicuro.

Ecco perché molte persone usano GIT e Jenkings. L'idea è che tutto il codice entri in un repository centralizzato. Nessuna singola persona ha accesso completo alla compilazione completa, quando un programmatore invia un pezzo di codice che viene controllato da un altro programmatore prima di essere spinto verso l'alto nel ramo. Un programmatore non può semplicemente cambiare codice o compilare a piacimento.

Normalmente un audit del codice sorgente viene fatto subito prima della compilazione, il revisore vedrà controllare il codice prima che venga compilato e nessun altro può apportare modifiche senza che questo venga approvato dal revisore. Si noti inoltre che l'auditor non può introdurre il codice da solo. Ciò significa che non puoi semplicemente inviare qualcosa.

Sfortunatamente questa è la situazione ideale e non viene eseguita ovunque. Uno dei concetti di base della gestione delle modifiche consiste nell'avere 3 ambienti:

• sviluppo
• Garanzia di qualità
• Produzione

In fase di sviluppo tutti i programmatori hanno accesso, in QA solo alcuni (il meno possibile) e in produzione non un singolo programmatore dovrebbe avere accesso . Tutto ciò crea una ragionevole quantità di garanzia, ma potrebbe esserci ancora una manomissione. Alla fine si cerca di coprire il rischio nel miglior modo possibile, ma nulla è infallibile.

Direi che è fondamentalmente impossibile per un cliente fidarsi che una build corrisponda a una fonte controllata a meno che non la costruisca lui stesso. Anche quello è nessuna garanzia contro la presenza di porte sul retro o altre caratteristiche indesiderabili, una porta sul retro è uguale a un bug - non puoi mai provare che non ce n'è.

Spesso mi chiedo come funzioni in situazioni in cui la fiducia totale è problematica. Quando gli Stati Uniti vendono gli F-16 in Pakistan, come fanno i pakistani a sapere che non c'è una porta di servizio nell'avionica che li renderà ciechi verso gli elicotteri invisibili. Oops.