01Cómo funciona el SAST por dentro
Los motores SAST traducen el código a representaciones intermedias – árboles de sintaxis abstracta o hechos de programa relacionales – y aplican sobre ellas análisis de flujo de control, de flujo de datos y de taint. CodeQL, por ejemplo, extrae el código a una base de datos y expresa las vulnerabilidades como consultas en una extensión de Datalog; Semgrep casa patrones estructuralmente sobre el árbol sintáctico, con fuentes, sumideros y sanitizers como reglas de taint. La profundidad marca la diferencia: el análisis dentro de una función es el estándar – el análisis interprocedural a través de límites de archivos y funciones distingue las clases de herramientas y, en Semgrep por ejemplo, queda reservado a la oferta comercial.
02El límite probado: la exactitud es imposible
Según el teorema de Rice, todas las propiedades semánticas no triviales de los programas son indecidibles – un análisis que encuentre todas las vulnerabilidades sin dar nunca una falsa alarma es matemáticamente imposible. Cada herramienta elige un lado: la sobreaproximación (ningún caso omitido dentro del espacio modelado, a costa de falsas alarmas sistemáticas – la base la pusieron Cousot y Cousot en 1977 con la interpretación abstracta) o la subaproximación (más precisa, con huecos). Los falsos positivos no son un error de implementación, sino el precio del enfoque – la única cuestión es quién los descarta.
03Qué encuentra el SAST de forma fiable
El SAST es más fuerte en clases de fallo con forma estable: inyección, llamadas criptográficas inseguras, credenciales incrustadas, errores de memoria en C/C++ – con archivo, línea y posición exactos, mucho antes de que exista una aplicación que probar. Por eso OWASP SAMM sitúa las pruebas estáticas y dinámicas automatizadas ya en el nivel de madurez 1 de su corriente de Security Testing: son la línea base escalable sobre la que se apoyan las pruebas manuales más profundas.
04Qué no puede encontrar estructuralmente
OWASP nombra con claridad los puntos ciegos: los fallos de autenticación y autorización, el mal uso de la criptografía y los errores de lógica de negocio son difíciles o imposibles de detectar automáticamente – y los errores de configuración ni siquiera están en el código. La medición lo confirma: en un estudio ISSTA de la TU de Múnich, seis analizadores de C/C++ pasaron por alto entre el 47 y el 80 por ciento de 192 vulnerabilidades reales conocidas; incluso combinando todas las herramientas se escapaba entre el 30 y el 69 por ciento. Estas clases requieren threat modeling, revisiones – o razonamiento semántico.
Página de conocimiento Threat Modeling →05La realidad de los falsos positivos
Según la investigación consolidada, entre el 35 y el 91 por ciento de las alertas del análisis estático no son accionables. Un estudio de campo de 2025 – financiado por un proveedor – sobre casi 3.000 repositorios públicos encontró más del 91 por ciento de falsas alarmas en tres clases de fallo clásicas, con un caso extremo de 1.166 hallazgos y 6 reales. Y la evaluación de más de 100 millones de hallazgos AppSec de 178 organizaciones mostró que solo entre el 2 y el 5 por ciento exige acción inmediata. La fatiga de alertas no es un factor blando: es la causa más frecuente del fracaso de los programas SAST.
06Qué hacen distinto Google y Meta
Las dos palancas más eficaces están publicadas: en Meta, la tasa de corrección de los escaneos nocturnos por lotes era casi cero; cuando el mismo análisis apareció como comentario en la revisión de código del diff, subió a más del 70 por ciento – mismo motor, misma tasa de falsas alarmas. Google solo admite en la revisión análisis cuya tasa efectiva de falsas alarmas quede por debajo del 10 por ciento; en la práctica su sistema Tricorder está justo por debajo del 5 por ciento. La lección: el punto de despliegue y la confianza del desarrollador pesan más que la calidad de la herramienta.
07Evaluar herramientas con seriedad
El OWASP Benchmark es una aplicación Java ejecutable con 2.740 casos de prueba realmente explotables en 11 categorías; las herramientas se puntúan por tasa de verdaderos positivos frente a falsos positivos (índice de Youden). La suite Juliet del NIST añade casos sintéticos sobre 118 CWE en C/C++ y 112 en Java. Cuidado con afirmaciones de fabricante como «100 % de detección»: los corpus son públicos, el sobreajuste es posible – y benchmarks recientes como CASTLE muestran que cada clase de herramienta tiene sus propios patrones de fallo: la verificación formal minimiza falsas alarmas pero falla fuera de su modelo; los LLM brillan en fragmentos y flaquean al crecer el código.
08Un panorama de herramientas en plena sacudida
Las coordenadas cambiaron en 2024/2025: Semgrep puso sus reglas mantenidas bajo licencia propietaria en diciembre de 2024 – en respuesta, un consorcio de unos diez proveedores de seguridad bifurcó el motor como Opengrep (LGPL; tras un año: 43 releases y análisis de taint entre funciones como código abierto). Sonar también sacó sus analizadores de lenguaje de la LGPL. GitHub dividió Advanced Security en abril de 2025 en Code Security (30 US-$ por committer activo/mes) y Secret Protection (19 US-$). Y tras dos años de pausa, Gartner relanzó el Magic Quadrant de Application Security Testing en octubre de 2025 – con 16 proveedores y el ASPM como dimensión de evaluación.
09Qué cambia la IA en el SAST
Las cifras más sólidas están en el triaje: agentes LLM detrás de un SAST clásico redujeron las falsas alarmas en el OWASP Benchmark hasta un 88,6 por ciento con solo un 3,1 por ciento de pérdida de recall; sobre alertas reales de CodeQL identificaron hasta el 93,3 por ciento de los falsos positivos. Copilot Autofix de GitHub reduce el tiempo mediano de corrección de 1,5 horas a 28 minutos según la telemetría beta. Y sistemas autónomos como Google Big Sleep o los finalistas del DARPA AIxCC ya encuentran vulnerabilidades reales por sí solos. Los límites de la tarjeta 4 se desplazan – pero no desaparecen: la IA complementa las capas, no las sustituye.
Profundizar: AI Code Security → 
