💻 computer science

How Humans, Bots, and Agents Communicate About Vulnerabilities in Pull Requests

Este relatório registrado descreve um estudo empírico de larga escala que investiga como humanos, bots e agentes de codificação se comunicam sobre vulnerabilidades em pull requests, analisando tanto identificadores explícitos quanto linguagem de segurança implícita através de vários artefatos de projeto para compreender seu impacto nos resultados de revisão.

Autores originais: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

Publicado 2026-06-29

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

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 um canteiro de obras massivo e global, onde milhares de equipes estão constantemente construindo e reparando arranha-céus digitais (software). Neste mundo, existem três tipos de trabalhadores: Humanos (os arquitetos originais), Bots (robôs automatizados que lidam com tarefas rotineiras como atualização de materiais) e Agentes de Codificação (assistentes de IA inteligentes que podem escrever novos projetos por conta própria).

Este artigo é um "relatório registrado", o que significa que é um plano detalado de um estudo que os pesquisadores estão prestes a realizar. Eles querem entender como esses três tipos de trabalhadores falam sobre riscos de segurança (vulnerabilidades) quando enviam alterações para os planos de construção (Pull Requests).

Aqui está a divisão do plano deles usando analogias simples:

1. As duas formas de os trabalhadores falarem sobre perigo

Quando um trabalhador encontra uma rachadura na parede ou uma viga fraca, ele precisa sinalizar isso. Os pesquisadores notaram que os trabalhadores fazem isso de duas maneiras muito diferentes:

O Método do "Cartão de Identidade Oficial" (Referências Explícitas):
Às vezes, um trabalhador aponta para um perigo específico e diz: "Isto é o CVE-2024-1234". É como mostrar um código de barras ou um número de série. Todos sabem exatamente o que esse número específico significa porque ele está listado em um banco de dados oficial e gigante.
- A Observação do Artigo: Estudos anteriores focaram majoritariamente apenas nesses "cartões de identidade".
O Método do "Aviso Casual" (Sinais Implícitos):
Outras vezes, um trabalhador apenas diz: "Ei, esta porta pode permitir a entrada de pessoas não autorizadas" ou "Este cano parece que poderia vazar dados SQL". Eles descrevem o problema em linguagem comum, sem usar um número de identificação específico.
- A Observação do Artigo: Os pesquisadores suspeitam que, ao ignorar esses "avisos casuais", estamos perdendo uma grande parte das conversas de segurança.

2. A Grande Pergunta: Quem diz o quê?

Os pesquisadores querem saber: Humanos, Bots e Agentes de IA falam sobre segurança de forma diferente?

Os Agentes de IA (os novatos no pedaço) usam mais "Cartões de Identidade Oficiais" porque são programados para serem precisos?
Os Humanos dependem mais de "Avisos Casuais" porque entendem melhor o contexto?
Os Bots seguem as regras e usam apenas os IDs?

3. As Três Coisas que Eles Planejam Investigar

O estudo é construído em torno de três perguntas principais (Questões de Pesquisa):

RQ1: A Distribuição (Quem está falando?)
Eles contarão com que frequência cada tipo de trabalhador usa "IDs Oficiais" vs. "Avisos Casuais" em diferentes partes da conversa (o título da solicitação, a descrição ou os comentários).
- Analogia: É como contar quantas vezes o Arquiteto, o Robô e o Assistente de IA usam um código de segurança formal versus apenas gritar "Cuidado!" na sala de descanso.
RQ2: O Teste de Realidade (O perigo é real?)
Esta é a parte mais crítica. Só porque alguém diz que há um perigo, não significa que haja um.
- Os pesquisadores usarão um "Scanner de Segurança" (uma ferramenta chamada Semgrep) para examinar as mudanças reais no código.
- Eles querem ver: Se uma IA diz "Eu corrigi uma brecha de segurança", ela realmente corrigiu um buraco? Ou ela apenas fez uma afirmação que não era verdadeira?
- Analogia: Se um trabalhador diz "Eu reforcei a ponte", os pesquisadores inspecionarão fisicamente a ponte para ver se ela está realmente mais forte, ou se o trabalhador apenas pintou por cima de uma rachadura.
RQ3: A Reação (Como as pessoas respondem?)
Como a maneira como o perigo é descrito afeta a reação da equipe?
- Se um trabalhador usa um "ID Oficial" formal, os revisores confiam nele mais rápido e aprovam a mudança mais rapidamente?
- Se um trabalhador usa um "Aviso Casual", isso causa um debate mais longo, mais perguntas ou é rejeitado porque é mais difícil de verificar?
- Analogia: O mestre de obras escuta imediatamente quando você mostra um código de barras, ou ele faz você esperar enquanto discutem se a sua descrição do vazamento é precisa?

4. Como Eles Farão Isso (O Kit de Ferramentas)

O Conjunto de Dados: Eles estão usando uma coleção massiva de mais de 33.000 pull requests de projetos populares de código aberto. Isso inclui o trabalho de agentes de IA famosos como GitHub Copilot, Devin e Cursor.
A Detecção:
- Para "IDs Oficiais", eles usarão uma lupa digital (Expressões Regulares) para encontrar padrões como "CVE-..." ou "GHSA-...".
- Para "Avisções Casuais", eles usarão uma lista de palavras-chave de segurança (como "inseguro", "hack", "bypass") para encontrar discussões em linguagem natural.
A Verificação: Como computadores podem cometer erros, eles usarão uma IA inteligente (Gemini) e especialistas humanos para conferir uma amostra dos achados para garantir que os "sinais de perigo" sejam reais.

5. Os Limites (O que este Estudo Não Dirá)

Os pesquisadores são muito honestos sobre os limites do seu estudo:

Eles estão olhando apenas para projetos populares (aqueles com muitos "stars" ou seguidores). Projetos menores e silenciosos podem ter regras diferentes.
Eles estão olhando apenas para o GitHub. Eles não estão verificando e-mails privados, salas de chat ou outros sites onde questões de segurança possam ser discutidas.
Eles estão olhando para a conversa e para o código, mas não podem garantir que o seu "Scanner de Segurança" capturará todas as falhas possíveis no mundo.

Resumo

Em suma, este artigo é um projeto para um estudo que pergunta: No canteiro de obras digital do futuro, como humanos, robôs e IA falam sobre segurança? Eles usam códigos formais ou linguagem comum? E a maneira como eles falam muda se suas alegações de segurança são acreditadas ou não? O objetivo é garantir que não estejamos ignorando os "avisos casuais" apenas porque eles não têm um código de barras anexado.

Resumo Técnico: Como Humanos, Bots e Agentes se Comunicam sobre Vulnerabilidades em Pull Requests

Declaração do Problema
Vulnerabilidades de software são tipicamente comunicadas por meio de identificadores padronizados (ex: CVE, CWE, GHSA) ou linguagem natural implícita (ex: "injeção de SQL", "acesso não autorizado"). Embora pesquisas anteriores tenham utilizado extensivamente identificadores explícitos para estudar atividades de desenvolvimento relacionadas à segurança, essa abordagem pode negligenciar discussões que dependem exclusivamente de linguagem implícita. Além disso, a crescente prevalência de bots e agentes de codificação autônomos nos fluxos de trabalho de pull requests (PRs) introduz novas dinâmicas na forma como as vulnerabilidades são referenciadas. Estudos existentes focaram amplamente em como esses atores utilizam identificadores explícitos, mas não investigaram suficientemente os sinais de segurança implícitos, se tais referências se correlacionam com vulnerabilidades reais no código, ou como elas influenciam os resultados de revisão de PRs. Este relatório registrado aborda essas lacunas investigando a comunicação de vulnerabilidades entre humanos, bots e agentes de codificação.

Metodologia
O estudo emprega uma análise empírica de larga escala baseada no dataset AIDev-pop, um subconjunto curado do dataset AIDev contendo mais de 33.000 pull requests de 2.807 repositórios de código aberto populares (aqueles com >500 estrelas). O dataset inclui PRs autoriais de cinco agentes de codificação específicos (OpenAI Codex, Devin, GitHub Copilot, Cursor, Claude Code), bem como contribuidores humanos e bots.

O plano de execução envolve três fases primárias:

Detecção de Sinais de Vulnerabilidade:
- Referências Explícitas: Identificadas usando correspondência de expressões regulares contra padrões padronizados para identificadores como CVE, CWE, GHSA, GO, RUSTSEC, OSV, MAL e USN (detalhados na Tabela II do artigo).
- Sinais Implícitos: Detectados usando uma abordagem baseada em palavras-chave validada (Zhou e Sharma [11]) aplicada a títulos de PR, descrições, comentários de revisão, mensagens de commit e discussões de linha do tempo.
- Validação: Os sinais detectados são validados utilizando o LLM Gemini-2.0-flash. Para garantir a confiabilidade, duas amostras representativas (360 PRs cada para sinais explícitos e implícitos) são codificadas manualmente por anotadores humanos para estabelecer o ground truth, com a confiabilidade inter-avaliador medida via Cohen's $\kappa$ .
Classificação de Contas:
- Agentes de Codificação: Identificados via contas de usuário específicas anotadas no dataset original AIDev-pop.
- Bots: Identificados via tags do GitHub, heurísticas de nome de usuário (contendo "bot") e uma lista curada de contas de bots conhecidas, com verificação manual em uma amostra estratificada.
- Humanos: Todas as contas restantes não classificadas como agentes ou bots.
Análise de Dados & Análise Estática:
- RQ1 (Distribuição): Analisa a frequência e a distribuição de referências explícitas vs. implícitas entre tipos de atores e componentes de PR usando testes qui-quadrado.
- RQ2 (Qualidade do Código): Utiliza o Semgrep (configurado com conjuntos de regras padrão e quatro níveis de severidade) para realizar análise estática no código antes (commit base) e depois (commit head) das mudanças do PR. Isso determina se um sinal de vulnerabilidade corresponde a uma vulnerabilidade real sendo introduzida, corrigida ou permanecendo inalterada. Modelos de regressão controlam características do PR (ex: linhas alteradas, contagem de arquivos).
- RQ3 (Resposta Social): Analisa a atividade de revisão (contagem de comentários, contagem de revisores), tempos de resposta e resultados de PR (mesclado, fechado, aberto) usando modelos de regressão logística e de contagem, controlando a complexidade do repositório e do PR.

Principais Contribuições

Análise Abrangente de Sinais: O estudo estende-se além de identificadores explícitos para incluir sinais relacionados à segurança de forma implícita, proporcionando uma visão mais completa da comunicação de vulnerabilidades.
Investigação Centrada no Ator: Compara especificamente como humanos, bots e agentes de codificação diferem em seus padrões de comunicação em relação a vulnerabilidades.
Validação Empírica: A pesquisa vincula sinais de comunicação a mudanças reais de código via análise estática, abordando a questão de se as referências (especialmente as de agentes) correspondem a problemas de segurança reais.
Dataset e Pipeline: Os autores fornecem um dataset e um pipeline de análise especificamente projetados para estudar a comunicação de vulnerabilidades em discussões de PR, facilitando pesquisas futuras neste domínio.

Resultos
Nota: Como este é um relatório registrado descrevendo um estudo planejado, o artigo não apresenta resultados empíricos finais ou achados estatísticos. O texto detalha as hipóteses e o framework analítico em vez de relatar resultados.

O artigo detalha o plano para responder a três questões de pesquisa:

RQ1: Como as referências de vulnerabilidade estão distribuídas entre tipos implícitos/explícitos, tipos de atores e componentes de PR.
RQ2: A associação entre tipos de referência e mudanças de segurança detectadas por análise estática (introduzidas vs. corrigidas).
RQ3: A associação entre tipos de referência e métricas de resposta social (atividade de revisão e resultados de PR).

Significância e Escopo
O estudo contribui com uma investigação empírica de larga escala sobre as práticas de comunicação de vulnerabilidades no desenvolvimento de software moderno. Ao distinguir entre identificadores explícitos e linguagem implícita, e ao considerar o papel de agentes autônomos, a pesquisa visa descobrir padrões que podem ser perdidos por estudos que dependem apenas de identificadores formais.

Os autores reconhecem limitações específicas quanto à validade:

Validade Interna: A dependência de regex para IDs explícitos pode perder identificadores malformados; a detecção baseada em palavras-chave para sinais implícitos pode gerar falsos positivos/negativos, embora mitigada por validação via LLM e humana. Ferramentas de análise estática (Semgrep) também podem produzir falsos positivos ou perder questões dependentes de contexto.
Validade Externa: Os achados são específicos para repositórios de código aberto populares (>500 estrelas) que utilizam ativamente agentes de codificação. Os resultados caracterizam as práticas de comunicação dentro desses ecossistemas específicos e podem não se generalizar para projetos menores, privados ou não pertencentes ao GitHub.

O artigo conclui posicionando este trabalho como um passo fundamental para entender como diferentes atores se comunicam sobre segurança, com trabalhos futuros sugeridos para investigar alegações de segurança incorretas ou não suportadas, particularmente em PRs gerados por IA.