SAST (Static Application Security Testing) es un método de pruebas que analiza el código fuente, el bytecode o los binarios de una aplicación en busca de debilidades de seguridad, sin ejecutarla. La herramienta convierte el código en un árbol de sintaxis abstracta y sigue el flujo de control y de datos para encontrar dónde una entrada no confiable llega a una operación sensible. Como lee el código en sí, puede correr desde el primer commit, antes de que haya algo desplegado.
La ficha de MITRE sobre inyección SQL dice que el análisis estático automatizado detecta muchas instancias de esa debilidad y, en la misma sección, que "100% accuracy and coverage are not feasible". Las dos mitades de esa frase se pueden medir. El escáner de Fluid Attacks alcanza una tasa de verdaderos positivos del 100 % y una tasa de falsos positivos del 0 % en el conjunto de pruebas OWASP Benchmark v1.2, un resultado que cualquiera puede reproducir con un solo comando de Docker. Frente a una aplicación real con 1.201 vulnerabilidades, ese mismo escáner reportó el 22,7 %.
Esta página cubre cómo el análisis estático lee el código, qué debilidades alcanza y cuáles no, cómo funciona el SAST en Fluid Attacks, en qué se diferencia de DAST y SCA, y qué no demuestra un escaneo limpio.
¿Qué es SAST?
SAST, también llamado análisis estático o pruebas estáticas de seguridad de aplicaciones, es un método de pruebas de caja blanca: la herramienta tiene acceso completo a la estructura interna y a la lógica de la aplicación, y nunca ejecuta el programa. Examina código fuente, bytecode o binarios compilados, y reporta el archivo y la línea donde está cada debilidad.
SAST trabaja en tres etapas. El parsing convierte el código en un árbol de sintaxis abstracta que representa funciones, variables y estructuras de control. El análisis de flujo de control mapea los caminos que puede tomar la ejecución. El análisis de flujo de datos rastrea los valores mientras se mueven entre esos caminos, que es como el análisis de código fuente conecta una entrada controlada por un atacante con la operación que confía en ella.
Las reglas de detección se montan sobre ese modelo. Las herramientas SAST codifican patrones asociados a clases de debilidad conocidas, mapeadas a catálogos como el OWASP Top 10 y CWE, de modo que una coincidencia produce un hallazgo con categoría, severidad y ubicación.
Qué no es SAST
Tres técnicas se agrupan bajo "escaneo de código". Responden preguntas distintas, y la diferencia importa cuando un reporte vuelve limpio.
Técnica | Qué lee | Qué responde | Qué no puede decirte |
Pruebas estáticas de seguridad de aplicaciones | Tu propio código fuente, bytecode o binarios | Dónde se escribió lógica insegura | Si la falla es explotable en el entorno desplegado |
Análisis de composición de software | Dependencias de terceros y sus versiones | Qué CVE conocidas heredaste | Nada sobre el código que escribió tu equipo |
Escaneo de secretos | Archivos e historial de commits | Qué credenciales se subieron | Si esas credenciales siguen vigentes |
Tres escaneos, tres preguntas. Un resultado limpio en uno no dice nada de los otros dos.
Por qué importa SAST
La mayor parte del riesgo de una aplicación a la medida está en el código que escribió el equipo, y SAST es la única técnica que lo lee antes de que la aplicación exista. Ese es el argumento práctico para correrlo.
La mayoría de las vulnerabilidades está en el código que escribiste
En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación con 1.201 vulnerabilidades en 105 categorías CWE, el 80 % de ellas estaba en el código, el 13 % en el backend y el resto en dependencias y en el frontend. El reporte State of Attacks 2026, que cubre 1.119.396 vulnerabilidades reportadas entre el 1 de enero y el 31 de diciembre de 2025, muestra la misma forma: 978.820 de ellas se encontraron en código fuente.
El volumen no es la severidad
La automatización encuentra casi todo lo que hay, y la parte menor de lo que importa. En ese mismo reporte, las técnicas automatizadas detectaron el 88,4 % de todas las vulnerabilidades, pero solo el 73,4 % de las altas y críticas, y la exposición al riesgo promedio por hallazgo automatizado fue de 15,5 CVSSF frente a 93,2 CVSSF por hallazgo reportado por un pentester.
Esas dos cifras fijan la expectativa para cualquier programa de SAST: cobertura amplia del código y un perfil de severidad que todavía necesita pruebas de seguridad de otro tipo encima.
La retroalimentación llega donde se escribe el código
Un hallazgo de SAST entregado en el IDE o en un pull request lo lee la persona que escribió la línea, minutos después de escribirla. Ese momento es lo que hace de la técnica parte de DevSecOps y no de una auditoría: las correcciones ocurren mientras el contexto sigue fresco, y el mismo circuito mejora la calidad general de la aplicación, no solo su seguridad.
Los hábitos de programación segura se forman igual. Un desarrollador que ve la misma regla de SAST dispararse tres veces deja de escribir el patrón.
SAST en Fluid Attacks
Fluid Attacks corre SAST como un escáner que puedes ejecutar tú, con resultados entregados en la plataforma, en el IDE y en el pipeline de CI. Lo que sigue es el alcance de nuestro SAST, la evidencia que produce y los límites que medimos.
Qué escaneamos, y bajo qué reglas
El escáner cubre 15 lenguajes de programación, seis protocolos de API, ocho formatos de infraestructura como código y 19 herramientas de CI/CD. También lee archivos de configuración y marca credenciales subidas al repositorio.
Las reglas son públicas. La Fluid Attacks Database tiene 2.200 reglas de seguridad en 45 objetivos, mapeadas a 173 estándares, que cubren código, nube, aplicaciones y binarios. Cada regla remite a una entrada de debilidad con su descripción, impacto, guía de remediación y los requisitos que hace cumplir.
La debilidad 146, inyección SQL, es un ejemplo concreto: una debilidad, 35 reglas de detección escritas para Java, C#, PHP, Python, Dart, TypeScript, Rust, Swift, Go, JavaScript, Elixir, Ruby, Scala y Kotlin, con ejemplos de remediación en 11 lenguajes. La debilidad 009 cubre credenciales y otros datos sensibles dejados en el código fuente
Una debilidad, 35 reglas de detección en catorce lenguajes y frameworks.
Cómo se ve en la práctica
Dónde corre | Cómo se dispara | Qué obtienes |
CLI en un contenedor Docker | Un solo comando | Un archivo de hallazgos en CSV |
Un push a la rama por defecto corre un escaneo completo; las ramas de trabajo y los pull requests corren un escaneo diferencial | Un archivo SARIF, listo para subir a la pestaña Security de GitHub | |
Extensiones de IDE | Abrir un archivo en el editor | El hallazgo junto a la línea que lo causó |
Plataforma de gestión de vulnerabilidades | Cada escaneo | Severidad, exposición al riesgo, ubicación y guía de remediación |
CI Gate | Ejecución del pipeline | Un build roto cuando un hallazgo incumple la política que definiste |
El mismo escáner, cinco puntos de entrada. El modo diferencial es lo que mantiene rápida la retroalimentación en los pull requests.
Un benchmark perfecto no es una aplicación segura
El escáner de Fluid Attacks obtiene 100 % en el OWASP Benchmark: una tasa de verdaderos positivos del 100 % y una tasa de falsos positivos del 0 % en la versión 1.2 del conjunto de pruebas, casi tres veces el puntaje promedio de las herramientas comerciales de detección y más de 1,5 veces el de la mejor herramienta gratuita. La documentación publica los comandos para reproducirlo: clonar el repositorio del benchmark, correr el contenedor del escáner y generar el scorecard con el plugin de OWASP.
El escáner alcanza una tasa de verdaderos positivos del 100 % y una tasa de falsos positivos del 0 % en el conjunto v1.2. .Fluid Attacks, 2026.
Ese número describe un conjunto de pruebas sintético en Java, construido para ser medible. No describe tu aplicación. En el benchmark contra una aplicación real, el mismo escáner reportó 273 de 1.201 vulnerabilidades —22,7 % de recall con 99 % de precisión—, mientras que un pentester trabajando el mismo objetivo reportó 1.076 de ellas, 89,6 % de recall con 100 % de precisión.
Evaluador y objetivo | Recall | Precisión | Qué es el objetivo |
Escáner de Fluid Attacks en OWASP Benchmark v1.2 | 100 % | 100 % | Un conjunto de pruebas sintético en Java |
Escáner de Fluid Attacks en una aplicación real | 22,7 % | 99 % | 1.201 vulnerabilidades reales, 105 categorías CWE |
Un pentester de Fluid Attacks en la misma aplicación | 89,6 % | 100 % | El mismo objetivo, 49 días de trabajo |
Promedio de las otras 34 herramientas de terceros | 1,7 % | Varía | El mismo objetivo |
Los dos resultados son del mismo escáner. La distancia entre ellos es la distancia entre un conjunto de pruebas y un código real.
Un puntaje perfecto es evidencia sobre el motor, no una afirmación sobre tu riesgo.
De un hallazgo estático a una CVE
Un hallazgo es una pista. La investigación de Fluid Attacks sobre los resultados de AI SAST describe lo que pasa en el medio: de 1.006 hallazgos generados y revisados, 163 sobrevivieron al triaje manual como verdaderos positivos, 118 quedaron tras consolidar duplicados y 28 llegaron a evaluación como candidatos a CVE. Las etapas intermedias: análisis contextual, revisión de fuente a sumidero, reproducción, deduplicación y divulgación.
Ese proceso termina en nuestros Advisories, donde las entradas detectadas por el escáner de AI SAST llevan un identificador CVE y el nombre del investigador que las divulgó.
Un hallazgo estático se convierte en CVE solo después del triaje manual, la reproducción y la divulgación.
La práctica que decide el resto
Escanear por calendario produce reportes. Escanear en cada cambio, con una compuerta, produce correcciones. Los sistemas que usan nuestro CI Gate alcanzaron una tasa de remediación del 72,2 % frente al 58 % de los que no lo usan, con una mediana de remediación de 22 días frente a 30, en el periodo de 2025 que cubre el reporte State of Attacks 2026.
Para profundizar: AI SAST explica cómo el aprendizaje automático amplía el conjunto de reglas, y nuestro benchmark contra agentes de codificación midió al AI SAST encontrando 72 de 100 vulnerabilidades reales en 52 bases de código, frente a 9 de Codex y 8 de Claude Code con el mismo prompt de auditoría.
Cómo lee el código SAST
SAST responde una pregunta, una y otra vez: ¿puede un valor que controla un atacante llegar a una operación que confía en él? Todo en el análisis sirve a esa pregunta.
El parsing convierte texto en estructura. El árbol de sintaxis abstracta le da a la herramienta funciones, parámetros, asignaciones y ramas, en vez de caracteres.
El análisis de flujo de control mapea el orden en que pueden ejecutarse las instrucciones, incluidas las ramas que solo corren bajo ciertas condiciones.
El análisis de flujo de datos sigue los valores por ese mapa, desde las fuentes —parámetros de petición, encabezados, contenido de archivos, lecturas de base de datos— hasta los sumideros, que son las operaciones donde un valor no confiable hace daño: una consulta, un comando de shell, una respuesta HTML, una ruta de archivo.
La coincidencia de reglas decide qué reporta SAST. Una regla de inyección SQL se dispara cuando un valor contaminado llega a la construcción de la consulta sin parametrización, y se queda callada cuando una sentencia parametrizada o una lista de permitidos validada rompe el camino.
Parsing, flujo de control, flujo de datos, coincidencia de reglas: de dónde sale un hallazgo y dónde se detiene. Elaboración propia.
La cadena también explica el punto ciego. Todo lo que SAST sabe viene de código presente y parseable. La configuración que se aplica al desplegar, un sanitizador implementado en un servicio que no ve, un control de autorización que impone una puerta de enlace: nada de eso está en el árbol.
Qué encuentra SAST y qué se le escapa
SAST es más fuerte con las debilidades visibles como patrón en el código: un valor que viaja desde una fuente no confiable hasta una operación peligrosa, una llamada criptográfica con un parámetro débil, una credencial escrita como literal. El análisis de código fuente las alcanza porque la evidencia está en el archivo.
Clase de debilidad | Por qué el análisis estático la alcanza | Qué sigue sin poder confirmar |
El valor contaminado y la construcción de la consulta están en el código | Si los privilegios de la cuenta limitan el impacto | |
Datos no confiables llegan al contenido web generado sin validación | Si un encabezado de respuesta o una CSP bloquea la ejecución | |
Los comandos del sistema se construyen con entradas manipulables desde fuera | Si el usuario en ejecución puede ejecutar algo útil | |
La configuración del parser y la resolución de entidades se declaran en el código | Si el parser desplegado usa esa configuración | |
Las credenciales aparecen como literales en archivos e historial | Si la credencial sigue vigente |
Cada fila es una entrada de la Fluid Attacks Database, con sus reglas y su guía de remediación.
La técnica trae dos modos de fallo, y MITRE documenta los dos para inyección SQL. Los falsos positivos aparecen cuando la herramienta no reconoce que hay validación, lo que produce alertas sin consecuencia de seguridad. Los falsos negativos aparecen cuando no puede analizar funciones de API propias o librerías de terceros, "especially if the API/library code is not available for analysis". La conclusión de MITRE sobre el análisis estático automatizado es la frase que vale la pena guardar: "100% accuracy and coverage are not feasible".
Los falsos negativos son el problema silencioso. Un reporte limpio se lee como buena noticia, y nada en él distingue "aquí no hay debilidad" de "no hay regla para esto". Por eso combinamos SAST con revisiones manuales de código en el plan Advanced, y por eso la cobertura ponderada por severidad, y no el conteo de hallazgos, es la métrica que vale la pena seguir.
SAST, DAST y SCA no son alternativas
Leen material distinto en momentos distintos, y los vacíos de una son la cobertura de otra. Las diferencias entre las tres se reducen a qué puede observar cada una.
Las Pruebas Dinámicas de Seguridad de Aplicaciones (DAST) atacan una aplicación en ejecución desde fuera, sin acceso al código. El Análisis de Composición de Software (SCA) inventaría los componentes de terceros y los compara contra vulnerabilidades conocidas. SAST lee el código que escribió tu equipo, que ninguna de las otras dos ve nunca.
Característica | SAST | DAST |
Método de prueba | Caja blanca, de adentro hacia afuera | Caja negra, de afuera hacia adentro |
Análisis | Lee el código sin ejecutar la aplicación | Simula ataques contra una aplicación en ejecución |
Cuándo aplica | Desde el primer commit | Cuando hay una aplicación desplegada y funcionando |
Hallazgos típicos | Inyección, manejo inseguro de datos, criptografía débil, secretos quemados | Configuración en ejecución, fallas de autenticación, problemas del lado del servidor |
Depende del lenguaje | Sí: la herramienta debe soportar el lenguaje y el framework | No: interactúa desde fuera |
Detalle de remediación | Archivo y número de línea | La petición que lo disparó, no la línea |
Modo de fallo principal | Falsos positivos por falta de contexto de ejecución | Falsos negativos en caminos de código que nunca alcanza |
SAST y DAST no se ponen de acuerdo sobre dónde mirar, que es justo por lo que correr las dos cubre más que correr una dos veces.
Fluid Attacks las combina en una sola solución, junto con Secure Code Review (SCR), Pentesting as a Service (PTaaS) y Reverse Engineering (RE), de modo que los hallazgos de cada técnica llegan a la misma cola y con la misma escala de severidad.
Cómo correr SAST con eficacia
Comprar un escáner es la decisión más pequeña de un programa de SAST. Cinco prácticas deciden si produce correcciones.
Elige para tu stack, no para una lista de funciones: la herramienta SAST debe soportar los lenguajes y frameworks que tus equipos usan de verdad, y publicar cómo se midió su precisión. Un proveedor que no puede decirte cómo reproducir sus propias cifras te dio una afirmación, no una medición.
Configura antes de escalar: ajusta el conjunto de reglas, delimita el escaneo al código que es tuyo y registra las exclusiones de forma explícita, para que un hallazgo suprimido sea una decisión documentada y no un vacío silencioso.
Integra donde ocurre el trabajo: extensiones de IDE para el minuto en que se escribe el código, escaneos diferenciales en los pull requests para el minuto en que se propone, escaneos completos en la rama por defecto para todo lo demás. La guía de programación segura cae mejor en ese momento.
Prioriza por exposición, no por conteo: tría por severidad y explotabilidad. En nuestros datos de 2025, el 4,5 % de las vulnerabilidades reportadas cargaba el 79,9 % de la exposición total al riesgo, que es la razón por la que un conteo de hallazgos es una mala cola de trabajo.
Verifica la corrección y deja la compuerta: vuelve a escanear después de remediar y mantén la compuerta del pipeline haciendo cumplir la política. La alternativa es un reporte que documenta la misma vulnerabilidad durante un año.
Conclusiones
SAST lee el código que escribió tu equipo, antes de que haya algo que atacar, y señala la línea exacta. Es una capacidad estrecha y valiosa: la mayoría de las vulnerabilidades de una aplicación a la medida vive en ese código, y ninguna otra técnica lo ve tan temprano.
Los límites de SAST son tan específicos como sus fortalezas. No puede confirmar la explotabilidad en un entorno desplegado, no puede razonar sobre código que no logra parsear, y un reporte limpio no es una aplicación segura. Trata un escaneo de SAST como la primera capa de evidencia, mídelo por el riesgo que cubre y no por los hallazgos que imprime, y pon encima las técnicas que ven ejecución, dependencias y lógica de negocio.
Preguntas frecuentes
¿Cuál es la diferencia entre SAST y DAST?
SAST lee código fuente, bytecode o binarios sin ejecutar la aplicación y reporta la línea exacta. Puede correr desde el primer commit. DAST ataca una aplicación en ejecución desde fuera, sin acceso al código, así que encuentra problemas de ejecución y configuración que son invisibles en el código fuente. Fallan en direcciones opuestas: SAST produce falsos positivos por falta de contexto de ejecución, y las pruebas dinámicas se pierden los caminos de código que nunca alcanzan.
¿SAST necesita que la aplicación esté corriendo?
No. Esa es la propiedad que define la técnica: analiza código en reposo, que es por lo que puede usarse antes de que la aplicación compile o se despliegue, y por lo que no puede observar el comportamiento en ejecución.
¿SAST puede encontrar todas las vulnerabilidades de mi código?
No. MITRE afirma que para el análisis estático automatizado "100% accuracy and coverage are not feasible". En el benchmark de Fluid Attacks contra una aplicación con 1.201 vulnerabilidades, nuestro escáner reportó el 22,7 % de ellas con 99 % de precisión, mientras que un pentester trabajando el mismo objetivo reportó el 89,6 % con 100 % de precisión.
¿Cuál es la diferencia entre SAST y AI SAST?
El SAST tradicional compara el código contra reglas escritas por personas, así que encuentra los patrones que esas reglas anticipan. AI SAST suma aprendizaje automático para generar candidatos y agentes para rastrear contexto entre archivos, lo que amplía la cobertura de flujos que cruzan módulos. En nuestro benchmark sobre 52 bases de código, encontró 72 de 100 vulnerabilidades reales frente a 9 de un agente de codificación de propósito general con el mismo prompt.
¿Un reporte limpio de SAST significa que mi aplicación es segura?
No. Significa que ninguna regla coincidió con el código escaneado. El código no parseado, las librerías de terceros, la configuración que se aplica al desplegar y las fallas de lógica de negocio quedan fuera del análisis, y un falso negativo se ve exactamente igual que un resultado limpio.
¿Qué tan preciso es el escáner SAST de Fluid Attacks?
En el conjunto de pruebas OWASP Benchmark v1.2 alcanza una tasa de verdaderos positivos del 100 % y una tasa de falsos positivos del 0 %, para un puntaje de 100 %, y la documentación publica los comandos para reproducirlo. Contra una aplicación real con 1.201 vulnerabilidades reportó el 22,7 % de ellas con 99 % de precisión. Las dos cifras describen el mismo escáner contra objetivos distintos.
Lee el error antes de que alguien lo ejecute
Nuestros escáneres y pentesters revisan tu código fuente desde el primer commit, para que las vulnerabilidades se corrijan mientras todavía son baratas. Prueba gratuita · Contáctanos.
Ejecuta SAST sobre lo que cambia en cada pull request
