Pruebas dinámicas de seguridad de aplicaciones (DAST)

Una herramienta DAST no necesita conocer detalles de tu aplicación, como el lenguaje de programación que se usó para desarrollarla. Así puedes mejorar la seguridad de tu aplicación incluso si usas lenguajes de programación poco comunes.

¿En qué se diferencia DAST de otros métodos de pruebas de seguridad?

Para determinar si un método de pruebas de seguridad es adecuado para el entorno de pruebas de tu aplicación, es importante considerar tanto lo que ofrece como sus limitaciones. Veamos las diferencias entre estos métodos de prueba.

SAST vs DAST vs SCA

Las pruebas estáticas de seguridad de aplicaciones (SAST) se enfocan en el código. Se realizan al inicio del pipeline de CI y analizan el código fuente, el bytecode o el código binario para identificar patrones de codificación problemáticos que incumplen las prácticas recomendadas. SAST depende del lenguaje de programación.

Las pruebas dinámicas de seguridad de aplicaciones (DAST) son un método de pruebas de caja negra que analiza las aplicaciones durante la ejecución. Se aplican más adelante en el pipeline de CI. DAST es una buena opción para prevenir regresiones y no depende de un lenguaje de programación específico.

Las pruebas interactivas de seguridad de aplicaciones (IAST) son similares a DAST porque se enfocan en el comportamiento de la aplicación durante la ejecución. Sin embargo, el análisis IAST se basa en una combinación de pruebas de caja negra, análisis y evaluación de los flujos internos de la aplicación. La ventaja de IAST es que puede vincular hallazgos similares a los de DAST con el código fuente, como SAST. La desventaja es que IAST depende del lenguaje de programación y solo puede realizarse más adelante en el pipeline de CI.

Análisis de composición de software (SCA) se enfoca en las dependencias de código de terceros que se usan en la aplicación. El análisis de composición de software es muy eficaz en las aplicaciones que usan muchas bibliotecas de código abierto. Este método también depende del lenguaje de programación.

Lee más sobre SAST vs. DAST: cuáles son las diferencias y cómo combinar ambos métodos.

¿Cómo se complementa DAST con otros métodos de pruebas de seguridad de aplicaciones?

DAST se complementa mejor con métodos de pruebas de seguridad de aplicaciones que se basan en comprobaciones estáticas, como SAST y SCA, ya que aporta información adicional sobre el tiempo de ejecución al análisis estático del código fuente.

A menudo, las herramientas SAST solo analizan fragmentos de código individuales y no tienen en cuenta su contexto. El código de un archivo puede parecer problemático, aunque el código de otro archivo que lo usa se encargue de resolver todos los problemas. Incluso es posible que las medidas de seguridad que implementaste en tu sistema se ejecuten en otra computadora. Por ejemplo, una herramienta SAST identificaría una entrada que no se desinfectó como un problema, porque no puede relacionarla con la desinfección que se realiza en el servidor justo antes de usar los datos.

Las herramientas DAST adoptan un enfoque de pruebas de extremo a extremo. No saben si el código del cliente sigue las prácticas recomendadas para desinfectar entradas. Las herramientas DAST analizan las entradas y salidas de tu aplicación; si la salida está desinfectada, no importa en qué parte de tu arquitectura se realizó la desinfección.

Sin embargo, las partes de tu aplicación que solo fallan en casos extremos pueden pasar desapercibidas para una herramienta DAST, ya que esta solo cubre casos de uso específicos, no entradas teóricas. Aquí es donde entran en juego las herramientas SAST y SCA. Estas herramientas analizan el código fuente y detectan comportamientos problemáticos que podrían pasar desapercibidos si solo usaras una herramienta DAST.

Por ejemplo, una conversión de tipos a veces puede fallar o generar resultados no deseados. Un caso de prueba DAST que solo cubra 10 entradas podría indicar que todo está bien, pero una herramienta SAST detectaría que un método de conversión puede fallar con valores específicos que ni siquiera habías considerado al desarrollar tu aplicación.

Ventajas y desventajas de DAST

La función principal de las herramientas DAST es probar una aplicación durante la ejecución. Esto ofrece varias ventajas, pero también tiene sus desventajas. Analicémoslas más a fondo para ayudarte a determinar si DAST es adecuado para tu proyecto de software.

Ventajas:

• Menos falsos positivos: Como no analiza toda la aplicación, DAST suele generar menos falsos positivos que SAST. Esto te permite verificar mucho más rápido si una vulnerabilidad es real y determinar si se puede prevenir más adelante.

• Independiente del lenguaje: DAST es el único método de pruebas de seguridad que no depende de un lenguaje de programación específico. DAST no analiza el código fuente, el bytecode ni el código ensamblador; solo verifica las entradas y salidas de tu sistema. Si tu aplicación está desarrollada con un lenguaje de programación poco común, DAST podría ser tu única opción.

• Repetición rápida de pruebas para vulnerabilidades corregidas: DAST ayuda a controlar las regresiones. Si se encuentra y reproduce una vulnerabilidad de seguridad, puedes automatizar esa reproducción y agregarla al conjunto de pruebas DAST. Así, cada versión posterior incluirá las interacciones que provocaron problemas en el pasado. Si esos problemas vuelven a aparecer, DAST los detectará antes del lanzamiento.

Desventajas:

• No ofrece información sobre el código: DAST solo analiza las entradas y salidas de tu sistema. Por eso, no es posible relacionar las vulnerabilidades detectadas con líneas de código.

• Proceso de pruebas más lento: Tener que ejecutar y usar el software puede ralentizar el proceso de pruebas, incluso con métodos automatizados. Recorrer un proceso de registro con varias combinaciones de entradas simplemente toma tiempo.

• Resultados tardíos en el pipeline de CI/CD: DAST se ubica en la etapa final del pipeline de CI/CD, ya que las herramientas DAST necesitan que la aplicación se ejecute para hacer su trabajo. Esto puede consumir bastante tiempo, especialmente si tu aplicación ha crecido con el tiempo.

• Es posible que se requieran pruebas manuales: Si por algún motivo no puedes automatizar la ejecución y el uso de tu aplicación, tendrás que sacar la prueba DAST del pipeline de CI/CD por completo y probar la aplicación manualmente en cada versión.

Cómo implementar DAST correctamente

Como DAST depende de la ejecución de tu aplicación, agregarlo a tu pipeline de pruebas no es tan sencillo como agregar SAST. Aunque es posible automatizar DAST, primero hay que escribir un script o grabar las acciones que se automatizarán. Después de agregar una herramienta DAST al pipeline, tendrás que seguir un proceso.

1. Reúnete con tus usuarios

Un buen punto de partida para implementar DAST es reunirte con tus usuarios y documentar cómo usan tu aplicación. Además de registrar lo que hacen, pídeles que expliquen sus acciones.

Los usuarios suelen olvidar en qué hacen clic en una aplicación: las interacciones frecuentes se vuelven subconscientes. Aunque esto les permite concentrarse en sus tareas, el hecho de que no piensen en algo que hicieron clic no significa que no pueda causar un problema.

2. Automatiza las interacciones de los usuarios

El siguiente paso es usar una herramienta de automatización para crear un script con las acciones de los usuarios. Puede ser más sencillo hacerlo con aplicaciones de CLI y API que con una interfaz gráfica, pero, en general, es posible automatizar todos estos tipos de aplicaciones.

3. Agrega los scripts de prueba a tu pipeline de CI/CD

Cuando hayas cubierto con interacciones automatizadas los casos de uso más importantes, puedes ejecutar estos scripts en tu aplicación mientras una herramienta DAST la analiza. Después de la primera ejecución de DAST, puedes empezar a corregir las vulnerabilidades de seguridad.

4. Agrega pruebas de regresión al conjunto de pruebas

Si encuentras vulnerabilidades de seguridad durante el uso diario de tu aplicación, puedes agregar scripts para esos casos de uso específicos al conjunto de pruebas. Así te aseguras de que los problemas no vuelvan a aparecer.

Resumen

Aunque DAST es un método confiable para detectar vulnerabilidades, no podrás cubrir todos los frentes si lo usas por sí solo. Sin embargo, a veces es la única solución disponible, por ejemplo, si usas un lenguaje de programación poco común para desarrollar tu aplicación o paquetes o extensiones de código cerrado para un lenguaje de programación común.

Ejecutar una herramienta DAST puede tomar bastante tiempo, especialmente cuando hay interacciones complejas. Y si no puedes automatizar esas interacciones, tendrás que realizarlas manualmente antes de cada versión, lo que podría tomar días o incluso semanas.

Al comparar SAST y DAST, SAST puede parecer la mejor opción en general, ya que se puede usar antes en el proceso de desarrollo, cuando es más fácil y económico corregir los problemas de seguridad detectados. Sin embargo, las herramientas DAST ofrecen grandes ventajas.