💻 computer science

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

Questo rapporto registrato delinea uno studio empirico su larga scala che investiga come umani, bot e agenti di codifica comunichino riguardo alle vulnerabilità nelle pull request analizzando sia gli identificatori espliciti che il linguaggio della sicurezza implicito attraverso vari artefatti di progetto per comprenderne l'impatto sugli esiti della revisione.

Autori originali: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

Pubblicato 2026-06-29

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un enorme cantiere globale, dove migliaia di squadre costruiscono e riparano costantemente grattacieli digitali (software). In questo mondo, ci sono tre tipi di lavoratori: Umani (gli architetti originali), Bot (robot automatizzati che si occupano di compiti di routine come l'aggiornamento dei materiali) e Agenti di Codice (assistenti IA intelligenti che possono scrivere nuovi progetti da soli).

Questo articolo è un "registered report", il che significa che è un piano dettagliato di uno studio che i ricercatori stanno per condurre. Vogliono capire come questi tre tipi di lavoratori parlano di pericoli per la sicurezza (vulnerabilità) quando inviano modifiche ai piani di costruzione (Pull Request).

Ecco la suddivisione del loro piano utilizzando semplici analogie:

1. I due modi in cui i lavoratori parlano del pericolo

Quando un lavoratore trova una crepa nel muro o una trave debole, deve segnalarlo. I ricercatori hanno notato che i lavoratori lo fanno in due modi molto diversi:

Il metodo della "Carta d'Identità Ufficiale" (Riferimenti Espliciti):
A volte, un lavoratore indica un pericolo specifico e dice: "Questo è CVE-2024-1234". È come mostrare un codice a barre o un numero di serie. Tutti sanno esattamente cosa significhi quel numero specifico perché è elencato in un enorme database ufficiale.
- L'osservazione del documento: Gli studi precedenti si sono concentrati principalmente solo su queste "carte d'identità".
Il metodo dell' "Avviso Informale" (Segnali Impliciti):
Altre volte, un lavoratore dice semplicemente: "Ehi, questa porta potrebbe permettere l'ingresso a persone non autorizzate", oppure "Questo tubo sembra che potrebbe avere una perdita di dati SQL". Descrivono il problema in linguaggio naturale senza usare un numero ID specifico.
- L'osservazione del documento: I ricercatori sospettano che ignorando questi "avvisi informali", stiamo perdendo una fetta enorme di conversazioni sulla sicurezza.

2. La grande domanda: Chi dice cosa?

I ricercatori vogliono sapere: Gli umani, i Bot e gli Agenti IA parlano della sicurezza in modo diverso?

Gli Agenti IA (i nuovi arrivati sul campo) usano più "Carte d'Identità Ufficiali" perché sono programmati per essere precisi?
Gli Umani si affidano di più agli "Avvisi Informali" perché comprendono meglio il contesto?
I Bot seguono le regole e usano solo gli ID?

3. Le tre cose che intendono investigare

Lo studio è costruito attorno a tre domande principali (Domande di Ricerca):

RQ1: La Distribuzione (Chi sta parlando?)
Conteggeranno quanto spesso ciascun tipo di lavoratore utilizza "ID Ufficiali" rispetto ad "Avvisi Informali" in diverse parti della conversazione (nel titolo della richiesta, nella descrizione o nei commenti).
- Analogia: È come contare quante volte l'Architetto, il Robot e l'Assistente IA usano un codice di sicurezza formale rispetto al semplice gridare "Attenzione!" in sala pausa.
RQ2: Il Controllo della Realtà (Il pericolo è reale?)
Questa è la parte più critica. Solo perché qualcuno dice che c'è un pericolo, non significa che ce ne sia davvero uno.
- I ricercatori utilizzeranno uno "Scanner di Sicurezza" (uno strumento chiamato Semgrep) per esaminare le effettive modifiche al codice.
- Vogliono vedere: Se un'IA dice "Ho risolto un buco di sicurezza", ha effettivamente risolto un buco? O ha solo fatto un'affermazione che non era vera?
- Analogia: Se un lavoratore dice "Ho rinforzato il ponte", i ricercatori ispezioneranno fisicamente il ponte per vedere se è effettivamente più resistente, o se il lavoratore ha solo verniciato sopra una crepa.
RQ3: La Reazione (Come rispondono le persone?)
In che modo il modo in cui il pericolo viene descritto influenza la reazione del team?
Se un lavoratore usa un "ID Ufficiale" formale, i revisori si fidano più velocemente e approvano la modifica più rapidamente?
Se un lavoratore usa un "Avviso Informale", questo causa un dibattito più lungo, più domande o viene rifiutato perché è più difficile da verificare?
Analogia: Il capocantiere ascolta immediatamente quando mostri un codice a barre, o ti fa aspettare mentre discute se la tua descrizione della perdita è accurata?

4. Come lo faranno (Il loro kit di strumenti)

Il Dataset: Utilizzeranno una vasta collezione di oltre 33.000 pull request da popolari progetti open-source. Questo include il lavoro svolto da famosi agenti IA come GitHub Copilot, Devin e Cursor.
La Rilevazione:
- Per gli "ID Ufficiali", utilizzeranno una lente d'ingrandimento digitale (Espressioni Regolari) per trovare schemi come "CVE-..." o "GHSA-...".
- Per gli "Avvisi Informali", utilizzeranno un elenco di parole chiave di sicurezza (come "insecure", "hack", "bypass") per trovare discussioni in linguaggio naturale.
La Verifica: Poiché i computer possono commettere errori, utilizzeranno un'IA intelligente (Gemini) ed esperti umani per ricontrollare un campione dei risultati, per assicurarsi che i "segnali di pericolo" siano reali.

5. I Limiti (Cosa questo studio NON potrà dirvi)

I ricercatori sono molto onesti riguardo ai confini del loro studio:

Stanno guardando solo progetti popolari (quelli con molti "stars" o follower). Progetti piccoli e silenziosi potrebbero avere regole diverse.
Stanno guardando solo GitHub. Non stanno controllando email private, chat o altri siti web dove potrebbero essere discusse questioni di sicurezza.
Stanno guardando la conversazione e il codice, ma non possono garantire che il loro "Scanner di Sicurezza" catturerà ogni singola possibile falla nel mondo.

Riassunto

In breve, questo articolo è il progetto di uno studio che si chiede: Nel cantiere digitale del futuro, come parlano umani, robot e IA della sicurezza? Usano codici formali o un linguaggio semplice? E il modo in cui parlano cambia il modo in cui le loro afferole sulla sicurezza vengono credute o messe in atto? L'obiettivo è fare in modo che non stiamo ignorando gli "avvisi informali" solo perché non hanno un codice a barre allegato.

Sintesi Tecnica: Come esseri umani, bot e agenti comunicano le vulnerabilità nelle Pull Request

Definizione del problema
Le vulnerabilità del software vengono tipicamente comunicate attraverso identificatori standardizzati (ad es., CVE, CWE, GHSA) o tramite linguaggio naturale implicito (ad es., "SQL injection", "accesso non autorizzato"). Mentre la ricerca precedente ha ampiamente utilizzato identificatori espliciti per studiare le attività di sviluppo relative alla sicurezza, questo approccio rischia di trascurare le discussioni che si affidano esclusivamente al linguaggio implicito. Inoltre, la crescente prevalenza di bot e agenti di programmazione autonomi nei flussi di lavoro delle pull request (PR) introduce nuove dinamiche nel modo in cui le vulnerabilità vengono riferite. Gli studi esistenti si sono concentrati principalmente su come questi attori utilizzino identificatori espliciti, ma non hanno investigato sufficientemente i segnali di sicurezza impliciti, se tali riferimenti correlino con vulnerabilità reali nel codice, o come influenzino gli esiti della revisione delle PR. Questo rapporto registrato affronta queste lacune investigando la comunicazione delle vulnerabilità tra esseri umani, bot e agenti di programmazione.

Metodologia
Lo studio impiega un'analisi empirica su larga scala basata sul dataset AIDev-pop, un sottoinsieme curato del dataset AIDev che contiene oltre 3ata 33.000 pull request da 2.807 popolari repository open-source (quelli con >500 stelle). Il dataset include PR scritte da cinque specifici agenti di programmazione (OpenAI Codex, Devin, GitHub Copilot, Cursor, Claude Code) oltre a contributori umani e bot.

Il piano di esecuzione prevede tre fasi primarie:

Rilevamento dei segnali di vulnerabilità:
- Riferimenti Espliciti: Identificati tramite il matching di espressioni regolari contro pattern standardizzati per identificatori quali CVE, CWE, GHSA, GO, RUSTSEC, OSV, MAL e USN (dettagliati nella Tabella II del documento).
- Segnali Impliciti: Rilevati utilizzando un approccio basato su parole chiave validato (Zhou e Sharma [11]) applicato a titoli di PR, descrizioni, commenti di revisione, messaggi di commit e discussioni nella timeline.
- Validazione: I segnali rilevati sono validati utilizzando l'LLM Gemini-2.0-flash. Per garantire l'affidabilità, due campioni rappresentativi (360 PR ciascuno per i segnali espliciti e impliciti) sono codificati manualmente da annotatori umani per stabilire la verità di base (ground truth), con la misurazione dell'affidabilità inter-rater tramite il $\kappa$ di Cohen.
Classificazione degli Account:
- Agenti di Programmazione: Identificati tramite account specifici annotati nel dataset originale AIDev-pop.
- Bot: Identificati tramite tag GitHub, euristiche del nome utente (che contengono "bot") e una lista curata di noti account bot, con verifica manuale su un campione stratificato.
- Esseri Umani: Tutti gli account rimanenti non classificati come agenti o bot.
Analisi dei Dati e Analisi Statica:
- RQ1 (Distribuzione): Analizza la frequenza e la distribuzione dei riferimenti espliciti vs impliciti tra i diversi tipi di attori e le componenti della PR tramite test chi-quadrato.
- RQ2 (Qualità del Codice): Utilizza Semgrep (configurato con set di regole predefiniti e quattro livelli di severità) per eseguire l'analisi statica sul codice prima (commit base) e dopo (commit head) le modifiche alla PR. Ciò determina se un segnale di vulnerabilità corrisponde a una vulnerabilità effettiva introdotta, corretta o rimasta invariata. I modelli di regressione controllano le caratteristiche della PR (ad es., righe modificate, numero di file).
- RQ3 (Risposta Sociale): Analizza l'attività di revisione (conteggio commenti, numero di revisori), i tempi di risposta e gli esiti delle PR (accettata, chiusa, aperta) utilizzando modelli di regressione logistica e basati sul conteggio, controllando la complessità del repository e della PR.

Contributi Chiave

Analisi Esaustiva dei Segnali: Lo studio va oltre gli identificatori espliciti per includere segnali di sicurezza impliciti, fornendo un quadro più completo della comunicazione delle vulnerabilità.
Investigazione Centrata sull'Attore: Confronta specificamente come umani, bot e agenti di programmazione differiscano nei loro modelli di comunicazione riguardanti le vulnerabilità.
Validazione Empirica: La ricerca collega i segnali di comunicazione alle reali modifiche al codice tramite analisi statica, affrontando la questione se i riferimenti (specialmente quelli provenienti dagli agenti) corrispondano a problemi di sicurezza reali.
Dataset e Pipeline: Gli autori forniscono un dataset e una pipeline di analisi progettati specificamente per studiare la comunicazione delle vulnerabilità nelle discussioni delle PR, facilitando la ricerca futura in questo dominio.

Risultati
Nota: Trattandosi di un rapporto registrato che descrive uno studio pianificato, il documento non presenta risultati empirici finali o risultati statistici. Il testo delinea le ipotesi e il quadro analitico piuttosto che riportare gli esiti.

Il documento dettaglia il piano per rispondere a tre domande di ricerca:

RQ1: Come i riferimenti alle vulnerabilità sono distribuiti tra i tipi impliciti/espliciti, i tipi di attori e le componenti della PR.
RQ2: L'associazione tra i tipi di riferimento e le modifiche di sicurezza rilevate dall'analisi statica (introdotte vs corrette).
RQ3: L'associazione tra i tipi di riferimento e le metriche di risposta sociale (attività di revisione e esiti delle PR).

Significato e Ambito
Lo studio contribuisce a un'indagine empirica su larga scala sulle pratiche di comunicazione delle vulnerabilità nello sviluppo software moderno. Distinguendo tra identificatori espliciti e linguaggio implicito, e tenendo conto del ruolo degli agenti autonomi, la ricerca mira a svelare modelli che potrebbero sfuggire agli studi che si affidano esclusivamente a identificatori formali.

Gli autori riconoscono specifiche limitazioni riguardanti la validità:

Validità Interna: L'uso di regex per gli ID espliciti può mancare identificatori malformati; il rilevamento basato su parole chiave per i segnali impliciti può generare falsi positivi/negativi, sebbene mitigato da validazione tramite LLM e umani. Anche gli strumenti di analisi statica (Semgrep) possono produrre falsi positivi o mancare di contesti specifici.
Validità Esterna: I risultati sono specifici per i repository open-source popolari (>500 stelle) che utilizzano attivamente agenti di programmazione. I risultati caratterizzano le pratiche di comunicazione all'interno di questi ecosistemi specifici e potrebbero non essere generalizzabili a progetti più piccoli, privati o non basati su GitHub.

Il documento conclude posizionando questo lavoro come un passo fondamentale verso la comprensione di come i diversi attori comunicano riguardo alla sicurezza, suggerendo ricerche future per investigare affermazioni di sicurezza errate o non supportate, in particolare nelle PR generate dall'IA.