💻 computer science

Vulnerability Detection with Interprocedural Context in Multiple Languages: Assessing Effectiveness and Cost of Modern LLMs

Este estudio evalúa la efectividad, el costo y la calidad de las explicaciones de cuatro modelos de lenguaje modernos en la detección de vulnerabilidades interprocedimentales en C, C++ y Python, demostrando que incorporar contexto de llamadas mejora significativamente la precisión y ofrece soluciones rentables para herramientas de análisis de seguridad asistidas por IA.

Autores originales: Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

Publicado 2026-04-10

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

¡Claro que sí! Imagina que este artículo es como una prueba de conducir para cuatro coches de última generación (los modelos de Inteligencia Artificial), pero en lugar de conducir por una carretera normal, tienen que encontrar agujeros en el asfalto (vulnerabilidades de seguridad) en tres tipos de vehículos diferentes: camiones pesados (C), furgonetas (C++) y coches deportivos ligeros (Python).

Aquí tienes la explicación sencilla, usando analogías cotidianas:

🕵️‍♂️ El Problema: Mirar solo una pieza del rompecabezas

Antes de este estudio, los expertos en seguridad solían pedirle a la IA que mirara solo una habitación de una casa para ver si había un ladrón. Pero, ¿y si el ladrón no está en la habitación, sino que entra desde el pasillo o sale por la ventana de la cocina?

Muchas vulnerabilidades de seguridad no ocurren dentro de una sola función de código (una sola habitación), sino que dependen de cómo una función habla con otra (el pasillo y la cocina). El estudio quería saber: ¿Es mejor pedirle a la IA que mire solo la habitación, o que también mire quién entra y quién sale de ella?

🧪 La Prueba: Los 4 "Detectives" y sus 3 Lentes

Los investigadores tomaron 509 casos reales de fallos de seguridad y les dieron a cuatro modelos de IA famosos (Claude Haiku 4.5, GPT-4.1 Mini, GPT-5 Mini y Gemini 3 Flash) tres formas de mirar el código:

Lente Aislado: Solo la función problemática.
Lente de "Vecinos": La función + las funciones a las que llama (callees).
Lente de "Jefes": La función + las funciones que la llaman (callers).

Además, midieron cuánto les costó a los investigadores usar estos detectives (en dinero) y qué tan bien explicaban sus hallazgos.

🏆 Los Resultados Sorprendentes

1. "Más información" no siempre es mejor (El ruido del tráfico)

La idea común era que "si le das más contexto a la IA, será más inteligente". Falso.

La analogía: Imagina que intentas escuchar una conversación importante en una fiesta. Si te pones unos auriculares que aíslan el ruido (solo la función), escuchas bien. Pero si te pones unos auriculares que te dejan escuchar toda la fiesta (el contexto interprocedural), a veces el ruido de fondo te confunde y pierdes la conversación.
Lo que pasó: Para los modelos de "OpenAI" (GPT), darle más contexto (ver a los vecinos o a los jefes) los confundió. Su precisión bajó drásticamente (hasta un 25% menos). En cambio, los modelos de "Anthropic" (Claude) y "Google" (Gemini) fueron como detectives con oídos de lince: no les importó el ruido extra, mantuvieron su enfoque y su precisión se mantuvo estable.

2. El equilibrio entre Precio y Calidad (La cuenta del restaurante)

Usar IA cuesta dinero (se paga por cada palabra que la IA lee y escribe).

La analogía: Añadir contexto es como pedir una ensalada gigante en lugar de una pequeña. Te llena más (más palabras), pero ¿te da más sabor (mejor detección)?
El hallazgo: Añadir contexto duplicó el costo (más palabras = más dinero) pero no mejoró la detección. Al contrario, a menudo la empeoró.
El ganador económico: Gemini 3 Flash fue el mejor "cocinero" en relación precio-calidad. Detectó casi todo lo que tenía que detectar en el lenguaje C gastando muy poco dinero (aprox. 50 centavos por configuración).

3. La explicación (El "Por qué" importa)

No basta con decir "Aquí hay un error". Un buen detective debe explicar por qué es un error y cómo arreglarlo.

El ganador de la explicación: Claude Haiku 4.5 fue el mejor redactor. En el 93.6% de los casos, no solo encontró el fallo, sino que escribió una explicación perfecta, clara y útil.
Los perdedores: Los modelos de GPT a veces encontraban el error pero escribían explicaciones confusas o, peor aún, decían que había un error cuando no lo había (alucinaciones).

🌍 ¿Importa el idioma? (C, C++ y Python)

Sí, el "idioma" del código importa.

C y C++ (Los camiones pesados): Son lenguajes donde el manejo de la memoria es manual (como conducir un camión sin frenos automáticos). Aquí, el contexto extra confundió mucho a los modelos GPT.
Python (El coche deportivo): Es más seguro por sí mismo. Aquí, los resultados fueron más estables, pero la tendencia de "menos contexto es mejor" se mantuvo.

💡 La Lección Principal para el Futuro

Si quieres construir una herramienta de seguridad con IA:

No asumas que "más es mejor": A veces, dar demasiada información a la IA la confunde.
Elige tu detective según tu presupuesto:
- Si quieres la mejor explicación para entender el problema: Usa Claude Haiku 4.5.
- Si quieres el mejor equilibrio entre precio y detección rápida: Usa Gemini 3 Flash.
- Si usas modelos baratos (GPT Mini), ten cuidado: podrían confundirse si les das demasiada información de fondo.

En resumen: A veces, para encontrar un fallo de seguridad, es mejor mirar la pieza clave con lupa y silencio, que intentar escuchar todo el ruido de la fábrica al mismo tiempo. Y, por supuesto, elige al detective que mejor se ajuste a tu bolsillo y a tu necesidad de explicaciones.

Título del Estudio

Detección de Vulnerabilidades con Contexto Interprocedimental en Múltiples Lenguajes: Evaluación de la Efectividad y el Costo de los LLMs Modernos

1. Problema

La detección automatizada de vulnerabilidades de software es crítica, pero la literatura existente presenta dos limitaciones principales:

Alcance Funcional Limitado: La mayoría de los estudios anteriores evalúan a los Modelos de Lenguaje Grande (LLMs) solo dentro de funciones individuales, ignorando las vulnerabilidades que surgen de dependencias interprocedimentales (flujos de datos y control que cruzan múltiples funciones). Esto deja sin detectar fallos como use-after-free, desbordamientos de búfer o inyecciones mediadas por argumentos de llamadas externas.
Falta de Generalización y Análisis de Costos: Los estudios suelen centrarse en un solo lenguaje de programación y rara vez evalúan el costo económico (inferencia) o la calidad de las explicaciones generadas por los modelos, factores esenciales para la escalabilidad en entornos reales.

2. Metodología

Los autores realizaron un estudio empírico riguroso para evaluar cuatro LLMs modernos: Claude Haiku 4.5, GPT-4.1 Mini, GPT-5 Mini y Gemini 3 Flash.

Dataset: Se utilizaron 509 vulnerabilidades extraídas del dataset ReposVul, cubriendo tres lenguajes: C, C++ y Python.
Configuraciones de Contexto: Se varió sistemáticamente la información proporcionada al modelo en tres configuraciones:
1. Solo Código (CO): Solo la función objetivo.
2. Código + Calles (CC): Función objetivo + funciones que invoca (callees).
3. Código + Llamadores (CK): Función objetivo + funciones que la invocan (callers).
Métricas de Evaluación:
- Efectividad: Precisión, Recall (equivalente a la precisión en este conjunto de datos desbalanceado) y F1-score.
- Eficiencia: Costo económico por configuración basado en el consumo de tokens (USD).
- Calidad Explicativa: Evaluación manual de 986 explicaciones generadas bajo dos dimensiones: Correctitud (identificación correcta del tipo y ubicación) y Exhaustividad (inclusión de vectores de ataque y sugerencias de reparación). Se utilizó una escala de 0 a 2.
Análisis Estadístico: Se aplicó la prueba de McNemar con corrección Holm-Bonferroni para determinar la significancia estadística de las diferencias entre configuraciones.

3. Contribuciones Clave

Evaluación Multilingüe y Multilenguaje: Uno de los primeros estudios que compara sistemáticamente el rendimiento de LLMs en la detección de vulnerabilidades interprocedimentales a través de C, C++ y Python.
Análisis de Costo-Beneficio: Cuantificación real del costo de inferencia frente a la mejora (o degradación) en la precisión al añadir contexto.
Evaluación de Explicaciones: Una evaluación cualitativa detallada de la capacidad de los modelos para justificar sus decisiones de seguridad, no solo clasificarlas.
Hallazgo Contraintuitivo: Demostración de que "más contexto" no siempre es mejor; en muchos casos, añadir contexto interprocedimental degrada el rendimiento.

4. Resultados Principales

A. Efectividad y Contexto (RQ1)

El contexto no mejora consistentemente la detección: En la mayoría de los casos, la configuración con menos contexto (Solo Código - CO) obtuvo los mejores resultados.
Degradación en modelos GPT: Para los modelos GPT (especialmente GPT-4.1 Mini y GPT-5 Mini) en C, añadir contexto (callers o callees) redujo la precisión drásticamente (hasta un 25% en GPT-4.1 Mini). Se hipotetiza que estos modelos introducen "ruido" o se distraen con información irrelevante.
Robustez en Claude y Gemini: Claude Haiku 4.5 y Gemini 3 Flash mostraron gran estabilidad, manteniendo su rendimiento independientemente de la configuración de contexto.

B. Influencia del Lenguaje (RQ2)

C: Es el lenguaje donde la degradación por contexto es más pronunciada en los modelos GPT.
Python: Muestra tendencias similares pero menos severas; el contexto no mejoró significativamente la detección.
C++: El tamaño de la muestra fue demasiado pequeño para conclusiones estadísticas fiables, aunque los modelos lograron alta precisión en CO.

C. Eficiencia y Costo (RQ3)

Doble de costo sin ganancia proporcional: Añadir contexto interprocedimental casi duplica el consumo de tokens y, por tanto, el costo de inferencia, sin ofrecer mejoras de precisión proporcionales.
Mejor equilibrio Costo-Rendimiento: Gemini 3 Flash se destaca como la opción más eficiente para vulnerabilidades en C, logrando un F1 ≥ 0.978 con un costo estimado de $0.50–$ 0.58 por configuración.
Claude Haiku 4.5: Aunque tiene un costo más alto, ofrece la mejor calidad de explicación.

D. Calidad de las Explicaciones (RQ4)

Claude Haiku 4.5 lideró en calidad explicativa, identificando y explicando correctamente la vulnerabilidad en el 93.6% de los casos evaluados, con puntuaciones perfectas (2,2) en la mayoría de las muestras.
Los modelos GPT mostraron tasas de error cero (explicaciones fundamentalmente incorrectas) cinco veces más altas que Claude y Gemini.
Existe una correlación: los modelos que fallan más en la detección también tienden a generar explicaciones menos precisas.

5. Significado e Implicaciones

Diseño de Herramientas de Seguridad: Los desarrolladores de herramientas asistidas por IA no deben asumir que "más contexto es mejor". La estrategia de ingeniería de prompts debe calibrarse según el modelo específico y el lenguaje de programación.
Selección de Modelos: No existe un modelo único dominante.
- Para equilibrio costo-precisión: Usar Gemini 3 Flash.
- Para explicaciones detalladas y auditoría: Usar Claude Haiku 4.5.
- Evitar modelos GPT Mini para contextos interprocedimentales complejos en C, ya que el ruido degrada su rendimiento.
Generalización: Los hallazgos sugieren que los LLMs modernos pueden generalizar bien a través de bases de código en múltiples lenguajes si se selecciona el modelo adecuado y se gestiona el contexto de entrada de forma inteligente.

En conclusión, el estudio demuestra que la detección de vulnerabilidades interprocedimentales es viable con LLMs, pero requiere una gestión cuidadosa del contexto de entrada para evitar la degradación del rendimiento y optimizar los costos operativos.