Francamente cerchiamo di non passare attraverso la tua base di codice, proviamo a scrivere strumenti per farlo per noi.
Innanzitutto, la teoria. La sicurezza è un requisito di un sistema software, quindi come altri requisiti (funzionalità, usabilità, accessibilità, prestazioni ecc.) Dovrebbe essere considerata in ogni fase del flusso di lavoro di ingegneria del software dalla raccolta dei requisiti alla distribuzione e manutenzione. In effetti, questo è possibile ed esiste una guida per aiutare i team di progetto software a farlo. Anche se lavoro principalmente con sviluppatori iOS, la mia descrizione preferita di "ciclo di vita dello sviluppo sicuro" è di Microsoft Press .
In questo modello, la sicurezza delle applicazioni inizia quando stiamo cercando di ottenere requisiti dai nostri utenti. Dobbiamo scoprire i loro problemi di sicurezza e privacy, il che non è facile perché siamo gli esperti, non gli utenti, e dove capiscono i loro requisiti di sicurezza potrebbero avere difficoltà a esprimerli. Dobbiamo anche scoprire a quali rischi sarà esposto il software durante l'implementazione e quale livello di rischio è accettabile.
Progettiamo la nostra applicazione tenendo conto di tali requisiti. Scriviamo il codice con l'obiettivo di soddisfare tali requisiti ed evitare ulteriori rischi associati a errori di sicurezza a livello di codice. Testiamo il software per assicurarci che il nostro modello di sicurezza sia coerente con ciò che abbiamo realmente costruito, quindi implementiamo il software in modo che corrisponda ai presupposti che abbiamo fatto sull'ambiente quando abbiamo progettato la cosa. Infine, forniamo supporto e manutenzione che aiutano l'utente a far funzionare il software in modo coerente con i propri requisiti di sicurezza e che consente a loro (e noi) di reagire a nuovi cambiamenti nei rischi presentati.
Ok, così tanto per la teoria. In pratica , per ragioni che sono spiegate molto bene (anche se in modo non tecnico) in Geekonomics e che sono principalmente dovute al modo in cui le società di software sono motivate, la maggior parte delle cose di cui sopra non accade. Invece, abbiamo questo. Gli sviluppatori dovranno:
- assumere un ragazzo o una ragazza di sicurezza per essere presenti quando fanno un'offerta per un contratto, per dimostrare che "ottengono" sicurezza.
- scrivere software.
- assumere un ragazzo o una ragazza di sicurezza per convalidare il software prima del rilascio, risolvendo molti problemi sorti nel passaggio 2.
- patch tutto il resto dopo la distribuzione.
Quindi, ciò che la maggior parte delle persone addette alla sicurezza delle app sta realmente facendo, come dici tu, trovare bug. Questa è davvero una recensione di codice glorificata, ma è una revisione di codice altamente focalizzata condotta da persone che sono esperti del tipo di bug che questa recensione sta cercando, quindi c'è ancora valore nell'ottenere aiuto esterno nel farlo. Questa è una regola generale di teting, ovviamente: fai sempre testare qualcun altro che non è stato coinvolto nel fare la cosa.
Se accettiamo quanto sopra come vero, ne consegue che le persone che prendono decisioni di acquisto probabilmente equipareranno "un ragazzo di sicurezza capace" a "trova molti bug". Coloro che fanno lavorare i computer per loro troveranno più bug di quelli che non lo fanno, quindi ovviamente fanno molto affidamento sugli strumenti di analisi statica e mirano a dedicare più tempo ad estendere gli strumenti che alla codifica per problemi specifici per clienti specifici. Quindi concludiamo che è più probabile che gli addetti alla sicurezza delle app scrivano strumenti per leggere il codice piuttosto che per leggere il codice.
** Avvertenza: ciò che rimane è l'opinione personale e la speculazione **
La realtà è rotta. Noterai che la teoria della sicurezza del software riguardava l'identificazione e la risposta al rischio di fare affidamento su un sistema software, mentre la pratica consisteva nel trovare il maggior numero possibile di bug. Certo, ciò ridurrà comunque il rischio, ma solo come effetto collaterale. Il punto del gioco è diventato meno importante della "vincita" del gioco, quindi le regole sono cambiate per rendere più facile vincere.
Cosa puoi fare come sviluppatore di software al riguardo? Gioca secondo le sue regole originali. Trova qualcuno nella tua squadra (preferibilmente in realtà nella tua squadra, piuttosto che un appaltatore, in modo che siano motivati a fornire risultati a lungo termine piuttosto che una rapida vittoria) che capisca l'importanza della sicurezza e formi il bejeezus da loro. Dare a quella persona la responsabilità di dirigere il team nel fornire la sicurezza end-to-end descritta all'inizio della mia risposta.
Inoltre, dai a quella persona l'autorità di seguire . Se un progetto non esprime i requisiti di sicurezza, deve essere rivisto. Se l'implementazione non soddisfa i requisiti di sicurezza, non deve essere rilasciata . La persona di sicurezza può effettuare la sentenza, ma deve essere autorizzata ad agire in base a tale sentenza. Mi rendo conto che potrebbe sembrare il ragazzo della sicurezza che dice "La sicurezza OMFG è la cosa più importante", ma non è quello che intendo. Se il tuo prodotto non soddisfa nemmeno i requisiti di funzionalità, usabilità o prestazioni, non dovresti rilasciare quella cosa.
Perché vorresti farlo? Dovrebbe essere più economico: abbiamo visto tutti (e probabilmente quotato per un +10 rep economico) la tabella Codice completo dove i difetti diventano più costosi dopo che li hai risolti, giusto? Anche i difetti di sicurezza sono difetti. Sono le regole del gioco del mondo reale, la maggior parte di esse sono problemi nei requisiti fissi nella manutenzione. È economico?
Ok, ora che cosa posso io come una pistola di sicurezza per il noleggio fare a tale proposito? Bene, risulta che posso anche rifiutarmi di giocare secondo le regole modificate. Posso dire agli sviluppatori che si tratta di ridurre il rischio, che ciò può essere fatto in ogni fase e quindi posso aiutarli a farlo.