AI SAST

¿Qué es AI SAST?

AI SAST aplica un modelo grande de lenguaje (LLM) al código fuente para encontrar vulnerabilidades. Nuestro propio marco de comparación de proveedores lo define como una solución que ofrece capacidades de detección de vulnerabilidades impulsadas por inteligencia artificial mediante SAST. El LLM recibe el código con el contexto que lo rodea, razona sobre el flujo de datos y devuelve un juicio con su explicación, en lugar del identificador de una regla.

La diferencia con las pruebas de seguridad de aplicaciones estáticas (Static Application Security Testing, SAST) convencionales está en dónde vive la decisión. Un escáner basado en reglas codifica de antemano cómo se ve una vulnerabilidad. Quien escribe la regla describe un sink peligroso, una función insegura, una ruta contaminada. Todo lo que esa persona no anticipó queda invisible. AI SAST invierte el planteamiento: al modelo no se le dice cómo se ve el error, se le pregunta si este código, en este contexto, se puede abusar.

Que los modelos encuentren fallas reales no es teórico. En 2024, Google Project Zero y Google DeepMind informaron que su agente Big Sleep halló un stack buffer underflow explotable en SQLite, la primera vulnerabilidad del mundo real descubierta por el agente, y los mantenedores de SQLite la corrigieron el mismo día. Big Sleep es investigación agéntica, no AI SAST: persigue un objetivo en profundidad, mientras que AI SAST corre de forma continua sobre un repositorio que cambia. Lo que importa aquí es el terreno común: un modelo razonando sobre código encontró lo que las reglas no encontraron.

AI SAST, SAST tradicional y agentes de codificación no son alternativas

Tres cosas se mezclan en una sola conversación, y quien compra paga la confusión. Un conjunto de reglas hace coincidir patrones. AI SAST juzga el contexto. Un asistente de codificación escribe software y, de paso, se le puede pedir que busque errores. Tienen modos de falla distintos y ninguno reemplaza a los otros dos.

Las reglas siguen ganando donde el patrón es estable y la carga de contexto es baja. Una credencial escrita en el código, un cifrado obsoleto, una verificación de certificado deshabilitada: una expresión regular resuelve eso más rápido que cualquier modelo. AI SAST gana su costo en debilidades cuya explotabilidad depende de código que hay que armar entre varios archivos.

Por eso AI SAST va al lado del escaneo basado en reglas y no encima: las verificaciones deterministas baratas siguen siendo baratas, y el presupuesto de tokens va a las clases que necesitan el juicio de un modelo. Una organización que cambia su conjunto de reglas por AI-powered SAST paga precios de modelo por hallazgos que una expresión regular ya atrapaba. AI-powered SAST es una adición a un programa de seguridad de aplicaciones, no un reemplazo dentro de él.

AI SAST en Fluid Attacks

Nuestro escáner de AI SAST corre dentro del mismo programa que nuestros otros escáneres y nuestros pentesters, disponible en nuestros planes. Lo que sigue es lo que hace realmente, incluidas las partes de nuestros resultados que no nos favorecen.

Qué analizamos y bajo qué reglas

Tu código fuente se analiza bajo contrato y bajo los controles de nuestras páginas de cumplimiento: TLS 1.3 en tránsito, AES-256 para el almacenamiento de objetos y la base de datos de la plataforma, y TLS mutuo hacia nuestro origen. La evidencia de auditoría de SOC 2, PCI DSS e ISO está en nuestro Trust Center. Los hallazgos quedan en nuestra plataforma, donde tu equipo controla el acceso, y nuestro acuerdo de nivel de servicio nos compromete a detectar el 90 % de la severidad de las vulnerabilidades, medido por trimestre calendario sobre todos tus grupos.

Cómo se priorizan los candidatos

AI SAST no intenta leer todos los archivos, porque leerlos todos es el objetivo equivocado cuando cada lectura cuesta tokens. Nuestra documentación es explícita: las técnicas manuales y AI SAST usan priorización estadística de riesgo, y no cobertura de archivos, como objetivo operativo, y el modelo de priorización de AI SAST usa la probabilidad de que un fragmento tenga una vulnerabilidad específica.

Esa es la decisión arquitectónica que hace asequible la técnica. Los fragmentos llegan al modelo en orden de riesgo estimado, así que el presupuesto aterriza en el código con mayor probabilidad de ser vulnerable en vez de repartirse parejo sobre código que no lo es.

Cómo se ve en la práctica

De hallazgos de IA a advisories publicados

Apuntamos el escáner a proyectos de código abierto para probarlo contra código que nadie escribió para nosotros. El embudo de nuestro flujo de trabajo publicado es la imagen más clara de lo que rinde esta técnica.

CVE-2026-6093 muestra por qué el contexto lo es todo. En Corteza 2024.9.x, la función jsonPath escapaba comillas simples con una barra invertida en vez de duplicar la comilla como exige T-SQL, y un segundo defecto permitía que payload.ParseMeta omitiera la validación del formato de las claves cuando meta llegaba como un objeto JSON. Ninguno de los dos es una vulnerabilidad por sí solo. Juntos permiten que un usuario autenticado inyecte SQL en una expresión generada. Nuestro escáner marcó el candidato; Oscar Uribe, de nuestro Offensive Team, confirmó la cadena y publicó nuestro advisory.

Nuestro advisory de CVE-2026-6093, con el escáner que la detectó y el investigador que la divulgó.

Donde nuestras propias cifras incomodan

En nuestro benchmark contra agentes de codificación, la configuración de AI SAST que más vulnerabilidades reales encontró las encontró con 52 % de precisión. Atrapó 72 de 100 fallas sembradas y levantó 66 señalamientos erróneos en el intento. Más recall se paga con trabajo de triaje, y cualquier proveedor que reporte una cifra sin la otra esconde la mitad del trato.

El segundo resultado nos sorprendió más. Correr el mismo sistema sobre modelos más grandes lo empeoró: 0,19 de recall con GPT-5.5 y 0,47 con Opus 4.8, frente a 0,72 con la configuración más barata. La extracción, el análisis de flujo y la validación alrededor del modelo pesaron más que el modelo mismo. Compra la arquitectura, no el nombre del modelo.

Qué no cubre esta técnica

Nuestro escáner todavía no busca todos los tipos de debilidad. La investigación se concentra en las clases donde el contexto decide la explotabilidad: flujos entre archivos, persistencia de datos, SQL y controles de autorización. Tampoco sustituye al análisis de composición de software, que mira dependencias de terceros y no tu propio código, ni a las pruebas dinámicas ni a la revisión de configuración en la nube. Un CVE en una librería que importaste no es un problema que AI SAST esté buscando.

Cómo funciona AI SAST

Un pipeline de AI SAST tiene cuatro movimientos. El repositorio se divide en funciones. Un modelo puntúa cada función según la probabilidad de una debilidad específica. Los fragmentos mejor clasificados pasan a agentes especializados que traen el código circundante con llamadas a herramientas: llamadores, llamados, plantillas relacionadas, la capa de almacenamiento. Cada candidato se confirma o se descarta con su razonamiento adjunto.

El modelo actúa como generador de candidatos, no como veredicto. Ese encuadre es lo que mantiene usable a AI SAST. Un modelo al que se le pide una respuesta final sobre explotabilidad la va a producir, sostenga o no la evidencia, y así llegan vulnerabilidades alucinadas a la fila de un desarrollador. Cada paso posterior a la puntuación existe para obligar al modelo a probar su afirmación contra código recuperado.

El no determinismo se maneja igual: por diseño y no por esperanza. El mismo fragmento puede recibir respuestas distintas entre corridas, así que el pipeline acota lo que se le pregunta al modelo, lo ancla en código que efectivamente leyó y trata cada positivo como un candidato por verificar. Un hallazgo que sobrevive a eso merece la atención de un desarrollador.

Aquí es donde AI SAST se separa de apuntar un modelo de chat a un repositorio. El modelo es la parte más pequeña del sistema: la extracción decide qué ve, la puntuación decide qué lee primero, la validación decide qué llega a una persona. En nuestras pruebas, esas tres etapas explicaron más del resultado que el modelo.

AI SAST frente al SAST tradicional

Los escáneres basados en reglas y AI SAST fallan en direcciones opuestas, y la comparación solo tiene sentido por clase de debilidad, no en el agregado.

Comprensión del contexto

Muchas vulnerabilidades no son visibles en una sola línea. El cross-site scripting almacenado es el ejemplo de manual: la entrada del usuario llega en un archivo, se persiste en otro y se renderiza sin escapar en una plantilla en otro lado. Cada archivo se ve bien por su cuenta. Nuestro catálogo de debilidades describe el XSS almacenado como la posibilidad de inyectar JavaScript de forma persistente en los campos de la aplicación, lo puntúa en CVSS 4.0 y lo mapea a correcciones en siete lenguajes, pero encontrarlo en un repositorio real significa armar tres archivos en una sola historia.

La entrada 010 de nuestro catálogo de debilidades, con su puntaje CVSS 4.0 y las correcciones por lenguaje.

Ese armado es lo que hace AI SAST y lo que un escáner de un solo archivo estructuralmente no puede hacer.

Precisión, recall y lo que cuesta cada uno

La investigación independiente apunta en la misma dirección. En ICLR 2025, los autores de IRIS combinaron un modelo de lenguaje con análisis estático y lo evaluaron sobre 120 vulnerabilidades validadas a mano: CodeQL detectó 27 e IRIS con GPT-4 detectó 55, y cuatro de sus hallazgos eran desconocidos para las herramientas existentes.

Nuestros propios datos señalan la misma brecha. En nuestro benchmark de 36 herramientas de AppSec de terceros contra una aplicación web sembrada con 1.201 vulnerabilidades en 105 categorías CWE, un pentester alcanzó 89,6 % de recall con 100 % de precisión, muy por encima de lo que logró cualquier herramienta automatizada sobre el mismo objetivo. Cerrar parte de esa distancia sin poner una persona en cada archivo es el trabajo para el que se construyó AI SAST.

Soporte de lenguajes y ejecución

Las reglas se escriben por lenguaje, así que la cobertura crece de una gramática a la vez y los frameworks nuevos se retrasan. Un modelo generaliza entre sintaxis, lo que hace útil a AI SAST en lenguajes que un conjunto de reglas no ha alcanzado, aunque una clase de debilidad que el pipeline no persigue se sigue omitiendo, sea cual sea el lenguaje.

AI SAST frente a los agentes de codificación

Pedirle a un agente de codificación que audite un repositorio no es lo mismo que correr un escáner construido para auditar repositorios. Medimos la brecha sobre 52 bases de código, 68 versiones y cerca de 98 millones de líneas de código, y luego evaluamos cada configuración con 200 fragmentos: 100 vulnerabilidades reales de inyección y de scripting, y 100 señuelos escritos para parecer vulnerables sin ser explotables.

Los costos marcados con asterisco están proyectados a partir de una corrida focalizada, no medidos de punta a punta.

Lee la última fila con cuidado, porque es la que un tablero va a reportar mal. Claude Code produjo cero falsos positivos y 100 % de precisión, que parece el mejor resultado de la tabla. También omitió 92 de las 100 vulnerabilidades reales. Una herramienta que nunca grita lobo y nunca encuentra al lobo no es un control de seguridad. Esta es una medición de dos clases de vulnerabilidad sobre un conjunto de datos, no un ranking general de estos productos, pero alcanza para mostrar que la precisión por sí sola no dice nada sobre la cobertura.

AI SAST para remediación, verificación y cumplimiento

AI SAST que se detiene en un ticket no reduce el riesgo. Para que la remediación de vulnerabilidades ocurra de verdad, tres cosas tienen que seguir a un hallazgo: una corrección sobre la que el desarrollador pueda actuar, prueba de que la corrección funcionó y una línea de vuelta hacia la norma contra la que auditan a la organización.

La guía de corrección con IA generativa es la primera. Un parche aplicado en un clic es cómodo, pero una guía que explica la alternativa segura en el contexto de tu base de código cambia cómo se escribe la siguiente función. Los desarrolladores que reciben guía contextual dejan de reintroducir la misma clase, que es el retorno compuesto que AI SAST tiene sobre un escáner que solo etiqueta.

La verificación es la segunda. Una corrección no está terminada porque un modelo lo diga; nuestra plataforma permite que tu equipo solicite un reataque, y la vulnerabilidad sigue abierta hasta que las pruebas confirman que se cerró. Nuestro CI Gate rompe la compilación cuando un hallazgo incumple tu política, lo que impide que se despliegue código sin verificar.

El cumplimiento es la tercera, y es donde AI SAST ahorra más tiempo sin que se note. Nuestro catálogo de reglas de seguridad reúne 2.206 reglas sobre 47 objetivos, mapeadas a 173 estándares, así que un hallazgo llega ya conectado al requisito de OWASP, PCI DSS o NIST que incumple. Los auditores no aceptan una lista de errores; aceptan un control mapeado con evidencia de cierre, y ese mapeo es lo que convierte la salida de AI SAST en evidencia de auditoría y no en un atraso.

Cómo evaluar una solución de AI SAST

El proyecto OWASP Benchmark existe para verificar la velocidad y la exactitud de las herramientas de detección de vulnerabilidades, y su lógica es el punto de partida correcto para evaluar AI SAST: una afirmación sin un conjunto de datos detrás es mercadeo. La mayoría de las propuestas de AI SAST abre con la precisión, porque la precisión es la cifra que mejora cuando una herramienta reporta menos. Estas son las preguntas que conviene hacer en su lugar.

Un hallazgo en nuestra plataforma, con la explicación de dónde llega la entrada del atacante a la consulta.

Conclusiones

AI SAST mueve la decisión sobre si un código es explotable desde una regla escrita de antemano hacia un modelo que razona sobre el contexto, y ese cambio es lo que le permite atrapar debilidades repartidas entre varios archivos. No es gratis ni es limpio: nuestra configuración de mayor recall corrió con 52 % de precisión, los modelos más grandes rindieron por debajo del más barato, y cada candidato sigue pasando por una persona antes de convertirse en un reporte de vulnerabilidad. Esos límites son la razón por la que publicamos las cifras en vez de un solo número de precisión, y la razón por la que AI SAST va dentro de un programa de seguridad de aplicaciones con escáneres y pentesters en lugar de ocupar su lugar. Agents build, you lead, we secure, y la parte de asegurar sigue terminando con una persona leyendo la evidencia.

Preguntas frecuentes

¿Qué tan exacto es AI SAST? 

Depende por completo de la configuración y del conjunto de datos, y por eso una sola cifra no es una respuesta. En nuestro benchmark de 200 fragmentos sobre fallas de inyección y de scripting, nuestra configuración de mayor recall encontró 72 de 100 vulnerabilidades reales con 52 % de precisión, mientras que las configuraciones construidas sobre modelos más grandes alcanzaron 0,47 y 0,19 de recall.

¿Puede AI SAST encontrar vulnerabilidades que los escáneres basados en reglas omiten? 

Sí, concretamente aquellas cuya explotabilidad depende de código en otros archivos. Las fallas de scripting almacenado y las cadenas de inyección que cruzan un manejador de entrada, una capa de almacenamiento y una plantilla son los casos más claros. La investigación independiente apunta en la misma dirección: en ICLR 2025, IRIS detectó 55 de 120 vulnerabilidades validadas donde CodeQL detectó 27.

¿En qué se diferencia AI SAST de un agente de codificación con IA? 

Un agente de codificación está construido para escribir software y se le puede pedir que busque errores; AI SAST es un pipeline construido para encontrarlos, con extracción de código, análisis de flujo, priorización y validación alrededor del modelo. En nuestro benchmark, dos agentes de codificación encontraron 9 y 8 de 100 vulnerabilidades reales.

¿AI SAST sigue necesitando revisión humana? 

Sí. Un hallazgo del modelo es un candidato, no una vulnerabilidad confirmada. Nuestros analistas determinan si datos controlados por un atacante llegan a una operación peligrosa y si la sanitización, el escapado, la validación o la autorización lo bloquean, y luego manejan la deduplicación y la severidad.

¿Fluid Attacks usa AI SAST para encontrar CVE nuevos? 

Sí. De 1.006 hallazgos del escáner que nuestros analistas revisaron sobre proyectos de código abierto, 118 eran verdaderos positivos únicos y 28 se convirtieron en candidatos a CVE. Doce son advisories publicados, entre ellos CVE-2026-6093, una inyección SQL en Corteza confirmada y divulgada por nuestro Offensive Team.

Pon los hallazgos del modelo frente a un pentester

Nuestro escáner de AI SAST y nuestros pentesters revisan tu código juntos, así que un candidato se convierte en vulnerabilidad confirmada antes de llegar a la fila de tus desarrolladores. Prueba gratis · Contáctanos.