È abbastanza semplice tenere traccia quando si risolvono le vulnerabilità della sicurezza nel codice esistente. Ma per essere sicuri che tutto il team stia cercando di scrivere codice sicuro, vorrei anche tenere traccia di quanto stiamo evitando ed evitando di scrivere nuove vulnerabilità di sicurezza. Qual è il modo giusto per misurarlo?
Non puoi mai essere sicuro al 100% delle vulnerabilità della sicurezza, ma un buon approccio è controllare quanto del tuo codice è stato rivisto da un peer, perché entrambi gli sviluppatori devono esaminarlo e cercare problemi di sicurezza. Stiamo usando Crucible (uno strumento di Atlassian) per farlo e ogni commit è revisionato.
A seconda del tuo linguaggio di programmazione ci sono anche alcuni strumenti che usano gli algoritmi per cercare le tipiche vulnerabilità nel tuo codice o persino un crawler che controlla il tuo programma o sito web in un approccio blackbox.
Ancora una volta, non si tratta di garantire la sicurezza al 100%, ma è un modo per provare almeno a misurare i miglioramenti.
Sfortunatamente non c'è risposta. Come notato nei commenti, "Come fai a sapere se il tuo repellente per elefanti si è consumato?"
Detto questo, se vuoi segnalare una metrica in qualche modo informativa, investi in uno strumento di analisi del codice statico (Fortify, Veracode, Checkmarx) e vedi quanti problemi si presentano. Tali strumenti richiedono la messa a punto per trovare solo i problemi che ti interessano.
Uno strumento di analisi statica non catturerà i difetti di sicurezza nella logica o nella progettazione.
Puoi iniziare selezionando la OWASP ASVS lista di controllo per verificare che stai coprendo tutte le tue basi quando si tratta di sforzi di sicurezza. Per soddisfare i requisiti di ASVS è necessario un qualche tipo di controllo attivo del codice per cercare problemi di sicurezza.
Ci sono diversi approcci che puoi adottare:
Esempi di strumenti di analisi statici includono HP Fortify, Coverity, IBM AppScan. Sappiate che qui c'è un sacco di vendite di olio di serpente, perché questi strumenti sono strongmente ipervenduti (sia in termini di prezzo che di capacità). Nel codice su cui ho lavorato, abbiamo finito per sviluppare il nostro tool con una serie di regex per verificare la base di codice durante ogni build per cose come variabili erroneamente citate inserite in istruzioni SQL, perché era più economico e più efficace. Gli strumenti più generici, come Sonar , possono essere riutilizzati nell'attività, quindi considera quelli come bene.
Esistono anche strumenti di analisi dinamica che eseguono la scansione di un'applicazione in esecuzione, come Zed Attack Proxy e sqlmap . Questi strumenti sono ciò che un hacker reale userebbe per scansionare la tua applicazione alla ricerca di vulnerabilità, in modo che possa ripagare per usarlo per controllare il tuo lavoro.
Stai provando a testare un risultato negativo, cioè stai verificando che qualcosa sia assente. Il problema è che è come provare l'assenza del mostro di Loch Ness: il loch è profondo, non puoi controllarlo tutto e certamente non puoi controllare tutto in una volta. Non puoi mai essere sicuro se non ci sia, o se ti sia sfuggito.
La tua migliore scommessa è di lanciare il tuo test e cercare i lati positivi. Ottieni un software di scansione delle vulnerabilità e verifica la presenza di buchi nella tua applicazione, controllando il codice per cose brutte come le variabili senza escape vulnerabili all'iniezione e eseguendo la scansione dell'applicazione mentre è in esecuzione per cercare vulnerabilità agli exploit noti. Se il tuo budget può allungare abbastanza, assumere alcuni tester di penetrazione - o reclutare qualcuno per lavorare in casa - e fargli fare sondaggi intorno al tuo software per cercare un modo. Lo scopo di tutto questo è trasformare il tuo negativo "in cerca di qualcosa che non c'è "in positivo" abbiamo trovato la vulnerabilità questa ; Se non trovano nulla ... beh, non puoi mai essere completamente sicuro, ma almeno hai un elenco di cose che hai controllato, in modo che quando qualcuno trova inevitabilmente un exploit zero-day in qualcosa che sei usando, puoi almeno mostrare (al tuo capo, al tuo cliente o chiunque altro cerchi di puntare le dita) che sei stato diligente e hai fatto tutto ciò che ci si poteva aspettare per assicurarti che l'applicazione fosse sicura.
Leggi altre domande sui tag code-quality security metrics