Troy,
He visto tu trabajo, incluida la integración de Netsparker con TeamCity. Comenté y mencioné que Burp Suite Professional en modo sin cabeza puede ser más apropiado, pero las pruebas totalmente automatizadas de esta manera solo encuentran algunos de los errores. Es un problema clásico de automatización de pruebas.
Sin embargo, si tiene solicitudes HTTP conocidas que producen una respuesta HTTP no deseada (es decir, vulnerable), puede usar la función de solicitud de exportación de W3AF, disponible en la parte inferior derecha de Results- > KB Browser- > [ Elemento específico de la base de conocimientos desplegable] - > Solicitud- > [Botones en la parte inferior]. Esto abrirá una nueva ventana donde las solicitudes HTTP se pueden convertir en casos de prueba. Los casos de prueba están disponibles en HTML, Ajax, Python y Ruby.
Dependiendo de su entorno de servidor de compilación, puede variar la forma de integrar estos scripts. HtmlFixture, disponible en FitNesse, sería un buen candidato para los scripts de solicitud HTML o Ajax. Bajo Python, tal vez Nose sería adecuado; Ruby tiene pepino.
El libro, "Security on Rails" tiene capítulos completos dedicados a este tema, y separa las pruebas lógicamente en unidades, funcional, integración y navegador.
El Proyecto O2 de OWASP tiene opciones de menú en "Desarrollo de API / Script" para ejecutar y escribir pruebas unitarias. Estas pruebas de unidad están escritas en WatiN, pero gran parte del trabajo ya se ha realizado para el desarrollador de la prueba.
Si quieres desarrollar algo muy poderoso por tu cuenta, te sugiero que mires Geb , que combina la conducción del navegador. las características de WebDriver (y, por lo tanto, pueden trabajar con Internet Explorer, FireFox, Chrome y HTMLUnit) con una API de inspección / inspección de contenido inspirada en jQuery y la expresividad de Groovy .