SAST vs DAST: Diferencias, Qué Detecta Cada Uno y Cómo Combinarlos

SAST (static application security testing) lee tu código fuente sin ejecutarlo. DAST (dynamic application security testing) ataca tu aplicación corriendo, desde afuera. Esa sola diferencia, código quieto contra app en movimiento, explica casi todo lo demás: qué encuentra cada uno, cuándo corre, cuánto ruido hace y cuánto cuesta.

La respuesta corta a "SAST vs DAST" es que querés los dos, en momentos distintos del ciclo de vida. La respuesta larga, abajo, es cuál adoptar primero, qué no va a detectar nunca cada uno y dónde entran IAST, SCA y el SAST basado en IA.

Definiciones: SAST, DAST, IAST y SCA

SAST: análisis estático de seguridad

El SAST analiza código fuente, bytecode o binarios buscando patrones y flujos de datos que terminan en vulnerabilidades. Arma un modelo del programa (árbol sintáctico, flujo de control, flujo de datos) y sigue la entrada no confiable ("sources") hasta operaciones peligrosas ("sinks"): queries SQL, comandos de shell, salida HTML. Como trabaja sobre el código, puede correr en cada commit y señalarte el archivo y la línea exactos. Es el corazón del análisis estático de código aplicado a seguridad.

DAST: pruebas dinámicas de seguridad

El DAST es un enfoque de caja negra. Un scanner recorre una aplicación desplegada (web o API), manda requests armados a propósito y analiza las respuestas buscando señales de vulnerabilidad: payloads reflejados, mensajes de error de SQL, headers de seguridad faltantes, open redirects, TLS débil. No necesita el código fuente y no le importa en qué lenguaje escribiste. Ve la aplicación exactamente como la ve un atacante desde internet.

IAST: pruebas interactivas

El IAST mete un agente adentro de la aplicación corriendo (por ejemplo, un agente para la JVM o .NET). Mientras los tests funcionales o el tráfico real la ejercitan, el agente mira en tiempo real cómo viajan los datos desde el input HTTP hasta los sinks. Junta la precisión del SAST (sabe la línea de código) con la verdad de runtime del DAST (solo reporta caminos que realmente se ejecutaron). La contra: soporte de lenguajes limitado y necesidad de buena cobertura de tests.

SCA: análisis de composición de software

La mayor parte de una aplicación moderna es código de terceros. El software composition analysis arma un inventario de tus dependencias directas y transitivas a partir de lockfiles y manifiestos, y cruza las versiones contra bases de vulnerabilidades (CVEs, GitHub Security Advisories), además de revisar licencias. El SCA no mira la lógica de tu código; te avisa cuando una librería que despachás tiene una vulnerabilidad conocida.

Tabla comparativa SAST vs DAST

Qué encuentra cada uno y qué se le escapa

Un bug que el SAST encuentra y el DAST puede perderse

Mirá esta inyección SQL clásica, escondida detrás de un endpoint de reportes solo para admins:

// reports.js
app.get('/admin/reports', requireAdmin, async (req, res) => {
  const sort = req.query.sort;
  const rows = await db.query(
    `SELECT * FROM invoices ORDER BY ${sort}`
  );
  res.json(rows);
});

Un scanner DAST que no está logueado como admin nunca llega a esa ruta, así que no reporta nada. Y aun con credenciales, muchas herramientas DAST no fuzzean bien las cláusulas ORDER BY. Un SAST sigue req.query.sort hasta una query armada con concatenación y te marca reports.js en la línea exacta, antes de que se mergee.

Un bug que el DAST encuentra y el SAST no

Ahora suponé que el código está bien, pero producción corre detrás de un reverse proxy que borra el header Strict-Transport-Security, la cookie de sesión sale sin el flag Secure por una config del load balancer y quedó habilitado un endpoint de debug por una variable de entorno. Nada de eso aparece en el código de la aplicación. El DAST lo ve al instante porque mira respuestas reales del deploy real.

El bug que suelen perderse los dos: autorización rota

// invoices.js
app.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice); // no verifica que invoice.ownerId === req.user.id
});

Esto es un IDOR, parte del broken access control que encabeza el OWASP Top 10. No hay ningún sink peligroso: ni SQL armado a mano, ni shell, ni HTML. Una regla de SAST por patrones no tiene nada que matchear. Un DAST necesitaría dos cuentas y entender que la factura 42 es de otra persona. Acá es donde se ganan el sueldo la revisión manual, el pentesting o el análisis que razona.

Resumen de hallazgos típicos

• El SAST es fuerte en: inyecciones (SQL, comandos, templates), sinks de XSS, path traversal, deserialización insegura, credenciales hardcodeadas, criptografía débil, funciones peligrosas.
• El SAST es débil en: configuración del deploy, comportamiento en runtime, problemas que dependen de datos en la base y lógica de negocio que ninguna regla describe.
• El DAST es fuerte en: headers de seguridad, TLS, flags de cookies, paneles de admin expuestos, errores verbosos, XSS reflejado, servidor mal configurado.
• El DAST es débil en: todo lo que está detrás de flujos de auth complejos, rutas que no están linkeadas desde la UI y decirte qué línea arreglar.

Cómo se complementan SAST, DAST, IAST y SCA

Pensalos como capas que se superponen a propósito:

1. SCA y SAST en cada pull request. Baratos, rápidos y precisos. Frenan dependencias vulnerables y fallas obvias antes del merge.
2. Escaneo de secretos en todo el historial de git. Una key commiteada y después borrada sigue viviendo en el historial.
3. Chequeos de IaC y de CI. GitHub Actions, Dockerfiles, Terraform y manifiestos de Kubernetes también son código, y un error ahí suele ser más grave que un bug en la app.
4. DAST contra staging de forma periódica. Confirma que el sistema desplegado se comporta como sugiere el código y detecta drift de configuración.
5. IAST donde tengas buenas suites de tests y un runtime soportado, típicamente en entornos grandes de Java o .NET.
6. Pentests manuales periódicos para lógica de negocio, ataques encadenados y todo lo que necesita creatividad humana.

Esta estructura en capas es lo que en la práctica significa "shift left" dentro de DevSecOps: empujar la mayor cantidad posible de detección a las capas baratas y tempranas, y dejar las caras y tardías para lo que solo ellas pueden ver.

Dónde entra el SAST con IA

Los motores SAST tradicionales corren reglas: "si el input del usuario llega a db.query sin pasar por un sanitizador, reportalo". Funciona bien para tipos de sink conocidos, pero tiene dos problemas estructurales. Primero, las reglas no pueden conocer cada sanitizador propio, cada wrapper del ORM o cada convención del framework, así que reportan de más (ruido) o de menos (huecos). Segundo, las reglas no expresan intención. "Cada usuario solo puede leer sus propias facturas" no es un patrón; es lógica de negocio.

Un SAST con IA usa un modelo de lenguaje para leer el código como lo haría un revisor. En vez de solo matchear sintaxis, puede:

• Seguir el flujo de datos entre archivos y a través de helpers, middlewares y wrappers que un motor de reglas no modela.
• Razonar sobre autorización: notar que un handler chequea el dueño del recurso y su hermano no.
• Evaluar alcanzabilidad y contexto, descartando una llamada "peligrosa" cuyo input en realidad es una constante, lo que baja los falsos positivos.
• Explicar el hallazgo en lenguaje claro y proponer un fix, lo que acelera el triage para devs que no son especialistas en seguridad.

No es magia. Los modelos también se pueden equivocar con total seguridad, así que un buen SAST con IA ancla cada hallazgo a un archivo y una línea concretos y describe el camino de explotación para que una persona lo pueda verificar. Mirá cómo funciona el AI SAST en la práctica y en qué se diferencia de la revisión de código con IA en pull requests.

Un detalle práctico: un SAST con IA que manda tu código fuente a la API de un proveedor de IA genérico es una decisión sobre el manejo de tus datos, no solo sobre herramientas. Si eso te importa, leé nuestra guía sobre IA self-hosted para seguridad de código.

Stack recomendado: startup vs empresa regulada

Startup en etapa temprana

Tenés un equipo chico, uno o dos repositorios, nadie dedicado a seguridad y poca paciencia para el ruido. Optimizá señal por minuto:

• SAST + SCA + secretos + IaC en una sola pasada por repositorio, con hallazgos ordenados por explotabilidad y no solo por etiqueta de severidad.
• Correlo en los pull requests para que el problema lo arregle quien lo escribió, con el contexto fresco.
• Un chequeo DAST liviano de tu dominio de producción: headers, TLS y endpoints expuestos.
• Un pentest externo cuando un cliente o un inversor lo pida, no antes de haber arreglado lo fácil.

Por ejemplo, con Nurbak conectás GitHub y escaneás un repositorio: su propio modelo de IA self-hosted analiza el código (el análisis no manda tu código a OpenAI ni a Anthropic), reporta vulnerabilidades explotables con archivo y línea, cruza las dependencias contra CVEs conocidos, marca configuraciones inseguras de GitHub Actions, Docker, Terraform y Kubernetes y secretos en el historial de git, y lo resume en un score de seguridad de 0 a 100 con explicaciones en lenguaje claro. El escaneo gratis te muestra completos los 3 hallazgos más importantes, y en la página de AI SAST tenés más detalle del enfoque.

Empresa regulada (fintech, salud, sector público)

Acá lo que manda es la evidencia, la repetibilidad y el control de los datos, tanto como la detección:

• SAST y SCA como gates obligatorios en los pull requests, con umbrales de severidad documentados y un proceso de excepciones.
• DAST autenticado contra staging con cuentas de prueba realistas, incluyendo chequeos multi-rol para control de acceso.
• IAST en servicios críticos si tus runtimes están soportados y la cobertura de tests es alta.
• Generación de SBOM desde tu herramienta de SCA para auditorías y cuestionarios de clientes.
• Pentests manuales anuales o por release, complementados si querés con pentesting asistido por IA entre uno y otro.
• Control estricto de dónde se procesa el código. Si una herramienta de IA analiza tu código, necesitás saber dónde corre el modelo, qué se retiene y cómo es el registro de auditoría.

Errores comunes al elegir entre SAST y DAST

• Comprar DAST primero porque no requiere integración. Es fácil de arrancar, pero solo ve la superficie y no le dice al dev dónde arreglar.
• Prender todas las reglas del SAST. Los devs aprenden a ignorar una herramienta que tira cientos de hallazgos de baja confianza. Empezá por lo explotable y de alta confianza.
• Ignorar dependencias y configuración. Un código de aplicación perfecto igual despacha librerías vulnerables y un workflow de CI con tokens demasiado amplios.
• Tomar un escaneo limpio como "seguro". Los scanners bajan el riesgo; no prueban que no exista. Las fallas de lógica siguen necesitando razonamiento, revisión y pruebas.

En resumen

SAST vs DAST no es un "uno o el otro". El SAST te da detección temprana, precisa y barata en el código; el DAST te da la verdad sobre el sistema desplegado; el SCA cubre el código que no escribiste; IAST y pentests llenan los huecos. Si solo podés arrancar con una capa, empezá con SAST más SCA en los pull requests, porque ahí arreglar es más barato. Después sumá DAST y pruebas humanas a medida que crecen el producto y lo que está en juego. Un buen próximo paso es correr un escáner de seguridad de código sobre tu repo principal y ver qué encuentra de verdad.

Para seguir leyendo

• OWASP Top 10 2025
• Qué es DevSecOps
• Qué es el pentesting
• Inyección SQL