Es una buena idea querer abordar este problema con la automatización. Sin embargo, la lista de OWASP en sí misma no es una lista de vulnerabilidades, donde una vulnerabilidad es una versión mala conocida de software de lanzamiento público o una configuración mala conocida que se puede analizar, identificar y rectificar.
En cambio, es una lista de lo que OWASP denomina risk , que son clases de fallas de seguridad que han llevado a un compromiso y pérdida. En otras palabras, cada elemento OWASP es una abstracción de nivel superior, no una vulnerabilidad individual e identificable.
Además, muchas de las vulnerabilidades que pueden clasificarse bajo uno u otro riesgo de OWASP son, en sí mismas, abstractas y no necesariamente fáciles de analizar.
Por ejemplo, hay patrones de código que se recomiendan para ayudar a prevenir la inyección SQL (una clase de vulnerabilidad bajo el riesgo de inyección, el riesgo número 1 ahora por muchos años), como las declaraciones preparadas. Sin embargo, no todo el código de la aplicación que no usa declaraciones preparadas es vulnerable a la Inyección de SQL.
Desde una perspectiva de automatización, las herramientas de escaneo de código fuente conocidas como "analizadores estáticos" se especializan en encontrar patrones de código subóptimos, subóptimos tanto desde una perspectiva de seguridad como desde una perspectiva de deuda idiomática / técnica. En mi experiencia, requieren una enorme inversión en configuración y, a menudo, solo producen resultados apenas utilizables.
La automatización permanente para el análisis de seguridad de la aplicación en su conjunto no es un problema resuelto, solo depende de la disponibilidad de recursos legibles por la máquina. Todavía estamos en la etapa de seguridad de las aplicaciones en la que se combinan piedras para armar fuego al azar.
Quizás el riesgo más automatizable es el riesgo # 9, que utiliza componentes con vulnerabilidades conocidas. Ahora, cada plataforma lingüística tiene herramientas para verificar las versiones de las bibliotecas en uso en una base de código particular contra una lista de bibliotecas marcadas por tener vulnerabilidades conocidas. Lo que es genial.
Sin embargo, un enorme respeto para las personas con exceso de trabajo que sin recompensa o fama trabajan en estas áreas, estas últimas listas no son exhaustivas, exhaustivas ni definitivas. Que una biblioteca en particular no tenga una vulnerabilidad asociada no significa que no exista una. Más a menudo significa que existen vulnerabilidades, pero simplemente no se han encontrado a) ni b) se han notificado.
En general, es una situación bastante mala, y nuevamente, ese riesgo en particular es probablemente donde el estado actual de automatización es más fuerte.
Para cerrar en una nota esperanzadora, hay una serie de proyectos prometedores. Una de las que mantengo mis ojos es Grafeas de Google:
enlace
Su objetivo es apoyar la promulgación de artefactos de metadatos de lectura mecánica, a partir de los cuales se puede construir un canal de seguridad de la aplicación. No está listo para la producción, pero está progresando.