Oh, sí, literalmente, acabo de leer un informe lleno de falsos positivos (saqué un ticket legítimo de un informe DAST de 20 páginas). Y con eso quiero decir que, como en el ejemplo de @BrianWilliams, la herramienta es correcta para informarlos porque pueden ser reales en algunos escenarios, pero se necesita un analista experto para decidir si se aplica o no en este escenario. Algunos ejemplos que vi en la última hora:
-
Por defecto umask demasiado ancho . Mi análisis: irrelevante porque este es un dispositivo IoT donde la aplicación se ejecuta como root de todos modos.
-
X-Frame ClickJacking no está establecida . Mi análisis: irrelevante porque está en páginas web estáticas, no interactivas.
-
Falta la protección CSRF . Mi análisis: incorrecto, una vez que hayas iniciado sesión, el token de autenticación (sin cookie) cuenta, pero la herramienta está buscando a ciegas un encabezado llamado "CSRF".
-
TLS 1.0 está habilitado . Mi análisis: Sí, lo necesitamos por compatibilidad.
-
Partición montada con opciones débiles Mi análisis: irrelevante porque si puedes entrar en el dispositivo para infectar la partición, entonces ya estás dentro del dispositivo ...
Sí, podríamos (y probablemente deberíamos) corregirlos para que sean menos descuidados, pero no son explotables en esta aplicación, por lo que ya no es un problema de seguridad y se acumulan con otras tareas técnicas de limpieza de deuda / código.
A tu pregunta:
¿DAST necesita el mismo tiempo y esfuerzo del desarrollador y analista de seguridad para filtrar falsos positivos?
¡Quieres que los desarrolladores formen parte del proceso para que mejoren constantemente sus habilidades de seguridad y escriban códigos más seguros! La cantidad de participación depende de las habilidades del desarrollador.
Con algunos equipos necesito hacer el 100% del informe de triaje y abrir tickets para cosas específicas que necesitan ser cambiadas. Para otros equipos, hago triaciones con los desarrolladores, y para un equipo de desarrolladores veteranos, ellos realizan casi el 100% de los triaging y firmo su análisis antes de cada lanzamiento.
Para mí, un analista de seguridad que exige ciegamente que todo en un informe SAST / DAST sea reparado es perezoso o no comprende las tecnologías que se supone que deben proteger.
Parece que necesita poner un poco más de esfuerzo en su proceso de triaje y, como analista de seguridad, profundice un poco más para comprender qué es cada una de las vulnerabilidades informadas a punto de decidir si realmente necesita ser reparada (lo que tendrá el efecto secundario de expandir tus propias habilidades).
Parafraseando a la gran Tanya Janca :
"La forma más fácil de crear hostilidad entre los equipos de desarrollo y de seguridad es lanzar informes automáticos a ciegas a los desarrolladores y decir: ¡SOLICITUD!" - Tanya Janca