È una buona idea voler affrontare questo problema con l'automazione. L'elenco OWASP stesso, tuttavia, non è un elenco di vulnerabilità, in cui una vulnerabilità è una versione nota del software rilasciato pubblicamente o una configurazione errata nota che può essere scansionata, identificata e rettificata.
Invece, è un elenco di ciò che OWASP chiama rischi , che sono classi di errori di sicurezza che hanno portato a compromessi e perdite. In altre parole, ogni elemento OWASP è un'astrazione di livello superiore, non una vulnerabilità individuale identificabile.
Inoltre, molte delle vulnerabilità che possono essere classificate sotto l'uno o l'altro rischio OWASP sono esse stesse astratte e non necessariamente facili da cercare.
Per esempio, ci sono schemi di codice che sono consigliati per aiutare a prevenire SQL Injection (una classe di vulnerabilità sotto il rischio di Injection, il rischio numero 1 per molti anni) - come, usa istruzioni preparate. Tuttavia, non tutto il codice dell'applicazione che non utilizza le istruzioni preparate è vulnerabile a SQL Injection.
Da un punto di vista dell'automazione, gli strumenti di scansione del codice sorgente noti come "analizzatori statici" sono specializzati nella ricerca di modelli di codice subottimali non ottimali sia dal punto di vista della sicurezza che dal punto di vista del debito idiomatico / tecnologico. Nella mia esperienza, richiedono un enorme investimento di configurazione e spesso producono solo risultati appena utilizzabili.
L'automazione in piedi per l'analisi della sicurezza delle applicazioni nel suo complesso non è un problema risolto, dipende solo dalla disponibilità di risorse leggibili dalla macchina. Siamo ancora nella fase della sicurezza delle applicazioni, a colpi di martello, insieme, a casaccio.
Forse il rischio più automatico è il rischio n. 9, che utilizza componenti con vulnerabilità note. Ogni piattaforma linguistica ora dispone di strumenti per verificare le versioni delle librerie in uso in un determinato codebase rispetto a un elenco di librerie contrassegnate per avere vulnerabilità note. Che è fantastico.
Tuttavia - enorme rispetto per la gente stressata che senza ricompensa o fama faticano in queste aree - questi ultimi elenchi non sono esaustivi, completi o definitivi. Che una libreria particolare non abbia una vulnerabilità associata con essa non significa che non esista. Più spesso significa che esistono vulnerabilità ma non sono state a) trovate o b) segnalate.
Nel complesso, si tratta di uno stato di cose piuttosto scadente e, ancora una volta, il rischio particolare è probabilmente il caso in cui lo stato attuale dell'automazione è il più strong.
Per chiudere una nota di speranza, ci sono una serie di progetti promettenti. Uno che tengo d'occhio è Grafeas di Google:
link
Il suo obiettivo è supportare la diffusione di artefatti di metadati leggibili dalla macchina, dai quali è possibile costruire una pipeline di sicurezza delle applicazioni. Non è vicino alla produzione pronta, ma sta progredendo.