X
BLOG

SAST vs DAST: cómo usarlos juntos, no por separado

SAST vs DAST: cómo usarlos juntos, no por separado Tiempo de leer: 6 minutos
Al comparar SAST vs DAST, los desarrolladores a menudo dicen que se complementan entre sí, pero luego simplemente recomiendan usar ambos, lo que no es necesariamente complementario, sino que simplemente hace dos cosas diferentes. Pero tu enlatado combine SAST y DAST para AppSec de manera complementaria, maximizando el valor de SAST para su negocio al aprovechar DAST.

El potencial de una sinergia real entre SAST y DAST proviene de que sus herramientas SAST y DAST se apoyan entre sí de una manera que realmente conduce al corazón de la metodología de seguridad de aplicaciones Secure-by-Design. Por lo tanto, no es realmente SAST vs DAST, sino más bien SAST informado por DAST. ¿Como funciona esto?

Comencemos con los conceptos básicos de estas dos metodologías de prueba de seguridad de aplicaciones.

¿Qué es SAST?

SAST es Pruebas de seguridad de aplicaciones estáticas, es decir, analizar una aplicación sin ejecutarla. Hay una variedad de formas de hacer esto, desde la revisión humana hasta el análisis de métricas, el análisis de patrones y el análisis del flujo de datos. Esto se considera una prueba de caja blanca. Por lo general, los usuarios de SAST se preocupan por el análisis del flujo de datos porque les permite buscar fallas de seguridad, como datos contaminados, antes de que se complete la aplicación.

En los primeros días del análisis estático, se hacía mucho énfasis no solo en encontrar errores, sino también en encontrar construcciones de código sospechosas o riesgosas (ver Meyer's C ++ eficaz) así como el cumplimiento de los estándares de ingeniería de software. En el mundo de la seguridad, SAST se ha convertido principalmente en análisis de flujo. Básicamente, SAST se está utilizando para encontrar vulnerabilidades, similar a DAST, pero anteriormente en SDLC.

Ventajas de SAST

Las pruebas anteriores son mejores porque cuesta mucho menos, por lo que la principal ventaja de SAST es que se puede hacer antes, mucho antes de que la aplicación completa o el sistema estén listos. Con SAST, tiene un conocimiento interno profundo del código, por lo que sabe exactamente qué código está involucrado con un problema.

Desventajas de SAST

En el lado negativo, con SAST, sus pruebas no son contra un sistema real, y las herramientas deben sintetizar datos para intentar impulsar la cobertura de una función o ruta de datos. Debido a esto, las herramientas SAST tienen el riesgo de devolver un informe falso positivo, lo que significa que enlatado  decirle que un fragmento de código tiene una vulnerabilidad cuando en realidad es seguro. Además, las herramientas SAST suelen ser específicas de un idioma en particular. Esto hace que su construcción y mantenimiento sean costosos para las organizaciones (principalmente un problema para los proveedores de herramientas) y significa que necesita herramientas para cada idioma utilizado en sus aplicaciones.

¿Qué es DAST?

DAST es Pruebas de seguridad de aplicaciones dinámicas. Esto significa probar una aplicación (o dispositivo) que funcione, generalmente a través de sus entradas e interfaces. A menudo, se trata de pruebas de caja negra, en el sentido de que está utilizando la aplicación sin examinar en profundidad sus aspectos internos (código fuente).

Ventajas de DAST

La mayor ventaja de DAST es que obviamente se trata de pruebas realistas que tienen en cuenta la aplicación completa y / o el sistema de principio a fin. En segundo lugar, las pruebas DAST no dependen de un conocimiento profundo del código y las herramientas no requieren soporte específico para cada idioma.

Desventajas de DAST

La gran desventaja de DAST, por otro lado, es que no incluye un conocimiento profundo de su código. Esto significa que cuando encuentra un problema, puede llevar algo de tiempo y esfuerzo determinar exactamente qué código subyacente está causando el problema.

Además, DAST es una tecnología de "prueba", lo que significa que ocurre después del diseño y la codificación. Por lo tanto, es una muy buena manera de verificar que una aplicación es segura, pero si es la forma principal que se usa para proteger el software, entonces realmente está tratando de probar la seguridad en su aplicación, lo cual es una tarea sísifo. No puede probar la seguridad en una aplicación más de lo que puede probar la calidad en una aplicación; es por eso que nuevas regulaciones como LGPD y las próximas directrices de la FDA se basan en la metodología Security-by-Design.

Complementar DAST con SAST

Ahora que conoce la diferencia entre DAST y SAST, y algunos de sus pros y contras, es hora de ver cómo puede hacer que funcionen juntos. Pero, ¿por qué querrías hacer esto en primer lugar?

Tener una estrategia SAST sólida que incorpore verificadores de detección temprana para debilidades como CWE así como estándares de codificación segura como CERT es la forma más completa de asegurar una aplicación y dejar de tener los mismos problemas de seguridad una y otra vez. Pero para complementar DAST, podemos conectar SAST con lo que está haciendo DAST, informando nuestras actividades de SAST con la información obtenida de DAST.

Para comprender mejor cómo funciona, me gusta pensar en el software como una línea de montaje y comenzar desde el final de la línea, utilizando un proceso de mejora de 3 pasos para la seguridad. La Fase 1 es mejor que nada, pero no es tan buena como la Fase 3.

Pruebas de seguridad antes del lanzamiento (Fase 1)

La primera fase de la seguridad de la aplicación es DAST. Para la seguridad de la aplicación, tomamos la aplicación final, la compilamos antes del lanzamiento y la atacamos, tratando de entrar en ella de cualquier manera que podamos; esto es DAST. Si encontramos algo, evaluamos qué tan desagradable es y lo arreglamos cuando podemos, soltándolo cuando debemos. Hay un gran tema en sí mismo en torno a este problema (lanzamiento de software con debilidades y vulnerabilidades conocidas), pero lo dejaré para otro día.

Debido a que esta prueba llega al final, siempre hay presión de tiempo, así como una dificultad adicional para encontrar y remediar el problema subyacente, pero definitivamente es mejor hacer esta prueba que no hacerlo en absoluto, por lo que es un buen comienzo.

Detección temprana: cambio de seguridad a la izquierda (Fase 2)

La segunda fase del viaje hacia la mejora de la seguridad de las aplicaciones agrega SAST, para abordar ese problema tardío del ciclo. ¿Cómo podemos comenzar las pruebas de seguridad antes de que la aplicación esté lista? SAST es nuestra respuesta obvia. Los verificadores SAST pueden ejecutarse tan pronto como tengamos el código. Los verificadores de flujo de datos en SAST generalmente se pueden correlacionar directamente con los tipos de problemas que encuentra DAST, por lo que es fácil saber qué buscar y qué significa cuando SAST encuentra una debilidad.

Este es un buen siguiente paso, porque no solo tenemos más tiempo para remediar, sino que también las pruebas están más cerca de la fuente, por lo que el tiempo que lleva descubrir qué salió mal es mucho más corto. Nuestro SAST ahora está tomando el trabajo de nuestro DAST y lo está haciendo antes.

Prevención: adelantarse a la curva (Fase 3)

El flujo de datos realmente solo está haciendo más pruebas de seguridad, entonces, ¿cómo llegamos al siguiente nivel y combinamos SAST con DAST para complementarnos entre sí? La tercera fase es donde realmente nos damos cuenta del valor de usar ambas herramientas juntas.

Para pasar de SAST vs DAST a una situación completamente complementaria, podemos tomar la resultados desde DAST hasta informar nuestro SAST, ajustando nuestras configuraciones de reglas de análisis estático y diciéndonos qué tipo de debilidades de seguridad debemos buscar. Al usar DAST de esta manera, puede permitir que SAST nos diga todo lo que necesitamos sobre de dónde provienen las vulnerabilidades de seguridad, cómo podemos mitigarlas y cómo podemos codificar de tal manera que no sucedan.

Entonces, ¿cómo funciona esto? Primero, necesitamos realizar un análisis de la causa raíz utilizando los resultados de DAST. Por ejemplo, con la inyección de SQL, debemos asegurarnos de que los datos se desinfecten a medida que ingresan, para no tener que depender de la búsqueda de datos a través de innumerables rutas para ver si pueden escapar de la limpieza. También debemos observar los estándares SAST como los de CERT para que ambos podamos evitar construcciones que podrían funcionar pero que no son seguras, así como imponer buenos comportamientos que endurecerán nuestra aplicación, aunque no sean necesarios en la programación normal (insegura). Las reglas de SAST adecuadas evitan los problemas encontrados con DAST, y seguimos aprendiendo de DAST sobre cómo configurar y ajustar nuestro SAST.

Benefíciese de un enfoque a prueba de fallos

Al usar SAST y DAST juntos, terminas con lo que me gusta pensar que es una mentalidad a prueba de fallas. Por ejemplo, sin seguro por diseño, antes LGPD, almacenamos todos los datos de los usuarios sin cifrarlos y luego discutimos sobre qué datos en particular merecen protección adicional, como contraseñas o números de seguridad social. En un entorno seguro por diseño y a prueba de fallas, tomamos el enfoque opuesto y encriptamos todo, luego discutimos qué es seguro no encriptar. De esa manera, el comportamiento predeterminado es seguro o "a prueba de fallas", y está maximizando exitosamente su SAST y DAST.

¡Así que ten cuidado! Los verificadores SAST que realizan pruebas similares a DAST son los que captan el interés de los usuarios y analistas, pero el mayor valor proviene de los aburridos verificadores basados ​​en estándares que imponen un comportamiento seguro adecuado. Estos verificadores lo llevan de las pruebas tardías a la detección temprana y hasta los estándares de codificación preventiva reales que fortalecen su aplicación. SAST enlatado  complementa DAST al proporcionar una mitigación temprana y permitir que DAST se utilice principalmente para verificar que la aplicación sea segura, en lugar de intentar romper la aplicación.

Incorpore seguridad a su aplicación desde el principio

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft