Anderson Ponce
Es común que un equipo compre un escáner de seguridad, lo conecte al pipeline, y asuma que ya tiene cubierta la seguridad de la aplicación. El problema es que SAST, DAST y SCA no analizan lo mismo — y confundirlos deja huecos reales sin que nadie se entere hasta el incidente.
Qué analiza cada uno
| Metodología | Qué analiza | Problema principal |
|---|---|---|
| SAST | Código fuente estático | Muchos falsos positivos, no ve el comportamiento real de la app corriendo |
| DAST | La aplicación en ejecución | Requiere que la app esté corriendo; no ve el código |
| IAST | Código instrumentado en runtime | Más complejo de configurar que los dos anteriores |
| SCA | Dependencias y librerías de terceros | No analiza la lógica propia de la aplicación |
Ninguno reemplaza a los otros. Un programa de seguridad serio usa SAST para atrapar errores en el código antes de mergear, SCA para no arrastrar una dependencia con un CVE conocido, y DAST para validar cómo se comporta la aplicación real bajo ataque — algo que el análisis estático simplemente no puede ver.
DAST en la práctica: lo que nadie te dice antes del primer scan
Un scan DAST lanza miles de pruebas con payloads maliciosos contra la aplicación. Eso cambia las reglas del juego:
- Nunca contra producción. Un scan puede corromper datos o sobrecargar el servidor. Siempre en staging, con base de datos propia y restaurable.
- Cuenta de prueba dedicada. Nunca credenciales reales ni de producción. La cuenta debe tener acceso a todo lo que se quiere escanear — si solo ve la mitad de la app, el scan solo cubre la mitad.
- Excluir rutas destructivas del alcance antes de lanzar el scan —
/eliminar-cuenta,/reset-database, cualquier endpoint que un payload de inyección pueda ejecutar de verdad. - Verificar la autenticación antes de escanear, no después. Si el login falla a mitad del scan, el reporte queda incompleto y nadie se entera hasta revisarlo a fondo.
- La calidad del Swagger/OpenAPI es la calidad de la cobertura. Si un endpoint no está documentado, el escáner no lo prueba — no existe para la herramienta.
El perfil rápido de un DAST (pensado para correr en cada deploy) casi nunca cubre el OWASP Top 10 completo. Para eso se necesita un scan completo — y ninguna herramienta DAST puede verificar por sí sola los hallazgos de logging y monitoreo (A09), porque eso requiere acceso al servidor.
Dónde encaja cada escaneo en el pipeline
La secuencia que funciona en la práctica no mete todo en cada deploy — separa lo rápido de lo exhaustivo:
push → build → tests unitarios → scan SAST/SCA
→ si pasa → deploy a staging → scan DAST rápido
→ semanalmente → scan DAST completo sobre staging
→ Critical/High → ticket automático + notificación
→ se corrige → re-test puntual del hallazgo → se cierra el ticketEl scan rápido corre en cada deploy sin bloquear el pipeline. El scan completo corre programado, separado del flujo de despliegue, y es el que se usa como evidencia para auditorías. Configurar el pipeline para fallar solo en severidad alta o crítica — bloquear por hallazgos de severidad baja genera tantos falsos bloqueos que el equipo termina desactivando el gate por completo.
La seguridad que funciona no es la que se revisa una vez al final. Es la que corre en cada paso del proceso, con el tipo de análisis correcto en el momento correcto.
