💻 computer science

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

Este artigo propõe e avalia um fluxo de trabalho de agentes baseado em funções, composto pelos agentes Planejador, Analisador, Corretor e Verificador, para preencher a lacuna entre tarefas de segurança de LLM isoladas e práticas industriais do mundo real, demonstrando uma precisão de detecção de vulnerabilidades de 44% e uma precisão de correção de 19% em 25 vulnerabilidades reais de C/C++.

Autores originais: Srijita Basu, Miroslaw Staron

Publicado 2026-06-15

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Srijita Basu, Miroslaw Staron

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando consertar uma casa muito antiga e complexa (um programa de software escrito em C ou C++) que possui rachaduras ocultas e pontos fracos (vulnerabilidades de segurança). No passado, você poderia ter contratado um único detetive superinteligente (uma IA padrão) para examinar a casa, encontrar as rachaduras e tentar remendá-las todas de uma vez. Às vezes esse detetive acerta, mas frequentemente ele fica sobrecarregado, perde pistas sutis ou remenda a parede errada.

Este artigo propõe uma abordagem diferente: contratar uma equipe especializada de agentes em vez de um único detetive solitário. Eles trabalham juntos em uma linha de montagem rigorosa, onde cada um tem um trabalho específico.

Aqui está como a equipe funciona, usando as descobertas do artigo:

1. Os Papéis da Equipe (O "Fluxo de Trabalho Agêntico")

Os pesquisadores configuraram uma equipe digital com quatro papéis distintos, semelhantes a uma equipe de construção:

O Planejador (O Gerente de Obra): Antes de qualquer pessoa começar a cavar, este agente escaneia as plantas (o código) para detectar pontos problemáticos óbvios. Ele não conserta nada; apenas aponta a equipe para as áreas que parecem suspeitas, como "Verifique a porta dos fundos" ou "Olhe para a fundação".
- Descoberta Principal: O artigo descobriu que ter este "Gerente de Obra" era crucial. Quando removeram este papel, a capacidade da equipe de encontrar problemas caiu quase pela metade.
O Analista (O Inspetor): Este é o detetve principal. Ele pega as pistas do Planejador e o código bruto para entender exatamente o que está quebrado, por que está quebrado e como um ladrão poderia entrar.
- Descoberta Principal: Os pesquisadores tentaram dar a este agente um detector de metais de alta tecnologia (uma ferramenta chamada CodeQL) para ajudar a encontrar rachaduras. Surpreendentemente, o detector de metais nem sempre ajudou. Às vezes, ele gerava muitos alarmes falsos, confundindo o Inspetor. Os melhores resultados vieram do próprio modelo de IA realizando o pensamento profundo, em vez de depender fortemente da ferramenta extra.
O Reparador (O Consertador): Uma vez que o Inspetor diz: "O batente da porta está apodrecendo", o Reparador tenta construir uma nova porta. Eles escrem o código para tapar o buraco.
- Descoberta Principal: Este foi o trabalho mais difícil. Embora a equipe fosse razoável em encontrar o problema (cerca de 44% de precisão), realmente consertá-lo corretamente era muito mais difícil (apenas cerca de 19% de precisão). Frequentemente, o Reparador remendava o buraco, mas acidentalmente quebrava algo próximo ou adicionava partes desnecessárias.
O Verificador (O Inspetor de Segurança): Após o reparo ser feito, este agente faz uma dupla checagem do trabalho. Ele pergunta: "Você realmente consertou o apodrecimento? Você tornou a casa mais segura ou apenas pintou por cima da rachadura?"
- Descoberta Principal: Este papel foi bastante bom em detectar erros, pegando cerca de 69% dos erros nos reparos.

2. O Experimento

Os pesquisadores testaram esta equipe em 25 vulnerabilidades de segurança reais encontradas em softwares populares de C/C++ (como os usados em sistemas de segurança crítica). Eles usaram três "cérebros" diferentes (modelos de IA) para alimentar os membros da equipe.

Eles compararam duas versões da equipe:

Equipe A: Apenas os quatro papéis conversando entre si.
Equipe B: Os mesmos quatro papéis, mas o Inspetor recebeu o detector de metais CodeQL para ajudar a encontrar as rachaduras.

3. O Que Eles Descobriram

O "Gerente" Importa Mais: A parte mais importante do processo foi o Planejador. Sem um gerente para guiar a equipe sobre onde olhar, a IA se perdia. Com o gerente, a equipe teve o desempenho de uma IA comercial de alto nível (GPT-5.5) ao encontrar os bugs.
Ferramentas Não São Mágicas: Dar ao Inspetor uma ferramenta sofisticada (CodeQL) não o tornou automaticamente melhor. Na verdade, às vezes tornava as coisas piores porque a IA tinha dificuldade em interpretar corretamente os dados da ferramenta. O artigo sugere que, para linguagens de baixo nível (como C), a IA precisa ser inteligente o suficiente para priorizar as pistas por conta própria.
Encontrar vs. Consertar: É muito mais fácil para a IA encontrar um buraco de segurança do que consertá-lo. A equipe encontrou os bugs cerca de 44% das vezes, mas só os consertou corretamente 19% das vezes.
O Toque Humano Ainda é Necessário: Como o "Consertador" (Reparador) frequentemente cometia erros ou adicionava mudanças desnecessárias, o artigo conclui que, na segurança do mundo real, você não pode simplesmente deixar a IA comandar tudo. Você precisa de um humano para observar o trabalho da IA, verificar os reparos e garantir que a casa esteja realmente segura.

A Conclusão

Este artigo não afirma que a IA pode agora proteger o software perfeitamente por conta própria. Em vez disso, mostra que organizar a IA em uma equipe estruturada com papéis claros é uma maneira melhor de lidar com a segurança do que deixar uma única IA fazer tudo. No entanto, mesmo com uma ótima equipe, a parte de "consertar" ainda é complicada, e especialistas humanos ainda são essenciais para verificar o trabalho.

Resumo Técnico: Segurança em um Fluxo de Trabalho – Explorando Arquiteturas Agênticas Baseadas em Papéis para o Tratamento de Vulnerabilidades

Declaração do Problema

A engenharia de software segura na prática industrial envolve um fluxo de trabalho estruturado de múltiplas etapas, compreendendo análise de vulnerabilidade, remediação e verificação de correção. No entanto, as abordagens atuais baseadas em Grandes Modelos de Linguagem (LLMs) para segurança de software são frequentemente fragmentadas, focando em tarefas isoladas, como detecção ou geração de patches, em vez de refletir os fluxos de trabalho agênticos de ponta a ponta utilizados em processos de segurança do mundo real. Isso cria uma lacuna entre os métodos existentes de LLM e a engenharia de software segura prática, particularmente para linguagens de sistemas de baixo nível como C e C++. Nessas linguagens, as vulnerabilidades dependem de semânticas de memória complexas, manipulação de ponteiros e gerenciamento de buffers, tornando o diagnóstico e a remediação desafiadores para LLMs. Além disso, há uma exploração limitada de fluxos de trabalho agênticos aumentados por ferramentas e integração de habilidades via Model Context Protocol (MCP) especificamente para esses contextos de baixo nível.

Metodologia

Os autores propõem e avaliam um fluxo de trabalho agêntico baseado em papéis, projetado para decompor o tratamento de vulnerabilidades em estágios explícitos: planejamento de investigação, análise de vulnerabilidade, geração de patch e verificação de correção.

Design do Fluxo de Trabalho

O estudo implementa duas variantes de fluxo de trabalho usando o framework CrewAI, instanciadas com três LLMs de código aberto: nemotron-cascade-2:30b, qwen3-coder-next e gpt-oss:120b. Os fluxos de trabalho consistem em quatro papéis distintos:

Planejador (Planner): Um módulo estático baseado em regras (não é um LLM) que varre o código C de entrada em busca de padrões de vulnerabilidade predefinidos (ex: estouros de buffer, desreferência de ponteiro nulo) usando expressões regulares. Ele fornece regiões de investigação e temas priorizados para guiar o Analisador.
Analisador (Analyzer): Um agente de LLM responsável pelo diagnóstico técnico. Ele determina a vulnerabilidade primária, atribui o ID da Common Weakness Enumeration (CWE), identifica as linhas vulneráveis, explica a causa raiz e rastreia o fluxo fonte-para-sumidouro (source-to-sink).
- Fluxo de Trabalho 1: O Analisador depende exclusivamente da orientação do Planejador.
- Fluxo de Trabalho 2: O Analisador é aumentado com integração MCP CodeQL, fornecendo capacidades de análise estática durante o diagnóstico.
Corretor (Fixer): Um agente de LLM que gera um patch seguro e minimalista baseado no diagnóstico do Analisador. Ele é restrito a produzir o patch e uma explicação concisa, evitando o rediagnóstico.
Verificador (Verifier): Um agente de LLM independente que avalia se o patch gerado resolve a vulnerabilidade identificada, remove a causa raiz e evita a introdução de regressões.

Configuração Experimental

Conjunto de Dados: Um conjunto curado de 25 CVEs (Common Vulnerabilities and Exposures) reais de C/C++ abrangendo cinco categorias de CWE: CWE-787 (Escrita fora dos limites), CWE-476 (Desreferência de Ponteiro Nulo), CWE-190 (Overflow de Inteiro), CWE-125 (Leitura fora dos limites) e CWE-191 (Underflow de Inteiro).
Verdade Fundamental (Ground Truth): Derivada de descrições do National Vulnerability Database (NVD) e código corrigido fornecido pelos desenvolvedores.
Avaliação: Avaliação manual baseada em rubrica realizada por dois autores (coeficiente kappa de Cohen $\kappa = 0,83$ ) comparando as saídas dos agentes contra a verdade fundamental. As métricas incluíram precisão de detecção (atribuição de CWE, identificação de linha, causa raiz) e precisão de correção (similaridade semântica com correções confiáveis).
Escopo: O estudo é uma avaliação exploratória e orientada à metodologia, não um benchmark de larga escala, focando em 150 execuções de fluxo de trabalho (25 CVEs $\times$ 3 modelos $\times$ 2 variantes).

Principais Contribuições

Arquitetura Agêntica Baseada em Papéis: Proposta e avaliação de um fluxo de trabalho de ponta a ponta separando planejamento, análise, correção e verificação, demonstrando como a separação explícita de papéis pode estruturar atividades de segurança.
Design de Planejador Estático: Implementação de um planejador baseado em regras para guiar a investigação de vulnerabilidades em projetos C relevantes para a indústria, mostrando seu impacto crítico na qualidade da detecção.
Conjunto de Referência Curado: Fornecimento de 25 instâncias de vulnerabilidades reais de C/C++ com metadados de verdade fundamental, correções de desenvolvedores e saídas geradas por LLM, juntamente com o código do framework CrewAI para reprodutibilidade.
Análise de Integração de Ferramentas: Investigação da eficácia da integração de análise estática baseada em MCP (CodeQL) na etapa de análise de um fluxo de trabalho multi-agente.

Resultados

O estudo reporta as seguintes métricas de desempenho (usando nemotron-cascade-2:30b como o modelo principal para comparação):

Precisão de Detecção:
- Fluxo de Trabalho 1 (Sem CodeQL): Alcançou 44% de precisão de detecção, comparável às baselines do GPT-5.5.
- Fluxo de Trabalho 2 (Com CodeQL): A precisão caiu para 31%, sugerindo que a integração de ferramentas sozinha não garante melhoria se o agente não puder interpretar ou priorizar corretamente as dicas da ferramenta.
- Ablação: A remoção do Planejador reduziu a precisão de detecção para 25% (sem CodeQL) e 19% (com CodeQL), ressaltando o papel crítico do Planejador.
Precisão de Correção:
- A precisão geral de correção foi baixa, em 19% para o Fluxo de Trabalho 1 e 13% para o Fluxo de Trabalho 2.
- A reparação provou ser significativamente mais difícil do que a detecção. Embora alguns patches tenham sido "comparáveis" ou até "melhores" que a verdade fundamental (particularmente para CWE-476 e CWE-787), muitos continham lógica desnecessária ou introduziam novos bugs.
Precisão do Verificador:
- O Verificador alcançou 69% de precisão com o nemotron-cascade-2:30b, indicando uma capacidade de avaliação pós-remediação mais forte do que a de geração.
Variabilidade de CWE:
- CWE-787 e CWE-476 foram os mais fáceis de detectar, enquanto o CWE-191 (Integer Underflow) permaneceu como o mais difícil em todos os modelos e configurações.

Significância e Alegações

O artigo posiciona este trabalho como um estudo exploratório inicial, não como um benchmark definitivo. Sua principal significância reside em:

Melhoria de Processo: Demonstrar que a decomposição de tarefas de segurança em estágios estruturados e baseados em papéis (Planejamento, Análise, Correção, Verificação) pode tornar as atividades de segurança mais repetíveis e transparentes.
Necessidade de Humano no Ciclo (Human-in-the-Loop): Reforçar que, apesar dos avanços nos LLMs, a qualidade desigual dos patches gerados e a eficácia mista da integração de ferramentas exigem a supervisão humana contínua em ambientes críticos de segurança.
Fluxo de Trabalho sobre o Modelo: Deslocar o foco da seleção do "melhor" modelo para o refinamento da arquitetura do fluxo de trabalho subjacente e das técnicas de integração. Os autores observam que, embora a triagem de modelos seja essencial, o design do fluxo de trabalho é o principal alavancador para melhoria.
Nuance da Integração de Ferramentas: Destacar que integrar ferramentas como o CodeQL requer um design de agente cuidadoso para garantir que as dicas sejam priorizadas corretamente; simplesmente adicionar ferramentas não aumenta automaticamente o desempenho.

Os autores concluem que arquiteturas agênticas baseadas em papéis são uma direção promissora para a melhoria de processos de software seguros, motivando trabalhos futuros em conjuntos de dados maiores, análise de nível de repositório e alternativas de fluxo de trabalho refinadas (ex: múltiplos analisadores, loops de refinamento).