SAST se ejecuta sobre código sin desplegar la aplicación. Eso le permite ver lo que DAST no ve (lógica interna, rutas no alcanzables desde fuera, código muerto) y a la vez le impide ver lo que solo aparece en ejecución (errores de configuración, autenticación efectiva, comportamiento de runtime). Las dos técnicas son complementarias y se usan juntas.
Qué es SAST
SAST (Static Application Security Testing) es el análisis de seguridad de una aplicación sobre código fuente o binarios sin ejecutarla. La herramienta recorre el árbol sintáctico, el grafo de llamadas y el flujo de datos para detectar patrones inseguros: inyecciones SQL o de comandos, XSS por concatenación, deserialización insegura, secretos pegados en el repositorio, criptografía obsoleta o dependencias con CVE conocidos. Se ejecuta en el IDE del desarrollador, en el pull request o en el pipeline de CI/CD, antes del despliegue. Es uno de los componentes que recomienda OWASP SAMM en la práctica de Implementation y aparece como control central de la fase de codificación en el marco NIST Secure Software Development Framework (SSDF, SP 800-218). Su complemento natural es DAST, que mira la aplicación en ejecución desde fuera.
Por qué importa
Para una organización que entrega software propio, encontrar una vulnerabilidad en producción cuesta entre uno y dos órdenes de magnitud más que encontrarla en la fase de codificación. SAST mueve el coste a la izquierda del ciclo: el desarrollador ve el hallazgo en el momento de escribir el código o, como muy tarde, al abrir el pull request, y lo arregla con el contexto fresco. Lo que llega al pentest queda reservado para lo que solo se ve con la aplicación montada. Para los equipos que están preparando una auditoría ISO 27001, ENS o trabajando bajo NIS2 o DORA, SAST aporta evidencia continua de revisión técnica del software propio: una pieza concreta que el auditor puede pedir y que se entrega sin esfuerzo extra si la pipeline ya emite informe por cada build. La trampa habitual está en convertir el SAST en un cuello de botella: si la herramienta marca cinco mil hallazgos por proyecto y la mayoría son ruido, el equipo lo desactiva o lo ignora.
Puntos clave
La calidad del informe depende mucho del lenguaje y del framework analizado. Lenguajes con tipado fuerte y reglas estables (Java, C#) dan menos falsos positivos que lenguajes dinámicos (Python, JavaScript). Antes de elegir una herramienta conviene probarla sobre el repositorio real y medir señal frente a ruido, no leer el folleto del proveedor.
La integración correcta es en pull request, no en build nocturno aislado. El desarrollador necesita ver el hallazgo asociado a la línea que acaba de escribir, no en un informe que llega tres días después a otro equipo. CI/CD con gating selectivo (bloquear solo categorías críticas) suele ser el equilibrio que mantiene velocidad y reduce riesgo.
Los secretos hardcoded son el hallazgo más rentable de SAST. Un token de API o una clave de servicio pegada en el repositorio se mueve a cualquier mirror, fork o pipeline; rotarlo después de detectarlo es lento. Detectarlo en el commit que lo introdujo y bloquear el push elimina la mayor parte del riesgo.
SAST no sustituye al pentest ni al hacking ético. Un pentesting serio encuentra fallos de lógica de negocio, abuso de funcionalidad y rutas que la estática no puede modelar. Lo que sí evita es que el pentest gaste tiempo en clases de errores que la herramienta debería haber atrapado.
La gestión de hallazgos importa tanto como la herramienta. Sin asignación clara a un equipo de desarrollo, sin SLA por severidad y sin posibilidad razonada de marcar como falso positivo o aceptar el riesgo con caducidad, el inventario se infla y deja de servir para decidir. Suele convenir integrar SAST en un ASPM que dedupe hallazgos.
Ejemplo: introducción de SAST en una empresa con cartera de aplicaciones Java y Python
Una empresa con su cartera de productos en Java (Spring) y servicios internos en Python (FastAPI) decide arrancar un programa de seguridad del ciclo de desarrollo. En la primera fase elige una herramienta SAST que cubre los dos lenguajes y la integra en GitHub Actions de forma que cada pull request dispare el análisis. Para evitar el cuello de botella habitual, no se activa gating bloqueante en el inicio: la pipeline informa, pero no bloquea. El equipo de seguridad clasifica los primeros mil hallazgos en cuatro grupos: secretos en repositorio (acción inmediata), inyecciones y deserialización (alta), criptografía débil (media) y resto (informativo).
Al cabo de seis semanas se introduce un gating selectivo: la pipeline bloquea pull requests que añadan secretos o que introduzcan nueva criptografía obsoleta, pero no las que arrastran categorías informativas heredadas. El número de incidencias críticas detectadas en pentests semestrales cae de manera medible y, sobre todo, las pocas que aparecen son fallos de lógica que SAST nunca habría detectado, lo que confirma que el pentest está bien gastado. La evidencia generada por la pipeline alimenta el cuadro de control de ISO 27001 y la preparación de la próxima auditoría.
Errores habituales
- Activar gating bloqueante el primer día. Genera una pila inicial de hallazgos heredados que paraliza desarrollo y termina con la herramienta desactivada o configurada para ignorar todo. Hay que entrar en modo informativo y subir gating por categoría según madure el equipo.
- Tratar a todos los lenguajes con la misma plantilla. Cada motor analiza mejor unos lenguajes que otros. Sin un piloto sobre código real con métricas de señal frente a ruido, la elección se hace con criterios comerciales y luego no rinde.
- Comprar SAST sin proceso de gestión de hallazgos. Sin asignación clara, SLA y un mecanismo razonado de aceptar el riesgo o marcar como falso positivo, los hallazgos se acumulan y el inventario deja de ser una señal accionable.
- Asumir que SAST detecta vulnerabilidades en dependencias de terceros. Para eso está SCA y el SBOM. Pedir a SAST que cubra ese frente lleva a falsos negativos y a sorpresas en producción.
- Olvidar al desarrollador en el diseño del programa. SAST sin formación y sin ejemplos concretos de remediación por categoría se convierte en un castigo opaco. Una guía de patrones seguros por lenguaje cierra el bucle.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿En qué se diferencia SAST de DAST?
SAST analiza el código sin ejecutarlo: ve la lógica interna, rutas no alcanzables y secretos pegados en el repositorio. DAST analiza la aplicación en ejecución desde fuera y ve configuración real, autenticación efectiva y comportamiento de runtime. Son complementarios y un programa serio de seguridad de aplicaciones combina ambos.
¿Cuándo se ejecuta SAST en el ciclo de desarrollo?
Idealmente en tres puntos. En el IDE del desarrollador con un linter ligero, en el pull request con la herramienta completa, y en el merge a la rama principal como evidencia final. Lo importante es que el hallazgo llegue al desarrollador con la línea de código fresca, no en un informe tardío.
¿Cómo se gestionan los falsos positivos de SAST?
Hay que asumir que existen y diseñar el proceso para que no destruyan la confianza. Cada hallazgo debe poder marcarse como falso positivo con justificación firmada por un revisor distinto del que escribió el código, con caducidad y revisión en cada cambio. Sin ese flujo, el equipo desactiva la herramienta.
¿Sirve SAST para cumplir ISO 27001, ENS, NIS2 o DORA?
Aporta evidencia concreta de revisión técnica del software propio en el ciclo de desarrollo, que es una de las piezas que estos marcos piden cuando la organización desarrolla aplicaciones. Por sí solo no cubre todo el control de software seguro, pero es una de las pruebas más sólidas para esa parte.
¿Cuánto tarda en verse el primer resultado real?
El informe inicial llega en horas tras conectar la herramienta al repositorio. Pero la señal accionable (hallazgos clasificados, baseline saneado, gating selectivo activado) suele aparecer entre la cuarta y la octava semana. Antes de ese punto el ruido domina y conviene mantener el modo informativo.