💻 computer science

Security in a Workflow: Exploring Role-Based Agentic Architectures for Vulnerability Handling

Este artículo propone y evalúa un flujo de trabajo agéntico basado en roles que comprende agentes Planificador, Analizador, Reparador y Verificador para cerrar la brecha entre las tareas de seguridad de LLM aisladas y las prácticas industriales del mundo real, demostrando una precisión de detección de vulnerabilidades del 44% y una precisión de reparación del 19% en 25 vulnerabilidades reales de C/C++.

Autores originales: Srijita Basu, Miroslaw Staron

Publicado 2026-06-15

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Srijita Basu, Miroslaw Staron

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

Imagina que estás intentando reparar una casa muy antigua y compleja (un programa de software escrito en C o C++) que tiene grietas ocultas y puntos débiles (vulnerabilidades de seguridad). En el pasado, podrías haber contratado a un único detective superinteligente (una IA estándar) para que examinara la casa, encontrara las grietas e intentara parchar todas a la vez. A veces este detective acierta, pero a menudo se siente abrumado, pasa por alto pistas sutiles o parchea la pared equivocada.

Este artículo propone un enfoque diferente: contratar a un equipo de agentes especializados en lugar de a un detective solitario. Trabajan juntos en una línea de montaje estricta, donde cada uno tiene un trabajo específico.

Aquí explicamos cómo funciona el equipo, utilizando los hallazgos del artículo:

1. Los roles del equipo (El "Flujo de Trabajo Agéntico")

Los investigadores configuraron un equipo digital con cuatro roles distintos, similares a una cuadrilla de construcción:

El Planificador (El Jefe de Obra): Antes de que nadie empiece a excavar, este agente escanea los planos (el código) para detectar puntos problemáticos obvios. No arregla nada; simplemente señala al equipo hacia las áreas que parecen sospechosas, como "Revisa la puerta trasera" o "Mira los cimientos".
- Hallazgo clave: El artículo encontró que tener este "Jefe de Obra" era crucial. Cuando eliminaron este rol, la capacidad del equipo para encontrar problemas cayó casi a la mitad.
El Analista (El Inspector): Este es el detective principal. Toma las pistas del Planificador y el código bruto para comprender exactamente qué está roto, por qué está roto y cómo podría entrar un ladrón.
- Hallazgo clave: Los investigadores intentaron darle a este agente un detector de metales de alta tecnología (una herramienta llamada CodeQL) para ayudar a encontrar las grietas. Sorprendentemente, el detector de metales no siempre ayudó. A veces daba demasiadas falsas alarmas, confundiendo al Inspector. Los mejores resultados se obtuvieron cuando el propio modelo de IA realizaba el pensamiento profundo, en lugar de depender excesivamente de la herramienta adicional.
El Reparador (El Albañil): Una vez que el Inspector dice: "El marco de la puerta se está pudriendo", el Reparador intenta construir una puerta nueva. Escribe el código para tapar el agujero.
- Hallazgo clave: Este fue el trabajo más difícil. Mientras que el equipo fue bastante bueno encontrando el problema (con un 44% de precisión), arreglarlo correctamente fue mucho más difícil (solo un 19% de precisión). A menudo, el Reparador parcheaba el agujero pero, accidentalmente, rompía algo cercano o añadía partes innecesarias.
El Verificador (El Inspector de Seguridad): Después de que se realiza la reparación, este agente supervisa el trabajo. Pregunta: "¿Realmente arreglaste la podredumbre? ¿Hiciste la casa más segura o solo pintaste encima de la grieta?".
- Hallazgo clave: Este rol fue bastante bueno para detectar errores, capturando aproximadamente el 69% de los errores en las reparaciones.

2. El Experimento

Los investigadores probaron este equipo en 25 vulnerabilidades de seguridad reales encontradas en software popular de C/C++ (como el que se utiliza en sistemas críticos para la seguridad). Utilizaron tres "cerebros" diferentes (modelos de IA) para alimentar a los miembros del equipo.

Compararon dos versiones del equipo:

Equipo A: Solo los cuatro roles comunicándose entre sí.
Equipo B: Los mismos cuatro roles, pero el Inspector recibió el detector de metales CodeQL para ayudar a encontrar las grietas.

3. Lo que descubrieron

El "Gerente" es lo más importante: La parte más importante del proceso fue el Planificador. Sin un gerente que guíe al equipo sobre dónde mirar, la IA se perdía. Con el gerente, el equipo rindió tan bien como una IA comercial de primer nivel (GPT-5.5) al encontrar los errores.
Las herramientas no son mágicas: Darle al Inspector una herramienta sofisticada (CodeQL) no lo hizo automáticamente mejor. De hecho, a veces empeoraba las cosas porque la IA tenía dificultades para interpretar correctamente los datos de la herramienta. El artículo sugiere que para lenguajes informáticos de bajo nivel (como C), la IA necesita ser lo suficientemente inteligente como para priorizar las pistas por sí misma.
Encontrar frente a Reparar: Es mucho más fácil para la IA encontrar un agujero de seguridad que repararlo. El equipo encontraba los errores aproximadamente el 44% de las veces, pero solo los reparaba correctamente el 19% de las veces.
El toque humano sigue siendo necesario: Debido a que el "Reparador" (Fixer) a menudo cometía errores o añadía cambios innecesarios, el artículo concluye que en la seguridad real no se puede dejar que la IA tome el control por sí sola. Se necesita a un humano vigilando por encima del hombro de la IA, verificando las reparaciones y asegurándose de que la casa sea realmente segura.

La Conclusión

Este artículo no afirma que la IA pueda ahora asegurar el software perfectamente por sí sola. En cambio, demuestra que organizar la IA en un equipo estructurado con roles claros es una mejor manera de gestionar la seguridad que dejar que una sola IA lo haga todo. Sin embargo, incluso con un gran equipo, la parte de "reparar" sigue siendo complicada, y los expertos humanos siguen siendo esenciales para verificar el trabajo.

Resumen Técnico: Seguridad en un Flujo de Trabajo – Exploración de Arquitecturas Agénticas Basadas en Roles para el Manejo de Vulnerabilidades

Declaración del Problema

La ingeniería de software segura en la práctica industrial implica un flujo de trabajo estructurado y de múltiples etapas que comprende el análisis de vulnerabilidades, la remediación y la verificación de la corrección. Sin embargo, los enfoques actuales basados en Modelos de Lenguaje de Gran Escala (LLM) para la seguridad del software suelen ser fragmentados, centrándose en tareas aisladas como la detección o la generación de parches, en lugar de reflejar los flujos de trabajo agénticos de extremo a extremo utilizados en los procesos de seguridad del mundo real. Esto crea una brecha entre los métodos actuales de LLM y la ingeniería de software segura práctica, particularmente para lenguajes de sistemas de bajo nivel como C y C++. En estos lenguajes, las vulnerabilidades dependen de semánticas de memoria complejas, manipulación de punteros y gestión de buffers, lo que hace que el diagnóstico y la remediación sean desafiantes para los LLM. Además, existe una exploración limitada de los flujos de trabajo agénticos aumentados por herramientas y la integración de habilidades del Protocolo de Contexto de Modelo (MCP) específicamente para estos contextos de bajo nivel.

Metodología

Los autores proponen y evalúan un flujo de trabajo agéntico basado en roles diseñado para descomponer el manejo de vulnerabilidades en etapas explícitas: planificación de la investigación, análisis de vulnerabilidad, generación de parches y verificación de la corrección.

Diseño del Flujo de Trabajo

El estudio implementa dos variantes de flujo de trabajo utilizando el marco CrewAI, instanciado con tres LLM de código abierto: nemotron-cascade-2:30b, qwen3-coder-next y gpt-oss:120b. Los flujos de trabajo constan de cuatro roles distintos:

Planificador (Planner): Un módulo estático basado en reglas (no es un LLM) que escanea el código C de entrada en busca de patrones de vulnerabilidad predefinidos (por ejemplo, desbordamientos de buffer, desreferencia de puntero nulo) utilizando expresiones regulares. Produce regiones y temas de investigación priorizados para guiar al Analista.
Analista (Analyzer): Un agente de LLM responsable del diagnóstico técnico. Determina la vulnerabilidad primaria, asigna el ID de la Clasificación de Debilidades Comunes (CWE), identifica las líneas vulnerables, explica la causa raíz y rastrea el flujo de origen a sumidero (source-to-sink).
- Flujo de Trabajo 1: El Analista depende únicamente de la guía del Planificador.
- Flujo de Trabajo 2: El Analista está aumentado con la integración de MCP CodeQL, proporcionando capacidades de análisis estático durante el diagnóstico.
Corregidor (Fixer): Un agente de LLM que genera un parche seguro y mínimo basado en el diagnóstico del Analista. Está restringido a producir el parche y una explicación concisa, evitando el rediagnóstico.
Verificador (Verifier): Un agente de LLM independiente que evalúa si el parche generado resuelve la vulnerabilidad identificada, elimina la causa raíz y evita la introducción de regresiones.

Configuración Experimental

Conjunto de Datos: Un conjunto curado de 25 CVE (Vulnerabilidades y Exposiciones Comunes) reales de C/C++ que abarcan cinco categorías de CWE: CWE-787 (Escritura fuera de límites), CWE-476 (Desreferencia de Puntero Nulo), CWE-190 (Desbordamiento de Entero), CWE-125 (Lectura fuera de límites) y CWE-191 (Subdesbordamiento de Entero).
Verdad de Terreno (Ground Truth): Derivada de las descripciones de la National Vulnerability Database (NVD) y del código parcheado proporcionado por los desarrolladores.
Evaluación: Evaluación manual basada en rúbricas realizada por dos autores (kappa de Cohen $\kappa = 0.83$ ) comparando los resultados de los agentes contra la verdad de terreno. Las métricas incluyeron la precisión de detección (asignación de CWE, identificación de líneas, causa raíz) y la precisión de la corrección (similitud semántica con los parches de confianza).
Alcance: El estudio es una evaluación exploratoria orientada a la metodología en lugar de un benchmark a gran escala, centrándose en 150 ejecuciones de flujo de trabajo (25 CVEs $\times$ 3 modelos $\times$ 2 variantes).

Contribuciones Clave

Arquitectura Agéntica Basada en Roles: Propuesta y evaluación de un flujo de trabajo de extremo a extremo que separa la planificación, el análisis, la corrección y la verificación, demostrando cómo la separación explícita de roles puede estructurar las actividades de seguridad.
Diseño de Planificador Estático: Implementación de un planificador basado en reglas para guiar la investigación de vulnerabilidades en proyectos C relevantes para la industria, mostrando su impacto crítico en la calidad de la detección.
Conjunto de Referencia Curado: Provisión de 25 instancias de vulnerabilidades reales de C/C++ con metadatos de verdad de terreno, parches de desarrolladores y salidas de LLM, junto con el código del marco CrewAI de código abierto para la reproducibilidad.
Análisis de Integración de Herramientas: Investigación sobre la eficacia de integrar el análisis estático basado en MCP (CodeQL) en la etapa de análisis de un flujo de trabajo multi-agente.

Resultados

El estudio reporta las siguientes métricas de rendimiento (utilizando nemotron-cascade-2:30b como el modelo principal para la comparación):

Precisión de Detección:
- Flujo de Trabajo 1 (Sin CodeQL): Logró una precisión de detección del 44%, comparable a las líneas base de GPT-5.5.
- Flujo de Trabajo 2 (Con CodeQL): La precisión cayó al 31%, lo que sugiere que la integración de herramientas por sí sola no garantiza la mejora si el agente no puede interpretar o priorizar correctamente las pistas de la herramienta.
- Ablación: Eliminar el Planificador redujo la precisión de detección al 25% (sin CodeQL) y al 19% (con CodeQL), subrayando el papel crítico del Planificador.
Precisión de la Corrección:
- La precisión general de la corrección fue baja, con un 19% para el Flujo de Trabajo 1 y un 13% para el Flujo de Trabajo 2.
- La reparación resultó significativamente más difícil que la detección. Aunque algunos parches fueron "comparables" o incluso "mejores" que la verdad de terreno (particularmente para CWE-476 y CWE-787), muchos contenían lógica innecesaria o introducían nuevos errores.
Precisión del Verificador:
- El Verificador alcanzó una precisión del 69% con nemotron-cascade-2:30b, indicando una capacidad de evaluación post-remediación más fuerte que la de generación.
Variabilidad de CWE: CWE-787 y CWE-476 fueron los más fáciles de detectar, mientras que CWE-191 (Subdesbordamiento de Entero) fue el más difícil en todos los modelos y configuraciones.

Significado y Reclamaciones

El artículo posiciona este trabajo como un estudio exploratorio inicial en lugar de un benchmark definitivo. Su principal significancia radica en:

Mejora de Procesos: Demostrar que la descomposición de las tareas de seguridad en etapas estructuradas y basadas en roles (Planificación, Análisis, Corrección, Verificación) puede hacer que las actividades de seguridad sean más repetibles y transparentes.
Necesidad de Humano en el Bucle (Human-in-the-Loop): Reforzar que, a pesar de los avances en los LLM, la calidad desigual de los parches generados y la eficacia mixta de la integración de herramientas requieren una supervisión humana continua en entornos críticos de seguridad.
Flujo de Trabajo sobre el Modelo: Cambiar el enfoque de la selección del "mejor" modelo hacia el refinamiento de la arquitectura del flujo de trabajo subyacente y las técnicas de integración. Los autores señalan que, si bien el cribado de modelos es esencial, el diseño del flujo de trabajo es la principal palanca para la mejora.
Matiz de la Integración de Herramientas: Destacar que la integración de herramientas como CodeQL requiere un diseño de agente cuidadoso para asegurar que las pistas se prioricen correctamente; simplemente añadir herramientas no mejora automáticamente el rendimiento.

Los autores concluyen que las arquitecturas agénticas basadas en roles son una dirección prometedora para la mejora de los procesos de software seguro, motivando trabajos futuros en conjuntos de datos más grandes, análisis a nivel de repositorio y flujos de trabajo refinados (por ejemplo, múltiples analizadores, bucles de refinamiento).