Dentro del flujo de trabajo del AI SAST de Fluid Attacks para encontrar candidatos a CVE

Cómo el escáner pasa del código a los candidatos

En términos generales, el escáner no le pide a un modelo que lea un repositorio completo y adivine dónde se encuentran las vulnerabilidades. Este primero reduce la base de código en unidades más pequeñas que puedan analizarse con mayor precisión. La primera etapa descompone el repositorio y divide el código en funciones, que son las unidades en las que se observan muchos comportamientos relevantes para la seguridad: se reciben entradas, se transforman valores, se construyen consultas, se renderizan plantillas y se aplican comprobaciones de autorización.

Esas funciones luego son evaluadas por un modelo propietario de machine learning, entrenado con conocimiento acumulado sobre vulnerabilidades a través de la investigación de seguridad y las pruebas de penetración de Fluid Attacks. El modelo actúa como un generador de candidatos. En lugar de declarar una vulnerabilidad por sí solo, produce declaraciones tales como: "Esta función puede contener esta debilidad, con esta puntuación". Esa primera pasada reduce el espacio de búsqueda para un análisis más profundo.

La tercera etapa es más contextual. La lista de candidatos se pasa a agentes de IA especializados, es decir, flujos de trabajo de modelos enfocados en tareas específicas y diseñados para razonar sobre categorías concretas de debilidades. Estos agentes utilizan llamadas a herramientas, que son formas controladas para que el modelo inspeccione el código relacionado, siga las llamadas a funciones y navegue por el repositorio. Esto es importante porque muchas vulnerabilidades no son visibles en una sola línea. Un problema de XSS almacenado (cross-site scripting), por ejemplo, puede involucrar la entrada del usuario en un archivo, la persistencia en otro y el renderizado inseguro en una plantilla o en el receptor del navegador en otro lugar.

Esta arquitectura ayuda a explicar la diferencia entre la detección de candidatos y la confirmación de vulnerabilidades. La etapa de machine learning puede marcar una función como sospechosa porque se asemeja a patrones vulnerables conocidos. Luego, la etapa del agente puede inspeccionar el contexto circundante para formular mejores preguntas: ¿El valor está controlado por el atacante? ¿Se sanitiza o se escapa antes de llegar a un receptor? ¿Es esa operación realmente alcanzable? ¿Existe una comprobación de permisos? ¿La ruta depende de la configuración predeterminada o de una personalización privilegiada?

Para los investigadores, el resultado del AI SAST no constituye un aviso (advisory) definitivo. Es un punto de partida para la priorización. El escáner puede producir un archivo SARIF (un formato estándar para resultados de análisis estático), de modo que los hallazgos puedan revisarse en un IDE y vincularse de nuevo a los archivos y líneas. A partir de ahí, un investigador clona el repositorio, estudia la ruta reportada, comprueba el código circundante y decide si el candidato es una vulnerabilidad real, un falso positivo, un duplicado o un hallazgo real pero no apto para un ID de CVE.

Cómo se seleccionan los repositorios

Cuando el objetivo es identificar candidatos a CVE, no todos los repositorios de código abierto son igualmente útiles para su revisión. Los analistas de seguridad de Fluid Attacks priorizan los proyectos donde una vulnerabilidad confirmada tendría un impacto de seguridad real en el ecosistema de software más amplio.

El primer filtro es la madurez: un objetivo no debería ser un ejercicio académico, una prueba de concepto o un repositorio abandonado con escaso uso práctico. El proyecto debe ser una aplicación, un marco o un componente real que los usuarios puedan instalar, implementar y del cual puedan depender. Señales como las estrellas en GitHub, el recuento de instalaciones, la distribución de paquetes, la actividad de lanzamientos y la adopción de la comunidad ayudan a estimar si el software tiene suficiente uso como para justificar una revisión más profunda.

El alcance también importa: los investigadores evitan proyectos que ya están cubiertos por un programa específico de bug bounty o que claramente caen bajo el alcance de otra CNA. Una CNA (Autoridad de Numeración de CVE) es una organización autorizada para asignar identificadores de CVE a vulnerabilidades dentro de un alcance definido. Si un producto pertenece a otra CNA, el problema puede seguir siendo válido, pero la asignación debe seguir el canal de esa CNA en lugar del de Fluid Attacks.

Esto es especialmente importante para el descubrimiento asistido por IA, ya que el escáner puede generar muchos candidatos, mientras que el tiempo de los profesionales es limitado. Ejecutar el flujo de trabajo contra proyectos con baja adopción produciría actividad sin generar necesariamente valor para los usuarios, los mantenedores o el ecosistema. Por el contrario, centrarse en aplicaciones y marcos de código abierto maduros aumenta la posibilidad de que una vulnerabilidad confirmada ayude a múltiples equipos a reducir su exposición al riesgo.

Fluid Attacks también está trabajando en un modelo interno para clasificar la popularidad del software antes de iniciar la investigación de vulnerabilidades. El objetivo no es reemplazar el criterio del investigador, sino hacer que la priorización sea más sistemática. Al momento de escribir esta publicación, ese modelo no está integrado en el pipeline de AI SAST, pero apunta al mismo principio: el descubrimiento debe ser guiado por el impacto potencial.

De hallazgo candidato a candidato a CVE

Una vez que nuestro escáner AI SAST produce un hallazgo candidato, la cuestión ya no es "¿Encontró el escáner un patrón sospechoso?" sino "¿Este comportamiento representa una vulnerabilidad que debería ser divulgada públicamente?"

Los investigadores comienzan revisando el flujo de origen a receptor identificado por el escáner. Un origen (source) es un lugar donde los datos ingresan a la aplicación, como un parámetro de solicitud, una entrada de usuario almacenada o contenido importado. Un receptor (sink) es un lugar donde esos datos pueden causar daño, como un renderizador HTML, un creador de consultas SQL o una operación sensible a la autorización. El investigador verifica si los datos están controlados por el atacante, si llegan al receptor en un contexto peligroso y si la sanitización, el escape, la validación o las comprobaciones de permisos evitan la explotación.

Si el problema sigue pareciendo válido, el investigador lo reproduce localmente con configuraciones predeterminadas. Un candidato a CVE normalmente debería reflejar una vulnerabilidad en el producto o componente tal como se envía, no una personalización riesgosa que solo aparece tras cambios privilegiados. La reproducción también ayuda a separar una ruta de código plausible de un impacto de seguridad demostrable.

Solo entonces el hallazgo avanza hacia la evaluación de CVE: Fluid Attacks sigue las reglas operativas de las CNA y la guía de aplicación del programa CVE para las CNA. En la práctica, eso significa que los analistas confirman que el problema afecta a un producto publicado y respaldado, tiene un impacto demostrable en la confidencialidad, integridad o disponibilidad, aplica a versiones afectadas identificables y puede explicarse con suficiente evidencia técnica para el proveedor y la asignación del ID de CVE.

Algunos hallazgos válidos no se convierten en candidatos a CVE porque un proveedor puede considerar que el comportamiento está fuera de su modelo de amenazas, el impacto puede no ser lo suficientemente demostrable, o el problema puede depender de una configuración privilegiada, condiciones de despliegue no soportadas o código que no forma parte del lanzamiento normal del producto. En otros casos, el producto cae dentro del alcance de otra CNA, por lo que Fluid Attacks no debería ser la organización que asigne el ID.

Para los hallazgos que sí califican, nuestros investigadores recopilan el material necesario para el escalamiento: detalles de instalación, contexto afectado, una explicación técnica de la causa raíz, pasos de prueba de concepto, imágenes que demuestran la explotación y evidencia en video cuando resulta útil.

Por qué el triaje humano sigue siendo esencial

El escáner AI SAST de Fluid Attacks se utiliza intencionalmente como herramienta de descubrimiento, no como un sistema de divulgación autónomo. Esta diferenciación vale la pena destacarla en la investigación de software de código abierto, donde los mantenedores a menudo reciben informes automatizados de baja calidad y pueden rechazar explícitamente envíos que parecen haber sido generados en su totalidad por IA. En nuestro caso, un informe que llega a un proveedor debería, por lo tanto, representar el criterio de seguridad de Fluid Attacks, no solo la predicción de un modelo.

La priorización o el triaje humano comienza determinando si el candidato es explotable. Los analistas de seguridad revisan el flujo reportado, inspeccionan los archivos relacionados y comprueban si la aparente vulnerabilidad persiste tras los controles reales de la aplicación. Muchos candidatos se descartan porque los datos ya se sanitizan, escapan, validan o parametrizan antes de llegar a la operación riesgosa. Otros son rechazados porque la supuesta entrada controlada por el atacante es, en realidad, interna, constante, privilegiada o inalcanzable en un flujo realista.

También hay casos en los que el receptor no es peligroso en el contexto. Por ejemplo, un valor puede almacenarse pero nunca renderizarse como HTML ejecutable, o una ruta de autorización sospechosa puede estar protegida por comprobaciones en el backend que no son obvias desde la primera función reportada. El escáner ayuda a los investigadores a decidir dónde mirar, mientras que ellos deciden qué demuestra la evidencia.

La remoción de duplicados es, con frecuencia, otra tarea humana. El mismo problema subyacente puede aparecer en varios archivos, receptores, rutas de llamadas o variantes de un componente. Sin consolidación, la evaluación exageraría el número de vulnerabilidades y generaría ruido innecesario para los mantenedores. Los analistas agrupan los hallazgos repetidos, identifican la causa raíz más clara y deciden qué informe representa mejor el problema real.

El rol humano se vuelve aún más importante cuando un hallazgo es válido. Los investigadores aún deben determinar el impacto, las versiones afectadas, la severidad, la reproducibilidad y si el comportamiento se ajusta al modelo de amenazas del proveedor. También preparan la prueba de concepto, documentan el flujo vulnerable y coordinan la divulgación de una manera en la que los mantenedores puedan actuar.

Qué muestran los resultados actuales

El conjunto de datos de investigación actual ofrece una visión útil del embudo que abarca desde los hallazgos generados por IA hasta los avisos públicos. Las cifras a continuación se basan en los registros de ejecución disponibles al momento de escribir este blog post y deben entenderse como una instantánea, no como un benchmark final.

Nuestros analistas han revisado 1.006 hallazgos generados por el escáner AI SAST. Después del triaje manual, 163 se marcaron como verdaderos positivos, lo que significa que los investigadores consideraron los comportamientos informados como candidatos reales a vulnerabilidades, que, tras una consolidación, se convirtieron en 118 verdaderos positivos únicos.

De esos hallazgos, 28 se convirtieron en candidatos a CVE. Eso significa que aproximadamente una de cada cuatro vulnerabilidades únicas confirmadas cumplió con los criterios adicionales para la evaluación de CVE (o alrededor de 28 candidatos a CVE por cada 1.000 hallazgos revisados en este conjunto de datos). El resto aún podría corresponder a problemas reales de seguridad, pero no necesariamente a problemas que pertenecen al flujo de trabajo de CVE. Algunos pueden carecer de suficiente impacto demostrable, depender de condiciones fuera del modelo de amenazas predeterminado del producto, estar bajo el alcance de otra CNA o requerir un manejo a través de un canal diferente.

Esa proporción también necesita contexto. Los proyectos de código abierto revisados en este esfuerzo están altamente curados y generalmente cumplen con un alto estándar de calidad de software. En ese entorno, muchos hallazgos que parecen sospechosos al principio no resultan, finalmente, vulnerabilidades explotables. La señal es intencionalmente más difícil de extraer de lo que sería en muchas bases de código empresariales, donde los patrones vulnerables pueden ser más frecuentes o estar menos examinados. Como resultado, un agente de IA tiene una mayor probabilidad de cometer errores al buscar candidatos a CVE en proyectos de código abierto maduros que al ayudar a identificar vulnerabilidades en software de clientes.

Nuestra producción pública, que comenzó a finales de abril de 2026, incluye hasta ahora 12 avisos únicos asociados con AI SAST: nueve problemas de XSS, dos de inyección SQL y uno de autorización. El XSS ocurre cuando el contenido controlado por el atacante llega a un contexto de ejecución del navegador sin suficiente escape o sanitización. La inyección SQL ocurre cuando una entrada controlada por el atacante altera la estructura o el comportamiento de una consulta de base de datos. Los problemas de autorización aparecen cuando la aplicación no logra imponer quién está autorizado a realizar una operación o acceder a un objeto.

La distribución refleja las categorías de debilidades que se están explorando actualmente. Nuestro escáner aún no está pensado para encontrar todos los tipos de vulnerabilidades. En este flujo de trabajo de investigación, se está aplicando a un conjunto limitado de tipologías donde el contexto es fundamental: si los datos están controlados por un atacante, si cruzan límites de archivos o funciones, si se almacenan y luego se renderizan, si una abstracción de base de datos construye un SQL inseguro o si falta una comprobación de autorización en la ruta real del backend.

Fluid Attacks otorga nombres en clave a sus avisos. Un ejemplo del flujo de trabajo de AI SAST es "Motley", el aviso de una inyección SQL en el backend MSSQL de Corteza. Ese informe es útil porque el comportamiento vulnerable involucraba el parsing de metadatos JSON, la falta de validación de claves, el escape incorrecto de T-SQL y el SQL generado. Otros avisos de AI SAST, como "Billie" para autorización incorrecta en Camaleon CMS, y "Pink", "Weeknd" y "Bizkit" para XSS almacenado, muestran el mismo patrón en diferentes clases de debilidades: el problema se confirma siguiendo el contexto, no confiando en una sola línea sospechosa.

Por qué el AI SAST y el SAST tradicional son complementarios

El SAST tradicional sigue siendo valioso porque muchas debilidades presentan patrones estables. Si un parámetro de solicitud se refleja en una respuesta sin validación, o si una función peligrosa conocida recibe datos no confiables, un escáner basado en reglas o guiado por el flujo de datos a menudo puede marcar el riesgo de manera eficiente. El objetivo del AI SAST no es reemplazar esa capacidad, sino cubrir los casos en los que el patrón es menos estable y el contexto circundante aporta una mayor parte del significado de seguridad.

Un contraste útil, por ejemplo, es "Skims-8", un aviso de Fluid Attacks detectado por nuestro escáner SAST tradicional. El reporte describe un problema de XSS reflejado en Ad Inserter, donde el contenido web se generaba dinámicamente sin validar un valor potencialmente no confiable. La línea vulnerable mostrada en el aviso es lo suficientemente directa como para que un escáner convencional la detecte: un valor POST se refleja de vuelta en la página.

Motley, aunque es un tipo diferente de debilidad, muestra que el problema de Corteza no era solo "la entrada llega a SQL". La ruta relevante involucraba un parámetro HTTP meta, parsing de objetos JSON, omisión de validación de claves, comportamiento de escape específico de MSSQL, SQL generado para rutas JSON y los permisos requeridos para llegar al endpoint afectado. Detectar ese tipo de problema requiere seguir cómo cambian los datos a través de funciones y archivos, y luego preguntarse si los controles en esa ruta son realmente efectivos.

Cada enfoque tiene un mejor ajuste: el SAST tradicional es fuerte para patrones estables con poca carga contextual, mientras que el AI SAST es prometedor para debilidades cuya explotabilidad depende de un contexto de código más amplio.

Para los clientes y los equipos de investigación, la mejor opción no es elegir un escáner sobre otro. Es combinarlos con la revisión humana para que los patrones simples se detecten de manera eficiente, las rutas complejas reciban un análisis más profundo y los informes finales estén respaldados por evidencia reproducible.

Qué nos está enseñando este trabajo

El trabajo de CVE de código abierto descrito aquí es un esfuerzo activo de investigación y experimentación. Estamos utilizando repositorios públicos para evaluar hasta dónde puede llegar el AI SAST en el descubrimiento de vulnerabilidades, dónde funciona bien y dónde sigue siendo necesaria la validación de expertos. El propósito no es presentar la IA como un reemplazo definitivo para la investigación de seguridad, sino aprender dónde puede acelerar, ampliar y precisar dicha investigación.

Al mismo tiempo, el AI SAST no es solo una idea de investigación. Fluid Attacks ofrece pruebas estáticas de seguridad de aplicaciones impulsadas por IA como parte de su enfoque de seguridad más amplio, donde las técnicas automatizadas, el análisis asistido por IA y el soporte de expertos trabajan en conjunto. Los hallazgos de código abierto nos brindan una forma transparente de mostrar parte de esa capacidad en acción: generación de candidatos, análisis de código contextual, triaje manual, evaluación de CVE y divulgación responsable.

Los avisos o advisories públicos de AI SAST publicados hasta ahora demuestran que esta técnica puede ayudar a identificar vulnerabilidades en proyectos de software reales, incluidos casos que requieren más contexto que un patrón de una sola línea. También dejan claro por qué el proceso debe seguir siendo cuidadoso: los hallazgos deben ser reproducidos, deduplicados, delimitados, documentados y divulgados a través de los canales adecuados.

Ese es el estándar que seguimos persiguiendo. En la investigación de código abierto, esto significa una mejor priorización de objetivos, una revisión de candidatos más sistemática y divulgaciones respaldadas por más evidencia. Para las organizaciones que crean y mantienen software, significa una forma práctica de expandir el análisis estático más allá de los patrones obvios. Si tu equipo desea ver cómo el AI SAST genera valor para los mantenedores y usuarios —no solo más alertas— y puede fortalecer tu AppSec, contáctanos.