CI verifica per applicare regole di sviluppo specifiche: buone pratiche?

5

Quello che segue è tutto puramente ipotetico e ogni sua parte specifica può o non può descrivere con precisione persone o situazioni reali, sia che viva, sia morta o che faccia finta.

Diciamo che sono uno sviluppatore senior o un architetto responsabile di un team di sviluppo che lavora a un progetto. Questo progetto include una libreria di sicurezza per l'autenticazione / autorizzazione dell'utente dell'applicazione in fase di sviluppo. La libreria deve essere disponibile per gli sviluppatori da modificare; tuttavia, desidero "fidarmi ma verificare" che i programmatori non stiano facendo cose che potrebbero compromettere la sicurezza del sistema finito, e poiché questa non è la mia unica responsabilità, voglio che venga eseguita in modo automatico.

Come esempio, supponiamo di avere un'interfaccia che rappresenta un utente che è stato autenticato dalla libreria di sicurezza del sistema. L'interfaccia espone le informazioni di base dell'utente e un elenco di cose che l'utente è autorizzato a fare (in modo che l'app client non debba continuare a chiedere al server "Posso farlo?"), Il tutto in un modo immutabile, naturalmente. Esiste solo un'implementazione di questa interfaccia nel codice di produzione e, ai fini di questo post, possiamo dire che sono state prese tutte le misure appropriate per garantire che questa implementazione possa essere utilizzata solo da una parte del nostro codice che deve essere in grado per creare concrezioni dell'interfaccia.

I programmatori sono stati istruiti sul fatto che questa interfaccia e la sua implementazione sono sacrosante e che qualsiasi cambiamento deve passare attraverso di me. Tuttavia, quelle sono solo parole; la fonte della libreria di sicurezza è aperta per necessità di modifica. Qualcuno dei miei sviluppatori potrebbe decidere che questa implementazione protetta, privata, con controllo hash deve essere pubblica in modo che possano eseguire X, oppure in alternativa possono creare la propria implementazione di questa interfaccia pubblica in una libreria diversa, esponendo l'algoritmo di hash che fornisce il checksum sicuro, al fine di fare Y. Potrei non essere a conoscenza di questi cambiamenti in modo da poter battere lo sviluppatore in testa per questo. Un utente malintenzionato potrebbe quindi trovare questi piccoli nugget in una libreria non offuscata del prodotto compilato e sfruttarlo per fornire utenti falsi e / o autorizzazioni amministrative erroneamente elevate, ignorando l'intero sistema di sicurezza.

Questa possibilità mi tiene sveglio per un paio di notti, e poi creo un test automatizzato che controlla in modo riflessivo la base di codici per i tipi derivanti dall'interfaccia, e fallisce se trova qualcosa che non è esattamente ciò e dove mi aspetto che loro essere. Compilo questo test in un progetto in una cartella separata del VCS a cui solo io ho diritti di commit, ho CI che lo compila come libreria esterna del progetto principale, e lo configuro per essere eseguito come parte della suite di test CI per l'utente si impegna. Ora, ho un test automatizzato sotto il mio controllo completo che mi dirà (e chiunque altro) se il numero di implementazioni aumenta senza il mio coinvolgimento, o un'implementazione che conoscevo ha qualcosa di nuovo aggiunto o ha i suoi modificatori o quelli dei suoi membri cambiati. Posso quindi indagare ulteriormente e riguadagnare l'opportunità di battere gli sviluppatori in caso di necessità.

Questo è considerato "ragionevole" da voler fare in situazioni come questa? Sarò visto in una luce negativa per andare dietro alle spalle dei miei sviluppatori per assicurarmi che non stiano facendo qualcosa che non dovrebbero?

    
posta KeithS 04.04.2012 - 21:45
fonte

2 risposte

4

Questo non è irragionevole, perché è una buona idea fare revisioni di codice per il codice basato sulla sicurezza. Potresti mandare gli sviluppatori a fare revisioni del codice prima di controllare il codice, ma questo non ti protegge se dimentica e controlla comunque.

    
risposta data 04.04.2012 - 22:01
fonte
1

Quello che vuoi è completamente ragionevole. Il nostro processo di compilazione di elementi di configurazione, oltre a compilare il codice, esegue StyleCop, FxCop e NCover ed esegue test di unità. Il risultato è stato un codice di qualità molto più elevato, codice che è più leggibile e mantenibile. Potresti anche fare altre cose automatizzate, come l'analisi statica dei contratti in codice C #.

Un buon effetto collaterale è che durante le nostre revisioni del codice possiamo concentrarci su cose che contano davvero al posto di stili / best practice.

    
risposta data 05.04.2012 - 04:02
fonte

Leggi altre domande sui tag