Troy,
Ho visto il tuo lavoro, inclusa l'integrazione di Netsparker con TeamCity. Ho commentato e menzionato che Burp Suite Professional in modalità headless potrebbe essere più appropriato, ma i test completamente automatizzati in questo modo trovano solo alcuni dei bug. È un classico problema di automazione del test.
Tuttavia, se si hanno richieste HTTP note che producono una risposta HTTP non desiderata (cioè vulnerabile), è possibile utilizzare la funzione di richiesta di esportazione di W3AF, disponibile in basso a destra nel browser Risultati- > KB- > [ Menu specifico della Knowledge Base in discesa] - > Richiedi- > [Pulsanti in basso]. Verrà aperta una nuova finestra in cui le richieste HTTP possono essere convertite in casi di test. I test case sono disponibili in HTML, Ajax, Python e Ruby.
A seconda dell'ambiente del server di compilazione, può variare il modo in cui integrare questi script. HtmlFixture, disponibile in FitNesse, sarebbe un buon candidato per gli script di richiesta HTML o Ajax. Sotto Python, forse il Naso sarebbe adatto; Ruby ha Cetriolo.
Il libro "Security on Rails" contiene interi capitoli dedicati a questo argomento e separa logicamente i test su unità, funzionalità, integrazione e browser.
Il Progetto O2 di OWASP ha opzioni di menu sotto "Sviluppo API / Script" per eseguire e scrivere test unitari. Questi test unitari sono scritti in WatiN, ma gran parte del lavoro è già stato fatto per lo sviluppatore del test.
Se vuoi sviluppare qualcosa di molto potente da solo, ti suggerisco di guardare Geb , che combina il browser alla guida caratteristiche di WebDriver (e quindi può funzionare con Internet Explorer, FireFox, Chrome e HTMLUnit) con una API di navigazione / ispezione dei contenuti ispirata a jQuery e l'espressività di Groovy .