Extracting Recurring Vulnerabilities from Black-Box LLM-Generated Software

Este artículo presenta FSTab, un marco de ataque en caja negra que demuestra cómo las vulnerabilidades recurrentes en software generado por LLMs pueden predecirse a partir de características observables y evalúa la consistencia de estas fallas en modelos de última generación como GPT-5.2, Claude-4.5 Opus y Gemini-3 Pro, revelando un riesgo de seguridad significativo y transferible entre dominios.

Lo esencial

Imagina que estás construyendo una casa. En lugar de contratar a un arquitecto humano, decides usar un robot constructor ultra-inteligente (una Inteligencia Artificial) que ha leído millones de planos de casas anteriores. Le dices: "Constrúyeme una cocina con una ventana y una puerta".

El robot lo hace rápido, pero tiene un hábito extraño: siempre pone la cerradura de la puerta en el mismo lugar, y por si acaso, siempre deja la ventana abierta en la cocina, sin importar si la casa es para una familia o para una oficina.

Este es el problema que descubren los autores de este paper.

El Problema: El "Robot" tiene Manos Duras

Los modelos de lenguaje (como GPT, Claude o Gemini) son muy buenos escribiendo código, pero tienen un defecto: son predecibles. Cuando les pides que hagan algo común (como un formulario de inicio de sesión o una subida de archivos), tienden a usar los mismos "patrones" o plantillas una y otra vez.

El problema es que, a menudo, esos patrones tienen agujeros de seguridad. Es como si el robot siempre dejara la llave bajo el felpudo de la entrada. Si un ladrón sabe que el robot construyó la casa, no necesita revisar cada habitación; solo tiene que ir directo al felpudo.

La Solución: La "Tabla de Seguridad" (FSTab)

Los investigadores crearon una herramienta llamada FSTab (Feature–Security Table). Imagina que es un diccionario de detectives.

1. La Observación (Frente): El atacante mira solo la parte visible de la aplicación (la interfaz web, los botones, los menús). Ve, por ejemplo, un botón que dice "Subir Archivo".
2. La Predicción (Detrás): Gracias a la FSTab, el atacante sabe: "¡Ajá! Si el robot 'GPT-5' puso un botón de 'Subir Archivo', es 94% probable que haya dejado una puerta trasera abierta en el servidor para robar datos".

La analogía clave:
Imagina que el robot es un chef que siempre cocina la misma sopa.

• Si ves que el chef puso cebolla en la sopa (una característica visible), sabes que también puso sal (una característica oculta), porque siempre lo hace así.
• En este caso, si ves un formulario de login (cebolla), sabes que hay una vulnerabilidad de seguridad (sal) oculta en el código, aunque no puedas ver el código.

¿Qué descubrieron?

Los investigadores probaron esto con los robots más famosos (GPT-5.2, Claude-4.5, etc.) y descubrieron cosas sorprendentes:

• El "Huella Digital" del Robot: Cada modelo de IA tiene su propio estilo de cometer errores. Un modelo siempre olvida poner una cerradura en la puerta trasera; otro siempre deja la ventana abierta. Es como si cada robot tuviera su propia "firma" de inseguridad.
• Funciona en cualquier lugar: Si aprendes los errores del robot en una aplicación de "Tienda Online", puedes usar ese conocimiento para hackear una aplicación de "Red Social" hecha por el mismo robot. Los errores viajan de un tema a otro.
• No necesitas ver el código: Lo más peligroso es que un atacante no necesita ver el código interno para saber dónde están los agujeros. Solo necesita ver qué hace la aplicación por fuera y consultar la "Tabla de Seguridad" del modelo que la creó.

¿Por qué es importante?

Hasta ahora, pensábamos que para encontrar errores de seguridad teníamos que revisar todo el código línea por línea (como revisar cada ladrillo de la casa).

Este paper nos dice: "No, no necesitas revisar todo". Si sabes qué robot construyó la casa, puedes ir directo a los puntos débiles que ese robot suele dejar.

En resumen

Este estudio nos advierte que, al usar Inteligencia Artificial para crear software, estamos introduciendo un nuevo tipo de riesgo: la repetición de errores.

Es como si todos los coches fabricados por una fábrica defectuosa tuvieran el mismo fallo en el freno. Si eres un conductor (o un hacker), no necesitas inspeccionar el motor de cada coche; solo necesitas saber que el coche salió de esa fábrica y ya sabes dónde fallará.

La lección: Necesitamos aprender a "reconocer la firma" de estos robots para poder proteger lo que ellos construyen antes de que sea demasiado tarde.

Resumen técnico

Resumen Técnico: Extracción de Vulnerabilidades Recurrentes en Software Generado por LLMs

1. El Problema

Los Modelos de Lenguaje Grande (LLMs) se han convertido en componentes centrales para la generación de código automatizado. Sin embargo, existe un riesgo de seguridad crítico y subestimado: los LLMs tienden a generar código siguiendo plantillas recurrentes inducidas por su muestreo probabilístico. Esto significa que, incluso sin acceso al código fuente (entorno de caja negra), un modelo específico puede reproducir sistemáticamente los mismos patrones de diseño inseguros a través de diferentes programas, dominios y reescrituras de prompts.

El problema actual es que las defensas existentes (como analizadores estáticos o benchmarks de seguridad) evalúan cada pieza de código de forma aislada. No modelan las regularidades cruzadas inducidas por el modelo generador, dejando un "punto ciego" crítico: la incapacidad de predecir vulnerabilidades ocultas en el backend basándose únicamente en las características observables del frontend.

2. Metodología: FSTab (Feature–Security Table)

Los autores proponen FSTab, un marco de trabajo que opera como una tabla de búsqueda probabilística para atacar y evaluar software generado por LLMs.

• Concepto Central: FSTab mapea características observables del frontend (ej. "botón de inicio de sesión", "subir archivo") a vulnerabilidades latentes del backend (identificadas por reglas de seguridad como CWE o IDs de CodeQL).
• Suposición de Ataque (Caja Negra): El atacante solo necesita conocer la identidad del modelo generador (ej. GPT-5.2, Claude-4.5) y las funcionalidades visibles de la aplicación. No requiere acceso al código fuente.
• Proceso de Construcción:
  1. Generación de Corpus: Se generan grandes cantidades de aplicaciones usando un LLM objetivo.
  2. Etiquetado: Se utilizan analizadores estáticos (CodeQL, Semgrep) para identificar vulnerabilidades reales en el backend y escáneres para extraer características del frontend.
  3. Cálculo de Puntuación (PMI): Para evitar que las reglas comunes dominen la tabla, se utiliza la Información Mutua Puntual (PMI) para medir la asociación entre una característica $f$ y una vulnerabilidad $r$.
     $$S_{PMI}(f, r) = \log \frac{\hat{P}(r|f)}{\hat{P}(r)}$$
  4. Selección Diversa: Se aplica un algoritmo greedy con una penalización de diversidad ($\lambda$) para asegurar que la tabla capture un conjunto variado de vulnerabilidades discriminativas en lugar de mapear la misma regla genérica a todas las características.

3. Métricas de Evaluación Propuestas

El artículo introduce un marco de evaluación centrado en el modelo para cuantificar la persistencia de las vulnerabilidades:

1. FVR (Feature Vulnerability Recurrence): Frecuencia con la que una característica específica (ej. "Login") desencadena la misma vulnerabilidad en diferentes programas.
2. RVP (Rephrasing Vulnerability Persistence): Persistencia de la vulnerabilidad cuando el prompt se reescribe manteniendo la semántica.
3. DVR (Domain Vulnerability Recurrence): Recurrencia de patrones dentro del mismo dominio de aplicación (ej. comercio electrónico).
4. CDT (Cross-Domain Transfer): Capacidad de predecir vulnerabilidades en un dominio objetivo utilizando una FSTab construida con datos de otros dominios.

4. Resultados Experimentales

Los autores evaluaron seis LLMs de última generación (GPT-5.2, Claude-4.5 Opus, Gemini-3 Pro, Gemini-3 Flash, Composer, Grok) en cinco dominios (E-commerce, Herramientas Internas, Redes Sociales, Blogs, Dashboards).

• Eficacia del Ataque (Black-Box):

  • FSTab logró tasas de éxito de ataque (ASR) muy altas, llegando hasta el 100% en dominios como E-commerce y Herramientas Internas para modelos como GPT-5.2 y Composer.
  • Incluso en escenarios de transferencia cruzada (donde el dominio objetivo no se usó para construir la tabla), se mantuvieron tasas de éxito superiores al 75-90% (ej. 94% en Herramientas Internas con Claude-4.5).
  • Esto demuestra que las vulnerabilidades son arquitectónicas (intrínsecas al modelo) y no dependen del dominio específico.

• Persistencia y Patrones:

  • RVP: Modelos como Composer mostraron una alta persistencia (~50%), indicando que sus errores de seguridad son robustos frente a cambios en la redacción del prompt.
  • Huella Digital del Modelo: Cada modelo desarrolló un "patrón de vulnerabilidad" único. Por ejemplo, Composer tenía una rigidez extrema en operaciones de datos, mientras que Grok mostraba más variabilidad pero aún con patrones predecibles.
  • Brecha de Universalidad: Se observó que la transferencia entre dominios (CDT) fue a menudo mayor que la recurrencia dentro del mismo dominio (DVR), confirmando que las vulnerabilidades son inherentes al modelo generador.

5. Contribuciones Clave

1. Ataque Universal de Caja Negra: Presentación de FSTab, un método que permite inferir vulnerabilidades de backend sin acceso al código, solo con la identidad del modelo y la interfaz visible.
2. Marco de Evaluación Centrada en el Modelo: Introducción de métricas (FVR, RVP, DVR, CDT) para medir la estabilidad de los patrones de inseguridad en los generadores de código, permitiendo comparar modelos no por su capacidad de generar código, sino por su tendencia a reproducir fallos.
3. Caracterización Empírica: Demostración de que los patrones de vulnerabilidad son persistentes y específicos del modelo a través de múltiples dominios, exponiendo una superficie de ataque previamente no explorada.

6. Significado e Impacto

• Nueva Superficie de Ataque: El trabajo revela que la seguridad del software generado por IA no es solo un problema de "código defectuoso", sino de sesgos de generación sistemáticos. Un atacante puede "perfilarse" un modelo en una aplicación simple y usar ese conocimiento para comprometer aplicaciones críticas en dominios totalmente diferentes.
• Implicaciones Defensivas:
  • Se necesita un cambio de paradigma: pasar de analizar el código final a evaluar la persistencia de riesgos en el modelo generador.
  • Se sugieren mitigaciones como la reducción de la rigidez de las plantillas, la aplicación de reescrituras de código sensibles a la seguridad post-generación y la implementación de pruebas de regresión condicionadas a características de alto riesgo.
• Responsabilidad: Los autores omiten deliberadamente los payloads de explotación específicos, presentando FSTab como una herramienta de diagnóstico y priorización de riesgos para auditorías proactivas, en lugar de un manual de explotación.

En conclusión, el artículo demuestra que los LLMs de código no son generadores aleatorios, sino que poseen "huellas dactilares de vulnerabilidad" predecibles. Esto representa un desafío fundamental para la seguridad del software moderno, ya que la escala de la generación automatizada podría amplificar estos fallos recurrentes a nivel global.