Credo che questa domanda sia meglio affrontata nel capitolo 4 di The Art of Software Security Assessment , un libro di Mark Dowd, Justin Schuh e John McDonald.
Senza di esso come riferimento, posso tranquillamente dirti che il metodo migliore è usare i dati di runtime insieme al codice sorgente mentre si determinano i "colpi" (o tracce, copertura aka) usando il test black-box - ma solo dopo un Il modello di minaccia e l'architettura generale del sistema sono ben noti.
Gli autori sembrano anche gradire l'analisi sicura del codice statico quando combinati con le strategie del punto di vista, anche se è mia opinione che questi possano variare selvaggiamente assumendo che le seguenti non siano vere:
- La lingua e le sue librerie di classi di base devono essere supportate dallo strumento di analisi statica sicura
- L'intero sistema deve essere solitamente disponibile. Cioè deve includere codice sorgente compilabile che includa tutti i componenti di terze parti / contrib e librerie esterne, possibilmente anche per includere il compilatore di sistema, la VM o altri artefatti del sistema originale
- Tutte le componenti / librerie esterne che non fanno parte delle librerie della classe base devono avere origini e sink definiti nel database source-sink-passthru dello strumento di analisi statica sicura. Le complessità di alcuni passthrus (cioè i filtri) possono variare a seconda dell'implementazione o dell'implementatore e quindi richiedono quasi sempre una configurazione personalizzata
- L'uso aggiuntivo di determinati modelli o elementi di codice architettonico potrebbe causare altre variazioni, che potrebbero richiedere una personalizzazione che non è possibile con la maggior parte dei moderni strumenti di analisi statica sicura
Per le ragioni di cui sopra, così come i motivi esposti negli studi NIST SATE (fatti da NIST SAMATE), trovo difficile raccomandare molti strumenti di analisi statica sicura da usare nell'analisi della scatola bianca. È quasi sempre semplicemente meglio usare le strategie di comprensione del codice che molto probabilmente implicano la lettura del codice sorgente dall'alto verso il basso, che è davvero molto importante se si cercano i rootkit di codice gestito e simili.
Invece di testare e audire / valutare le applicazioni, adotterei un approccio diverso che è in gran parte molto indipendente dalla tecnologia. Il mio suggerimento sarebbe quello di implementare un portale di gestione dei rischi per la sicurezza delle applicazioni che includa un inventario di app insieme ai controlli di sicurezza delle applicazioni attualmente implementati. Dopo una previsione iniziale, i controlli di sicurezza delle applicazioni devono essere valutati rispetto agli standard del settore come MITER CWE, SAFEcode e OWASP ASVS. Un'analisi delle lacune (si noti che si tratta di un termine di gestione del rischio standard e funziona meglio se implementata in un programma di gestione della sicurezza delle informazioni basato su ISO 27001 o simile) può quindi essere utilizzata per determinare i controlli di sicurezza delle applicazioni ottimali, nonché un percorso per ottenere dai controlli attualmente implementati a quelli richiesti.
È necessario implementare questo portale di gestione dei rischi prima di eseguire attività di valutazione del rischio come test white-box o black-box per ottenere risultati migliori e misurare il successo del programma.