💻 computer science

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

Dit geregistreerde rapport schetst een grootschalige empirische studie die onderzoekt hoe mensen, bots en coderingsagenten communiceren over kwetsbaarheden in pull requests door zowel expliciete identificatoren als impliciete beveiligingstaal over diverse projectartefacten te analyseren om hun impact op review-uitkomsten te begrijpen.

Oorspronkelijke auteurs: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

Gepubliceerd 2026-06-29

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Pien Rooijendijk, Christoph Treude, Mairieli Wessel

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een enorme, wereldwijde bouwplaats voor waar duizenden teams constant digitale wolkenkrabbers (software) bouwen en repareren. In deze wereld zijn drie soorten werkers: Mensen (de oorspronkelijke architecten), Bots (geautomatiseerde robots die routinetaken afhandelen zoals het bijwerken van materialen) en Coding Agents (slimme AI-assistenten die op eigen houtje nieuwe blauwdrukken kunnen schrijven).

Dit artikel is een "registered report", wat betekent dat het een gedetailleerd plan is voor een studie die de onderzoekers van plan zijn uit te voeren. Ze willen begrijpen hoe deze drie soorten werkers over veiligheidsrisico's (kwetsbaarheden) praten wanneer ze wijzigingen aan de bouwplannen (Pull Requests) indienen.

Hier is de uitsplitsing van hun plan met behulp van eenvoudige analogieën:

1. De twee manieren waarop werkers over gevaar praten

Wanneer een werker een barst in de muur of een zwakke balk vindt, moeten ze dit melden. De onderzoekers merkten op dat werkers dit op twee zeer verschillende manieren doen:

De "Officiële ID-kaart"-methode (Expliciete verwijzingen):
Soms wijst een werker naar een specifiek gevaar en zegt: "Dit is CVE-2024-1234." Het is alsof je een barcode of een serienummer laat zien. Iedereen weet precies wat dat specifieke nummer betekent omdat het in een enorme, officiële database staat.
- De observatie van het artikel: Eerdere studies keken voornamelijk alleen naar deze "ID-kaarten".
De "Informele Waarschuwing"-methode (Impliciete signalen):
Soms zegt een werker gewoon: "Hé, deze deur laat misschien onbevoegden binnen," of "Deze leiding ziet eruit alsof hij SQL-data zou kunnen lekken." Ze beschrijven het probleem in gewone taal zonder een specifiek ID-nummer te gebruiken.
- De observatie van het artikel: De onderzoekers vermoeden dat we door deze "informele waarschuwingen" te negeren, een enorm deel van de veiligheidsgesprekken missen.

2. De grote vraag: Wie zegt wat?

De onderzoekers willen weten: Praten Mensen, Bots en AI-Agents anders over veiligheid?

Gebruiken AI-Agents (de nieuwkomers op de werkvloer) meer "Officiële ID-kaarten" omdat ze geprogrammeerd zijn om precies te zijn?
Vertrouwen Mensen meer op "Informele Waarschuwingen" omdat zij de context beter begrijpen?
Houden Bots zich aan de regels en gebruiken ze alleen de ID's?

3. De drie dingen die ze van plan zijn te onderzoeken

De studie is gebouwd rond drie hoofdvragen (Onderzoeksvragen):

RQ1: De Verdeling (Wie praat er?)
Ze zullen tellen hoe vaak elk type werker "Officiële ID's" versus "Informele Waarschuwingen" gebruikt in verschillende delen van het gesprek (de titel van de aanvraag, de beschrijving of de reacties).
- Analogie: Het is als het tellen van hoe vaak de Architect, de Robot en de AI-Assistent een formele veiligheidscode gebruiken versus simpelweg "Pas op!" roepen in de kantine.
RQ2: De Reality Check (Is het gevaar echt?)
Dit is het meest cruciale deel. Alleen omdat iemand zegt dat er een gevaar is, betekent dat nog niet dat er ook daadwerkelijk één is.
- De onderzoekers zullen een "Veiligheidsscanner" (een tool genaamd Semgrep) gebruiken om naar de daadwerkelijke code-wijzigingen te kijken.
- Ze willen zien: Als een AI zegt "Ik heb een beveiligingsgat gefixt," heeft het dan ook echt een gat gefixt? Of heeft het alleen maar een bewering gedaan die niet waar was?
- Analogie: Als een werker zegt: "Ik heb de brug versterkt," dan zullen de onderzoekers de brug fysiek inspecteren om te zien of hij daadwerkelijk sterker is, of dat de werker alleen een barst heeft overgeschilderd.
RQ3: De Reactie (Hoe reageren mensen?)
Hoe beïnvloedt de manier waarop het gevaar wordt beschreven de reactie van het team?
- Als een werker een formele "Officiële ID" gebruikt, vertrouwen de reviewers dit dan sneller en wordt de wijziging sneller goedgekeurd?
- Als een werker een "Informele Waarschuwing" geeft, leidt dit dan tot een langer debat, meer vragen of wordt het afgewezen omdat het moeilijker te verifiëren is?
- Analogie: Luistert de voorman van de bouwplaats direct wanneer je een barcode laat zien, of moet je wachten terwijl ze discussiëren over de vraag of jouw beschrijving van het lek wel accuraat is?

4. Hoe ze het gaan doen (De Toolkit)

De Dataset: Ze gebruiken een enorme collectie van meer dan 33.000 pull requests van populaire open-source projecten. Dit bevat werk van beroemde AI-agents zoals GitHub Copilot, Devin en Cursor.
De Detectie:
- Voor "Officiële ID's" zullen ze een digitaal vergrootglas (Regular Expressions) gebruiken om patronen zoals "CVE-..." of "GHSA-..." te vinden.
- Voor "Informele Waarschuwingen" zullen ze een lijst met veiligheidstermen (zoals "insecure", "hack", "bypass") gebruiken om discussies in natuurlijke taal te vinden.
De Verificatie: Omdat computers fouten kunnen maken, zullen ze een slimme AI (Gemini) en menselijke experts gebruiken om een steekproef van de bevindingen te controleren om er zeker van te zijn dat de "gevaarsignalen" echt zijn.

5. De Limieten (Wat deze studie u niet zal vertellen)

De onderzoekers zijn zeer eerlijk over de grenzen van hun studie:

Ze kijken alleen naar populaire projecten (die veel "stars" of volgers hebben). Kleine, stille projecten kunnen andere regels hebben.
Ze kijken alleen naar GitHub. Ze controleren geen privé-e-mails, chatkamers of andere websites waar veiligheidskwesties besproken kunnen worden.
Ze kijken naar het gesprek en de code, maar ze kunnen niet garanderen dat hun "Veiligheidsscanner" elk mogelijk gebrek in de wereld zal vangen.

Samenvatting

Kortom, dit artikel is een blauwdruk voor een studie die de vraag stelt: Hoe praten mensen, robots en AI over veiligheid in de digitale bouwplaats van de toekomst? Gebruiken ze formele codes of gewone taal? En beïnvloedt de manier waarop ze praten of hun veiligheidsclaims geloofd en opgevolgd worden? Het doel is om ervoor te zorgen dat we "informele waarschuwingen" niet negeren, alleen omdat er geen barcode aan vastzit.

Technische Samenvatting: Hoe mensen, bots en agenten communiceren over kwetsbaarheden in Pull Requests

Probleemstelling
Softwarekwetsbaarheden worden doorgaans gecommuniceerd via gestandaardiseerde identificatoren (bijv. CVE, CWE, GHSA) of impliciete natuurlijke taal (bijv. "SQL-injectie", "ongeautoriseerde toegang"). Terwijl eerder onderzoek uitgebreid gebruik heeft gemaakt van expliciete identificatoren om beveiligingsgerelateerde ontwikkelingsactiviteiten te bestuderen, negeert deze aanpak potentieel discussies die uitsluitend vertrouwen op impliciete taal. Bov�els de toenemende prevalentie van bots en autonome programmeeragenten in pull request (PR) workflows, ontstaan er nieuwe dynamieken in de manier waarop kwetsbaarheden worden gerefereerd. Bestaande studies hebben zich grotendeels gericht op hoe deze actoren expliciete identificatoren gebruiken, maar hebben onvoldoende onderzocht hoe impliciete beveiligingssignalen werken, of dergelijke referenties correleren met werkelijke kwetsbaarheden in de code, en hoe zij de uitkomsten van PR-reviews beïnvloeden. Dit geregistreerde rapport adresseert deze hiaten door kwetsbaarheidscommunicatie bij mensen, bots en programmeeragenten te onderzoeken.

Methodologie
De studie maakt gebruik van een grootschalige empirische analyse gebaseerd op de AIDev-pop dataset, een gecureerde subset van de AIDev-dataset die meer dan 33.000 pull requests bevat uit 2.807 populaire open-source repositories (met >500 sterren). De dataset bevat PR's geschreven door vijf specifieke programmeeragenten (OpenAI Codex, Devin, GitHub Copilot, Cursor, Claude Code) evenals menselijke en bot-bijdragers.

Het uitvoeringsplan omvat drie primaire fasen:

Detectie van Kwetsbaarheidssignalen:
- Expliciete Referenties: Geïdentificeerd via regular expression matching tegen gestandaardiseerde patronen voor identificatoren zoals CVE, CWE, GHSA, GO, RUSTSEC, OSV, MAL en USN (gedetailleerd in Tabel II van het artikel).
- Impliciete Signalen: Gedetecteerd met behulp van een gevalideerde keyword-gebaseerde aanpak (Zhou en Sharma [11]) toegepast op PR-titels, beschrijvingen, review-comments, commit-berichten en tijdlijn-discussies.
- Validatie: Gedetecteerde signalen worden gevalideerd met behulp van de Gemini-2.0-flash LLM. Om de betrouwbaarheid te waarborgen, worden twee representatieve steekproeven (360 PR's elk voor expliciete en impliciete signalen) handmatig gecodeerd door menselijke annotatoren om de grondwaarheid vast te stellen, waarbij de inter-beoordelaarsbetrouwbaarheid wordt gemeten via Cohen's $\kappa$ .
Classificatie van Accounts:
- Programmeeragenten: Geïdentificeerd via specifieke gebruikersaccounts geannoteerd in de oorspronkelijke AIDev-pop dataset.
- Bots: Geïdentificeerd via GitHub-tags, gebruikersnaam-heuristieken (bevatten "bot") en een gecureerde lijst van bekende bot-accounts, met handmatige verificatie op een gestratificeerde steekproef.
- Mensen: Alle overige accounts die niet als agent of bot zijn geclassificeerd.
Data-analyse & Statische Analyse:
- RQ1 (Distributie): Analyseert de frequentie en distributie van expliciete versus impliciete referenties over verschillende typen actoren en PR-componenten met behulp van chi-kwadraattoetsen.
- RQ2 (Codekwaliteit): Gebruikt Semgrep (geconfigureerd met standaard regelsets en vier ernstniveaus) om statische analyse uit te voeren op de code vóór (base commit) en na (head commit) de PR-wijzigingen. Dit bepaalt of een kwetsbaarheidssignaal overeenkomt met een werkelijke kwetsbaarheid die wordt geïntroduceerd, opgelost of ongewijzigd blijft. Regressiemodellen controleren voor PR-kenmerken (bijv. aantal gewijzigde regels, aantal bestanden).
- RQ3 (Sociale Respons): Analyseert review-activiteit (aantal comments, aantal reviewers), responstijden en PR-uitkomsten (merged, closed, open) met behulp van logistische en count-gebaseerde regressiemodellen, waarbij gecontroleerd wordt voor repository- en PR-complexiteit.

Belangrijkste Bijdragen

Uitgebreide Signaalanalyse: De studie breidt de analyse uit voorbij expliciete identificatoren door ook impliciete beveiligingsgerelateerde signalen op te nemen, wat een completer beeld geeft van de communicatie over kwetsbaarheden.
Actor-Centrische Onderzoek: Het vergelijkt specifiek hoe mensen, bots en programmeeragenten verschillen in hun communicatiepatronen met betrekking tot kwetsbaarheden.
Empirische Validatie: De research koppelt communicatiesignalen aan werkelijke code-wijzigingen via statische analyse, waarmee de vraag wordt beantwoord of referenties (vooral die van agenten) overeenkomen met echte beveiligingsproblemen.
Dataset en Pipeline: De auteurs bieden een dataset en analyse-pipeline die specifiek zijn ontworpen voor het bestuderen van kwetsbaarheidscommunicatie in PR-discussies, wat toekomstig onderzoek in dit domein faciliteert.

Resultaten
Opmerking: Aangezien dit een geregistreerd rapport is dat een gepland onderzoek beschrijft, presenteert het artikel geen definitieve empirische resultaten of statistische bevindingen. De tekst schetst de hypothesen en het analytisch kader in plaats van de uitkomsten te rapporteren.

Het artikel beschrijft het plan om drie onderzoeksvragen te beantwoorden:

RQ1: Hoe de distributie van kwetsbaarheidsreferenties is verdeeld tussen impliciete/expliciete types, actortypes en PR-componenten.
RQ2: De associatie tussen referentietypes en door statische analyse gedetecteerde beveiligingswijzigingen (geïntroduceerd versus opgelost).
RQ3: De associatie tussen referentietypes en sociale respons-metrieken (review-activiteit en PR-uitkomsten).

Betekenis en Omvang
De studie draagt bij aan een grootschalig empirisch onderzoek naar communicatiepraktijken rondom kwetsbaarheden in moderne softwareontwikkeling. Door onderscheid te maken tussen expliciete identificatoren en impliciete taal, en door rekening te houden met de rol van autonome agenten, beoogt het onderzoek patronen bloot te leggen die mogelijk gemist worden door studies die uitsluitend vertrouwen op formele identificatoren.

De auteurs erkennen specifieke beperkingen met betrekking tot de validiteit:

Interne Validiteit: Het vertrouwen op regex voor expliciete ID's kan malafide identificatoren missen; keyword-gebaseerde detectie voor impliciete signalen kan fout-positieven/negatieven opleveren, hoewel dit wordt gemitigeerd door LLM- en menselijke validatie. Statische analyse-tools (Semgrep) kunnen ook fout-positieven produceren of context-afhankelijke problemen missen.
Externe Validiteit: De bevindingen zijn specifiek voor populaire open-source repositories (>500 sterren) die actief gebruikmaken van programmeeragenten. De resultaten karakteriseren de communicatiepraktijken binnen deze specifieke ecosystemen en zijn mogelijk niet generaliseerbaar naar kleinere, private of niet-GitHub projecten.

Het artikel concludeert door dit werk te positioneren als een fundamentele stap naar het begrijpen van hoe verschillende actoren communiceren over beveiliging, waarbij toekomstig werk wordt gesuggereerd om onjuiste of niet-onderbouwde beveiligingsclaims te onderzoeken, met name in door AI gegenereerde PR's.