SAST (Pruebas estáticas de seguridad de aplicaciones).

SAST analiza el código convirtiéndolo en representaciones intermedias —un árbol de sintaxis abstracta (AST), un grafo de flujo de control (CFG) y un grafo de flujo de datos (DFG)— y después aplica reglas de patrones o análisis de taint para detectar construcciones inseguras mapeadas a identificadores CWE. El análisis de taint es el motor central: marca las fuentes no confiables (un parámetro HTTP, la lectura de un fichero), rastrea cómo se propagan esos datos a través de variables y llamadas a funciones, y genera un hallazgo cuando alcanzan un sink peligroso (una consulta SQL, exec, una respuesta HTML) sin haber pasado por un sanitizador reconocido. Como nada se ejecuta, SAST corre en IDEs, ganchos pre-commit y CI, y puede analizar el código mucho antes de que se despliegue.

Sus puntos ciegos están bien documentados. SAST es potente con los bugs deterministas (inyección SQL, sinks XSS, secretos codificados en el código, criptografía débil), pero genera falsos positivos en rutas inalcanzables en tiempo de ejecución y omite fallos de configuración, de lógica de autenticación y que solo aparecen en tiempo de ejecución, por lo que los programas maduros lo combinan con SCA y DAST. Ajustar los rulesets y triar el ruido son los verdaderos costes operativos. Estándares como OWASP ASVS y NIST SSDF referencian el análisis estático como un control de verificación. Entre los motores habituales se incluyen Semgrep, GitHub CodeQL (que consulta el código como si fuera una base de datos), SonarQube, Checkmarx, Fortify y Snyk Code.

flowchart LR
  SRC[Código fuente / bytecode] --> P[Parsear a AST + CFG + DFG]
  P --> T[Análisis de taint + reglas]
  SO[Fuente no confiable] -. flujo rastreado .-> T
  T --> SK{¿Alcanza un sink<br/>sin sanitizador?}
  SK -->|Sí| F[Hallazgo mapeado a CWE]
  SK -->|No| OK[Sin alerta]
  F --> TR[Triaje: corregir o marcar falso positivo]