Los agentes LLM de código abierto fallan en el escaneo SAST, según un estudio empírico

¿Qué es esto?

El 10 de junio de 2026, Derek Yohn, Luke Flancher, Mirajul Islam y Khaled Slhoub, del Florida Institute of Technology, publicaron Can Open-Source LLM Agents Replace Static Application Security Testing Tools? An Empirical Assessment (arXiv:2606.11672, cs.CR). La pregunta es oportuna: los equipos que entregan código generado por IA quieren cada vez más que un agente de IA también lo revise, y muchos equipos pequeños nunca integraron una herramienta real de Static Application Security Testing (SAST) en su pipeline.

Los autores construyeron un agente Python sencillo llamado Snitch, impulsado por turnos por tres modelos open-weight alojados en Ollama — gemma3 (Google), llama3.1 (Meta) y qwen2.5 (Alibaba) — y lo compararon con Bandit, una herramienta SAST de Python contrastada y basada en reglas, sobre tres repositorios de código abierto reales. Su conclusión es tajante: un agente LLM de código abierto de propósito general no es adecuado hoy para el escaneo SAST en condiciones realistas.

Cómo funciona

El montaje es un cara a cara limpio. Bandit y Snitch analizaron cada uno 224 archivos Python / 101 816 líneas de código repartidos en Beaverhabits (un rastreador de hábitos), Fail2ban (un daemon de seguridad) y Yum (el gestor de paquetes RPM, maduro). Las detecciones de severidad media/alta de Bandit se tomaron como referencia — 4 en Beaverhabits, 37 en Fail2ban, 0 en el código maduro de Yum. Snitch ejecutaba un prompt fijo de experto SAST pidiendo a cada modelo emitir JSON con los campos where, what, why y fix.

El rendimiento se midió como recall (proporción de detecciones M/H de Bandit también halladas, con crédito parcial) menos una tasa de falsos positivos, dando una puntuación compuesta de -1 a 1. Todas las celdas resultaron negativas:

Modelo	Beaverhabits (R / FP / Comp)	Fail2ban	Yum
gemma3	0,25 / 0,88 / -0,62	0,00 / 0,80 / -0,80	0,00 / 0,89 / -0,89
llama3.1	0,25 / 0,46 / -0,21	0,03 / 0,40 / -0,37	0,00 / 0,59 / -0,59
qwen2.5	0,25 / 0,28 / -0,03	0,01 / 0,14 / -0,12	0,00 / 0,40 / -0,40

El modo de fallo dominante fue la alucinación. El campo where — archivo y rango de líneas de cada problema — se fabricaba con frecuencia, apuntando a archivos o ubicaciones inexistentes. Solo el nombre de archivo capturado por separado permitió aprovechar la salida. Los modelos también confundieron patrones de ingeniería normales con vulnerabilidades: una configuración .env / dotenv señalada como secretos codificados, constantes de la biblioteca estándar como calendar.MONDAY señaladas como secretos, cabeceras de licencia y métodos «dunder» de Python señalados como inyecciones. qwen2.5 fue el menos malo (menos falsos positivos); gemma3 el peor. Los autores señalan que modelos cerrados o especializados, con mejor prompting, podrían rendir más — pero la magnitud de la brecha sugiere un problema estructural, no un artefacto de ajuste del prompt.

Por qué importa

Este es el reflejo defensivo de los trabajos recientes sobre agentes cazadores de vulnerabilidades como Code-Augur y los benchmarks de búsqueda de bugs a largo horizonte: al retirar el andamiaje, un modelo genérico puesto frente a una base de código rinde menos que un detector de patrones de los años noventa. El peligro no es que el agente no encuentre nada — es que produce una salida fluida y segura pero esencialmente ruido, empujando a los desarrolladores a «arreglar» no-problemas mientras las detecciones reales se ahogan. Esa falsa confianza es en sí una superficie de riesgo, y agrava los problemas de confianza ya documentados en torno a la ergonomía de los LLM de código y los defectos de código introducidos por la IA. La velocidad lo empeora: Bandit procesaba cada repositorio en menos de un minuto, mientras que Snitch tardaba de una a cuatro horas por repositorio (~672 llamadas LLM, 10-12 horas en total).

Defensas

Para los equipos que sopesan un agente LLM como escáner de seguridad, los puntos prácticos:

1. Mantén la herramienta determinista como fuente de verdad. El SAST basado en reglas (Bandit, Semgrep, CodeQL) es rápido, reproducible, explicable y ligado a CVE. Trata al LLM como una pasada secundaria opcional, nunca como la barrera.
2. No confíes nunca en los números de línea de un LLM. El campo where alucinaba con regularidad; toda detección del agente debe re-anclarse al código fuente real antes de que un humano actúe.
3. Espera un torrente de falsos positivos. Ajusta los filtros para los patrones .env/dotenv, constantes-como-secretos y comentarios/licencias vistos en el estudio — o enseñarás a los desarrolladores a ignorar la herramienta.
4. Mide antes de adoptar. Reproduce la métrica barata del estudio — recall y tasa de falsos positivos frente a una referencia contrastada, sobre tu código — en vez de fiarte de una demo de un proveedor.
5. Usa los LLM donde son fuertes. Es notable que los investigadores usaron Claude para generar el script de cotejo que analizó la salida ruidosa — LLM-asistente de un pipeline determinista, no LLM-escáner.

Estado

Elemento	Referencia	Fecha	Notas
Evaluación empírica	arXiv:2606.11672	2026-06-10	Agente Snitch vs Bandit, 224 archivos / 101 816 LOC
Modelos probados	gemma3, llama3.1, qwen2.5 (vía Ollama)	2026-06-10	Modelos open-weight de propósito general
Mejor compuesto	qwen2.5	2026-06-10	Negativo en los tres repositorios aun así
Herramienta de referencia	Bandit (PyCQA)	—	SAST de Python basado en reglas, ligado a CVE

La conclusión: a mediados de 2026, un agente LLM de código abierto de propósito general es un mal sustituto de una herramienta SAST determinista — falsos positivos altos, ubicaciones fabricadas y horas de ejecución. El patrón útil es el inverso del discurso dominante: deja que las herramientas probadas hagan la detección, y deja que el modelo ayude en el triaje y la explicación bajo supervisión humana.