¿Cómo difieren SAST, SCA y DAST?

Las aplicaciones son lo que hace que el mundo gire. ¿O no es ese el dicho? De cualquier modo, difícilmente pasa un día sin que utilicemos algún tipo de aplicación de software, por eso la seguridad de software es esencial. Cuando se demuestra que una aplicación es insegura, se desata el caos.

En este artículo del blog, definiremos los tres métodos más populares utilizados en las pruebas de seguridad de software: pruebas de seguridad de aplicaciones estáticas(SAST), análisis de composición de software (SCA) y pruebas de seguridad de aplicaciones dinámicas (DAST). Veremos sus diferencias y hablaremos de cómo se complementan. Asimismo, argumentamos que alcanzan su máximo potencial cuando se realizan mediante herramientas de pruebas de seguridad automatizadas y de forma manual por parte de personas expertas.

SAST y SCA aparecen asociados en búsquedas, posiblemente porque ambos se realizan mirando el contenido interno de la aplicación estática y no desde el exterior mientras la aplicación se está ejecutando. Además, DAST y SAST a menudo son enfrentados entre sí. La diferencia de nombres (es decir, "dinámicas", "estáticas") suele inspirar la pregunta "¿cuál es mejor?". Sin embargo, como intentaremos transmitir a lo largo de este post, estos métodos se realizan con intenciones diferentes. Por lo tanto, cualquiera de ellos no es necesariamente mejor que los otros dos. Echemos un vistazo a cada uno de ellos por separado para que se entienda mejor nuestra postura.

Las pruebas de seguridad de aplicaciones estáticas (SAST) son un tipo de pruebas caja blanca. Esto significa que los analistas de seguridad y las herramientas que realizan este método tienen acceso al código fuente, al código de bytes o a los binarios de la aplicación. Cuando se habla de una herramienta SAST, se hace referencia a un programa que encuentra automáticamente errores en el código utilizando funciones sofisticadas (p. ej., análisis de flujo de datos, análisis de flujo de control, reconocimiento de patrones). Los encuentra porque coinciden con errores conocidos que tiene almacenados en una base de datos.

No es un secreto que las herramientas comerciales de pruebas de seguridad de aplicaciones estáticas generan reportes que contienen altas tasas de falsos positivos. Por eso siempre es necesaria la verificación humana. Los expertos se encargan de revisar los resultados para determinar si se trata de problemas reales. Así pues, el despliegue de herramientas SAST debe realizarse junto con el trabajo manual. El SAST manual lo llevan a cabo analistas de seguridad que comprenden el contexto de la aplicación y encuentran problemas de seguridad en el código fuente que la herramienta no ha podido detectar (es decir, falsos negativos). En un artículo anterior del blog se explica más detalladamente por cuáles etapas pasa. Los expertos están al día en materia de vulnerabilidades gracias a su trabajo diario y al contacto con recursos como Open Web Application Security Project (OWASP) y Common Weakness Enumeration (CWE). La combinación de pruebas de seguridad automáticas y manuales continuas genera resultados más precisos.

Es muy importante examinar el código fuente realizando SAST manualmente junto con herramientas de pruebas de seguridad automatizadas. Para que te hagas una mejor idea, nuestro State of Attacks 2022 muestra que la información confidencial no cifrada y la información sensible en el código fuente se encuentran entre los cinco tipos de vulnerabilidades que más riesgo suponen para los sistemas que Fluid Attacks evaluó en 2021.

El análisis de la composición de software (SCA) te permite inventariar tus componentes de código abierto. Al conocer sus versiones, puedes comprobar cuáles están actualizados, y al conocer las licencias de los componentes, puedes cambiar a otros componentes que hagan cosas similares pero que tengan licencias compatibles con las políticas de tu organización para evitar riesgos legales. Además, tanto manualmente como con la ayuda de herramientas de SCA, este método apunta a aquellos componentes que tienen vulnerabilidades que aparecen en bases de datos públicas o que han sido reveladas por analistas de seguridad, investigadores o los propios vendedores.

Identificar el riesgo relacionado con las dependencias vulnerables de software de código abierto es una prioridad absoluta. Has oído hablar de Log4Shell. ¿Cómo no? A día de hoy sigue siendo un gran lío. Los atacantes siguen explotando vulnerabilidades en Log4j porque una multitud de aplicaciones (tal vez millones, pero ¿quién sabe?) lo utilizan para logging. Sigue siendo noticia porque la gente no logra recordar que lo utiliza en su software y, por tanto, está expuesta a ataques de ejecución remota de código y de malware, entre otros.

Log4j es solo uno de nuestros problemas. Nuestro State of Attacks de 2022 muestra que el "uso de software con vulnerabilidades conocidas" es el tipo de vulnerabilidad que generó la mayor exposición al riesgo y también estuvo presente en la mayoría de los sistemas Fluid Attacks evaluados durante 2021.

Pero no nos malinterpretes. No creemos que el código abierto sea malo. De hecho, recomendamos compartir abiertamente tu código fuente, siempre y cuando te asegures de probarlo constantemente en busca de vulnerabilidades. La importancia de la seguridad del código abierto se debe, al menos en parte, a que facilita el desarrollo de software. Alrededor de 80% del código de las aplicaciones procede de dependencias de código abierto y el resto es código propietario. La forma en que se utilizan estas bibliotecas para poder crear algo nuevo se ajusta al curso estándar de la evolución de la cultura humana. Ya lo hemos dicho antes: nos paramos sobre hombros de gigantes.

Entre las ventajas más destacables del análisis de composición de software se encuentran las siguientes:

Las pruebas de seguridad de aplicaciones dinámicas (DAST) son un método para evaluar aplicaciones en ejecución. Es decir, estas aplicaciones ya están en un servidor web, una máquina virtual o un contenedor y funcionando. A diferencia de SAST, DAST no requiere acceso al código fuente, sino que evalúa el comportamiento de la aplicación desde el lado del usuario, por así decirlo. Como se realiza sin ver el código fuente, es un tipo de prueba caja negra.

Las pruebas de seguridad de aplicaciones dinámicas consisten en enviar vectores de ataque (p. ej., cadenas de código) a los puntos finales de la aplicación para inspeccionar comportamientos inesperados. Así, por ejemplo, si una aplicación no descarta correctamente las entradas no seguras, es vulnerable a ataques de inyección (p. ej., inyección SQL). Estos ataques pueden permitir a los delincuentes obtener información confidencial o lograr la ejecución remota de código. Por lo tanto, DAST puede ayudar a identificar este tipo de riesgos mucho antes de que la aplicación esté siquiera en manos de los usuarios finales.

Una limitación de las pruebas de seguridad de aplicaciones dinámicas es que no pueden señalar dónde residen exactamente las vulnerabilidades en el código fuente. Además, como limitación compartida con las pruebas de seguridad de aplicaciones estáticas y el análisis de composición de software, cuando se realizan solo con herramientas, pueden producir reportes con altas tasas de falsos positivos y pasar por alto vulnerabilidades reales. Pero la forma de superar los falsos positivos y los falsos negativos es combinar el uso de herramientas DAST con el trabajo manual. Cuando DAST se hace manualmente, la superficie de ataque puede ser definida con mayor precisión, y los ataques pueden ser especialmente elaborados y actualizados sobre las técnicas utilizadas por los actores de amenazas.

Frecuentemente publicamos avisos de software vulnerable secuencia de comandos en sitios cruzados, falsificación de petición en sitios cruzados e inyección, entre otros problemas de seguridad. Como nuestro equipo de investigación puede atestiguar, un atacante no necesita tener acceso al código fuente para saber cómo causar un gran daño, solo necesita usar las aplicaciones probando formas creativas de obtener acceso no autorizado. Esta es la razón por la que DAST debe llevarse a cabo constantemente. Al atacar proactivamente su propia aplicación desde el exterior, las organizaciones pueden encontrar problemas antes de que lo hagan los delincuentes. Entonces los desarrolladores pueden arreglar la aplicación desde dentro, reduciendo eficazmente los riesgos.

Después de todas estas definiciones, ¿qué se puede decir sobre la validez de comparaciones comunes como SAST vs SCA y SAST vs DAST? ¿Cuál es la mejor? Es evidente que SAST, DAST y SCA se ejecutan con diferentes alcances dentro del mismo objeto de evaluación. Cada uno de ellos beneficia a la seguridad del software a su manera y ofrece sus propias ventajas. Así que, si nos preguntas si alguno de estos métodos es mejor que los otros dos, te responderemos con otra pregunta: ¿Qué quieres lograr?

Si tu respuesta es algo así como "solo quiero saber cuál protegerá mi software de forma más eficaz", te recomendamos que te des cuenta y reflexiones sobre la importancia de las pruebas exhaustivas. Es decir, hay que eliminar las vulnerabilidades del código fuente, gestionar el riesgo del código abierto y evaluar continuamente la aplicación adoptando la postura de un atacante.

Cuando adoptas un enfoque combinado de pruebas de seguridad, estás ampliando tu alcance y tienes más posibilidades de identificar la exposición al riesgo con mayor precisión. Además, te instamos a que apliques SAST, DAST y SCA de forma continua en todo el SDLC, los incorpores lo antes posible y combines el trabajo manual con las pruebas automatizadas a lo largo de todo el proceso. La idea es mantener una práctica de remediación rigurosa a lo largo de todo el desarrollo, en la que cada vulnerabilidad se detecte y se aborde con prontitud. La adopción de pruebas integrales demostrará ser útil en la construcción de una cultura DevSecOps en tu organización.

En Fluid Attacks, ofrecemos SAST, SCA y DAST a lo largo de todo el SDLC, todo en una única solución: Hacking Continuo. Nuestro equipo de hacking altamente certificado trabaja continuamente junto con las herramientas de pruebas de seguridad para detectar todas las vulnerabilidades de las aplicaciones evaluadas. Ampliamos constantemente los tipos de vulnerabilidades que las herramientas son capaces de detectar, generando informes exhaustivos con tasas mínimas de falsos positivos y aumentando la eficacia de nuestros expertos. En el proceso, te ayudamos a cumplir varios estándares de seguridad y a reducir los costos de remediación hasta en un 90%.

Pulsa aquí para conocer la prueba gratuita de 21 días de nuestro plan Essential de Hacking Continuo, el cual te permite probar nuestras pruebas de seguridad automatizadas, o pregúntanos ahora por nuestro plan Advanced para añadir pruebas de seguridad por hackers éticos. Para obtener más información, ¡contáctanos!