SDLC seguro y herramientas SAST y DAST

El ciclo de vida seguro del desarrollo de software (SSDLC) integra actividades de seguridad en todas las fases del desarrollo de software: desde los requisitos, pasando por el diseño, la programación, las pruebas y la implementación, hasta el mantenimiento. El SDLC tradicional trata la seguridad como una validación de la fase final, lo que resulta costoso e ineficaz. La filosofía del SDLC seguro consiste en encontrar y corregir las vulnerabilidades lo antes posible, porque los defectos detectados durante el diseño cuestan mucho menos de corregir que los encontrados en producción.

Desplazar hacia la izquierda significa adelantar la seguridad (hacia la izquierda en la línea temporal del desarrollo) en lugar de añadirla al final. En la práctica, esto implica incluir requisitos de seguridad en las historias de usuario, realizar modelado de amenazas durante el diseño, llevar a cabo revisiones de código y SAST durante el desarrollo, y ejecutar DAST antes de la publicación. Los equipos que desplazan la seguridad hacia la izquierda detectan las vulnerabilidades cuando resulta más barato corregirlas: durante el desarrollo y no en producción.

El modelado de amenazas identifica y documenta sistemáticamente las amenazas de seguridad durante la fase de diseño. El modelo STRIDE clasifica las amenazas en: suplantación de identidad, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. PASTA (Process for Attack Simulation and Threat Analysis) es una metodología centrada en el riesgo que simula los objetivos de un atacante. Los modelos de amenazas generan medidas de mitigación priorizadas antes de escribir una sola línea de código.

SAST (pruebas de caja blanca) analiza el código fuente, el bytecode o los binarios sin ejecutar la aplicación, en busca de patrones de programación asociados con vulnerabilidades conocidas. Las herramientas SAST pueden analizar rápidamente todo el código base e informar de problemas como credenciales codificadas directamente, puntos vulnerables a inyección SQL y deserialización insegura. Se ejecutan dentro del IDE o de la canalización de CI y muestran los hallazgos con el archivo y el número de línea, lo que facilita su corrección.

Una limitación importante de SAST es su tendencia a producir falsos positivos: marcar código como vulnerable cuando en realidad es seguro. Esta fatiga por alertas hace que los desarrolladores descarten los hallazgos sin investigarlos. Las herramientas SAST tampoco pueden detectar problemas de configuración en tiempo de ejecución, fallos de autenticación que dependen del comportamiento en tiempo de ejecución ni vulnerabilidades en llamadas a API de terceros. SAST es más eficaz cuando se combina con formación para desarrolladores, de modo que los hallazgos se clasifiquen correctamente.

DAST (pruebas de caja negra) prueba una aplicación en ejecución mediante el envío de cargas útiles de ataque a sus endpoints HTTP y el análisis de las respuestas en busca de indicadores de vulnerabilidades. DAST no requiere acceso al código fuente: prueba la aplicación como lo haría un atacante. Es especialmente eficaz para detectar problemas en tiempo de ejecución, como omisiones de autenticación, XSS reflejado en las respuestas y configuraciones incorrectas del servidor. Entre las herramientas DAST se incluyen OWASP ZAP, Burp Suite y Netsparker.

SAST y DAST son complementarios, no herramientas que compitan entre sí. SAST detecta pronto problemas a nivel de código y se integra con el IDE, pero no tiene visibilidad del comportamiento en tiempo de ejecución. DAST detecta vulnerabilidades en tiempo de ejecución y no requiere el código fuente, pero no puede analizar rutas de código que sus sondas automatizadas no activen. Utilizar ambos conjuntamente —SAST en la canalización de CI y DAST contra un entorno de staging— maximiza la cobertura de vulnerabilidades en todo el SDLC.

IAST combina aspectos de SAST y DAST instrumentando la aplicación durante el tiempo de ejecución. Un agente IAST se ejecuta dentro de la aplicación (en el servidor) y observa la ejecución del código a medida que el tráfico de prueba la atraviesa. Puede correlacionar entradas de usuario contaminadas a través de las rutas de código hasta llegar a puntos sensibles, y detectar vulnerabilidades con menos falsos positivos que SAST puro. IAST es especialmente eficaz en aplicaciones Java y .NET, y se integra de forma natural en las ejecuciones de pruebas funcionales.

El análisis de composición de software (SCA) identifica las bibliotecas de código abierto y las dependencias de terceros de una aplicación, y las compara con bases de datos de vulnerabilidades (NVD, OSV). Dado que las aplicaciones modernas pueden incorporar cientos de dependencias —muchas de ellas transitivas—, las herramientas SCA como OWASP Dependency-Check, Snyk y Renovate son esenciales para detectar CVE conocidos antes de que los atacantes los aprovechen en su cadena de suministro.

Integrar herramientas de seguridad en las canalizaciones de CI/CD garantiza que ningún código llegue a producción sin superar los controles de seguridad. Una canalización de DevSecOps típica ejecuta: SAST en cada commit, SCA cuando cambian las dependencias, análisis de imágenes de contenedor antes de enviarlas al registro, análisis de IaC para Terraform/CloudFormation y DAST contra una implementación de staging. Los controles de seguridad fallidos bloquean la compilación y hacen cumplir una cultura de seguridad por defecto.

Las herramientas automatizadas no pueden sustituir una revisión de código humana centrada en la lógica de seguridad. La revisión por pares debe verificar que: las comprobaciones de autenticación y autorización estén en los lugares adecuados; el manejo de errores no revele información confidencial; las funciones criptográficas utilicen algoritmos y parámetros aprobados; y la lógica de negocio no pueda omitirse. Los responsables de seguridad dentro de los equipos de desarrollo —desarrolladores con formación en seguridad— cubren la brecha entre el equipo de seguridad y el de ingeniería.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que: el SDLC seguro integra la seguridad en todas las fases del desarrollo, en lugar de añadirla al final; SAST analiza el código sin ejecutarlo, mientras que DAST prueba aplicaciones en ejecución; y SCA identifica dependencias de código abierto vulnerables, mientras que los controles de seguridad de CI/CD hacen cumplir automáticamente los hallazgos. A continuación, exploraremos los servicios de directorio con LDAP y Active Directory.