💻 computer science

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

Este informe registrado describe un estudio empírico a gran escala que investiga cómo los humanos, los bots y los agentes de codificación se comunican sobre las vulnerabilidades en los pull requests mediante el análisis tanto de identificadores explícitos como del lenguaje de seguridad implícito a través de diversos artefactos de proyectos para comprender su impacto en los resultados de la revisión.

Autores originales: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

Publicado 2026-06-29

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

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 un sitio de construcción masivo y global donde miles de equipos construyen y reparan constantemente rascacielos digitales (software). En este mundo, hay tres tipos de trabajadores: Humanos (los arquitectos originales), Bots (robots automatizados que se encargan de tareas rutinarias como actualizar materiales) y Agentes de Codificación (asistentes de IA inteligentes que pueden escribir nuevos planos por su cuenta).

Este documento es un "informe registrado", lo que significa que es un plan detallado de un estudio que los investigadores están a punto de realizar. Quieren entender cómo estos tres tipos de trabajadores hablan sobre riesgos de seguridad (vulnerabilidades) cuando envían cambios a los planes de construcción (Pull Requests).

Aquí está el desglose de su plan utilizando analogías sencillas:

1. Las dos formas en que los trabajadores hablan del peligro

Cuando un trabajador encuentra una grieta en la pared o una viga débil, necesita señalarlo. Los investigadores notaron que los trabajadores hacen esto de dos maneras muy diferentes:

El método de la "Tarjeta de Identificación Oficial" (Referencias Explícitas):
A veces, un trabajador señala un peligro específico y dice: "Esto es CVE-2024-1234". Es como mostrar un código de barras o un número de serie. Todo el mundo sabe exactamente qué significa ese número específico porque figura en una base de datos gigante y oficial.
- La observación del documento: Estudios previos se centraron principalmente solo en estas "tarjetas de identificación".
El método de la "Advertencia Casual" (Señales Implícitas):
Otras veces, un trabajador simplemente dice: "Oye, esta puerta podría permitir la entrada de personas no autorizadas", o "Esta tubería parece que podría tener una fuga de datos SQL". Describen el problema en lenguaje sencillo sin usar un número de identificación específico.
- La observación del documento: Los investigadores sospechan que, al ignorar estas "advertencias casuales", estamos perdiendo una gran parte de las conversaciones de seguridad.

2. La gran pregunta: ¿Quién dice qué?

Los investigadores quieren saber: ¿Hablan los Humanos, los Bots y los Agentes de IA de forma diferente sobre la seguridad?

¿Los Agentes de IA (los nuevos en el barrio) usan más "Tarjetas de Identificación Oficiales" porque están programados para ser precisos?
¿Los Humanos dependen más de las "Advertencias Casuales" porque entienden mejor el contexto?
¿Los Bots se ciñen a las reglas y solo usan las identificaciones?

3. Las tres cosas que planean investigar

El estudio se basa en tres preguntas principales (Preguntas de Investigación):

RE1: La Distribución (¿Quién está hablando?)
Contarán con qué frecuencia cada tipo de trabajador utiliza "IDs Oficiales" frente a "Advertencias Casuales" en diferentes partes de la conversación (el título de la solicitud, la descripción o los comentarios).
- Analogía: Es como contar cuántas veces el Arquitecto, el Robot y el Asistente de IA usan un código de seguridad formal frente a simplemente gritar "¡Cuidado!" en la sala de descanso.
RE2: El Control de Realidad (¿Es real el peligro?)
Esta es la parte más crítica. El hecho de que alguien diga que hay un peligro, no significa que lo haya.
- Los investigadores utilizarán un "Escáner de Seguridad" (una herramienta llamada Semgrep) para examinar los cambios reales en el código.
- Quieren ver: Si una IA dice "He arreglado un agujero de seguridad", ¿realmente arregló un agujero? ¿O simplemente hizo una afirmación que no era cierta?
- Analogía: Si un trabajador dice "He reforzado el puente", los investigadores inspeccionarán físicamente el puente para ver si realmente es más fuerte, o si el trabajador solo pintó encima de una grieta.
RE3: La Reacción (¿Cómo responde la gente?)
¿Cómo afecta la forma en que se describe el peligro a la reacción del equipo?
- Si un trabajador utiliza un "ID Oficial" formal, ¿los revisores confían en él más rápido y fusionan el cambio con mayor rapidez?
- Si un trabajador utiliza una "Advertencia Casual", ¿esto provoca un debate más largo, más preguntas o es rechazado porque es más difícil de verificar?
- Analogía: ¿El capataz de la construcción escucha de inmediato cuando muestras un código de barras, o te hace esperar mientras discuten si tu descripción de la fuga es precisa?

4. Cómo lo harán (Su caja de herramientas)

El Conjunto de Datos: Utilizarán una colección masiva de más de 33,000 pull requests de proyectos de código abierto populares. Esto incluye el trabajo de agentes de IA famosos como GitHub Copilot, Devin y Cursor.
La Detección:
- Para los "IDs Oficiales", utilizarán una lupa digital (Expresiones Regulares) para encontrar patrones como "CVE-..." o "GHSA-...".
- Para las "Advertencias Casuales", utilizarán una lista de palabras clave de seguridad (como "inseguro", "hack", "bypass") para encontrar discusiones en lenguaje natural.
La Verificación: Dado que las computadoras pueden cometer errores, utilizarán una IA inteligente (Gemini) y expertos humanos para verificar una muestra de los hallazgos y asegurar que las "señales de peligro" sean reales.

5. Los Límites (Lo que este estudio NO te dirá)

Los investigadores son muy honestos sobre los límites de su estudio:

Solo están mirando proyectos populares (aquellos con muchas "estrellas" o seguidores). Los proyectos pequeños y silenciosos podrían tener reglas diferentes.
Solo están mirando GitHub. No están revisando correos electrónicos privados, salas de chat u otros sitios web donde se puedan discutir problemas de seguridad.
Están analizando la conversación y el código, pero no pueden garantizar que su "Escáner de Seguridad" detectará cada posible falla en el mundo.

Resumen

En resumen, este documento es un plano para un estudio que pregunta: En el sitio de construcción digital del futuro, ¿cómo hablan los humanos, los robots y la IA sobre la seguridad? ¿Utilizan códigos formales o lenguaje sencillo? Y, ¿cambia la forma en que hablan el hecho de que sus afirmaciones de seguridad sean creídas o ejecutadas? El objetivo es asegurarnos de que no estamos ignorando las "advertencias casuales" solo porque no tienen un código de barras adjunto.

Resumen Técnico: Cómo los humanos, los bots y los agentes se comunican sobre vulnerabilidades en los Pull Requests

Declaración del Problema
Las vulnerabilidades de software se comunican típicamente a través de identificadores estandarizados (por ejemplo, CVE, CWE, GHSA) o mediante lenguaje natural implícito (por ejemplo, "inyección SQL", "acceso no autorizado"). Si bien investigaciones previas han utilizado extensamente identificadores explícitos para estudiar actividades de desarrollo relacionadas con la seguridad, este enfoque puede pasar por alto las discusiones que dependen únicamente del lenguaje implícito. Además, la creciente prevalencia de bots y agentes de codificación autónomos en los flujos de trabajo de los pull requests (PR) introduce nuevas dinámicas en la forma en que se referencian las vulnerabilidades. Los estudios existentes se han centrado mayoritariamente en cómo estos actores utilizan identificadores explícitos, pero no han investigado suficientemente las señales de seguridad implícitas, si tales referencias se correlacionan con vulnerabilidades reales en el código, o cómo influyen en los resultados de la revisión de los PR. Este informe registrado aborda estas brechas investigando la comunicación de vulnerabilidades entre humanos, bots y agentes de codificación.

Metodología
El estudio emplea un análisis empírico a gran escala basado en el conjunto de datos AIDev-pop, un subconjunto curado del conjunto de datos AIDev que contiene más de 33,000 pull requests de 2,807 repositorios de código abierto populares (aquellos con >500 estrellas). El conjunto de datos incluye PR de autoría de cinco agentes de codificación específicos (OpenAI Codex, Devin, GitHub Copilot, Cursor, Claude Code), así como de contribuyentes humanos y bots.

El plan de ejecución consta de tres fases primarias:

Detección de Señales de Vulnerabilidad:
- Referencias Explícitas: Identificadas mediante el uso de expresiones regulares contra patrones estandarizados para identificadores tales como CVE, CWE, GHSA, GO, RUSTSEC, OSV, MAL y USN (detallados en la Tabla II del artículo).
- Señales Implícitas: Detectadas mediante un enfoque validado basado en palabras clave (Zhou y Sharma [11]) aplicado a títulos de PR, descripciones, comentarios de revisión, mensajes de commit y discusiones de la línea de tiempo.
- Validación: Las señales detectadas se validan utilizando el modelo de lenguaje LLM Gemini-2.0-flash. Para garantizar la fiabilidad, dos muestras representativas (360 PR cada una para señales explícitas e implícitas) son codificadas manualmente por anotadores humanos para establecer la verdad de campo (ground truth), midiendo la fiabilidad inter-evaluador mediante el coeficiente $\kappa$ de Cohen.
Clasificación de Cuentas:
- Agentes de Codificación: Identificados mediante cuentas de usuario específicas anotadas en el conjunto de datos original AIDev-pop.
- Bots: Identificados mediante etiquetas de GitHub, heurísticas de nombre de usuario (que contienen "bot") y una lista curada de cuentas de bots conocidas, con verificación manual en una muestra estratificada.
- Humanos: Todas las cuentas restantes no clasificadas como agentes o bots.
Análisis de Datos y Análisis Estático:
- RQ1 (Distribución): Analiza la frecuencia y distribución de las referencias explícitas frente a las implícitas a través de tipos de actores y componentes de los PR mediante pruebas de chi-cuadrado.
- RQ2 (Calidad del Código): Utiliza Semgrep (configurado con conjuntos de reglas por defecto y cuatro niveles de severidad) para realizar un análisis estático en el código antes (commit base) y después (commit head) de los cambios del PR. Esto determina si una señal de vulnerabilidad corresponde a una vulnerabilidad real que se está introduciendo, corrigiendo o que permanece sin cambios. Los modelos de regresión controlan las características del PR (por ejemplo, líneas cambiadas, número de archivos).
- RQ3 (Respuesta Social): Analiza la actividad de revisión (conteo de comentarios, número de revisores), los tiempos de respuesta y los resultados de los PR (fusionados, cerrados, abiertos) utilizando modelos de regresión logística y de conteo, controlando la complejidad del repositorio y del PR.

Contribuciones Clave

Análisis Integral de Señales: El estudio se extiende más allá de los identificadores explícitos para incluir señales implícitas relacionadas con la seguridad, proporcionando una imagen más completa de la comunicación de vulnerabilidades.
Investigación Centrada en el Actor: Compara específicamente cómo difieren los humanos, los bots y los agentes de codificación en sus patrones de comunicación respecto a las vulnerabilidades.
Validación Empírica: La investigación vincula las señales de comunicación con cambios reales en el código mediante el análisis estático, abordando la cuestión de si las referencias (especialmente las de los agentes) corresponden a problemas de seguridad reales.
Conjunto de Datos y Pipeline: Los autores proporcionan un conjunto de datos y un pipeline de análisis diseñado específicamente para estudiar la comunicación de vulnerabilidades en las discusiones de PR, facilitando la investigación futura en este dominio.

Resultados
Nota: Dado que este es un informe registrado que describe un estudio planificado, el artículo no presenta resultados empíricos finales ni hallazgos estadísticos. El texto detalla las hipótesis y el marco analítico en lugar de reportar resultados.

El artículo detalla el plan para responder a tres preguntas de investigación:

RQ1: Cómo se distribuyen las referencias a vulnerabilidades entre tipos implícitos/explícitos, tipos de actores y componentes de los PR.
RQ2: La asociación entre tipos de referencia y cambios de seguridad detectados mediante análisis estático (introducidos vs. corregidos).
RQ3: La asociación entre tipos de referencia y métricas de respuesta social (actividad de revisión y resultados de los PR).

Significación y Alcance
El estudio contribuye con una investigación empírica a gran escala sobre las prácticas de comunicación de vulnerabilidades en el desarrollo de software moderno. Al distinguir entre identificadores explícitos y lenguaje implícito, y al tener en cuenta el papel de los agentes autónomos, la investigación pretende descubrir patrones que podrían pasar desapercibidos para los estudios que dependen únicamente de identificadores formales.

Los autores reconocen limitaciones específicas respecto a la validez:

Validez Interna: La dependencia de expresiones regulares para los ID explícitos puede omitir identificadores mal formados; la detección basada en palabras clave para señales implícitas puede generar falsos positivos/negativos, aunque esto se mitiga mediante la validación por LLM y humanos. Las herramientas de análisis estático (Semgrep) también pueden producir falsos positivos o pasar por alto problemas dependientes del contexto.
Validez Externa: Los hallazgos son específicos de repositorios de código abierto populares (>500 estrellas) que utilizan activamente agentes de codificación. Los resultados caracterizan las prácticas de comunicación dentro de estos ecosistemas específicos y pueden no generalizarse a proyectos más pequeños, privados o ajenos a GitHub.

El artículo concluye posicionando este trabajo como un paso fundacional hacia la comprensión de cómo los diferentes actores se comunican sobre la seguridad, sugiriendo trabajos futuros para investigar afirmaciones de seguridad incorrectas o no respaldadas, particularmente en los PR generados por IA.