🤖 AI

Understanding the Impact of AI Code Assistants on Security API Usage: An Empirical Study

Deze empirische studie onder 44 professionele ontwikkelaars onthult dat hoewel GitHub Copilot de functionele correctheid verbetert en bepaalde onveilige patronen marginaal vermindert, het er niet in slaagt om het veilige gebruik van security API's significant te verbeteren, waardoor ontwikkelaars vaak onbewust blijven van resterende kwetsbaarheden.

Oorspronkelijke auteurs: Zahra Mousavi, Chadni Islam, M. Ali Babar, Alsharif Abuadbba, Kristen Moore

Gepubliceerd 2026-07-14

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zahra Mousavi, Chadni Islam, M. Ali Babar, Alsharif Abuadbba, Kristen Moore

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 voor dat je een supergeheime clubhuis bouwt en je moet geavanceerde sloten, alarmen en geheime tunnels installeren om indringers buiten te houden. Deze sloten zijn als Security API's—speciale hulpmiddelen die ontwikkelaars gebruiken om software te beschermen. Maar hier komt de twist: deze sloten zijn lastig. Als je ze verkeerd installeert, kan je "geheime" tunnel zomaar een wagenwijd openstaande deur worden voor hackers.

Stel je nu voor dat je een superintelligente robotassistent hebt genaamd Copilot die code voor je kan schrijven. Je denkt misschien: "Geweldig, de robot kent alle regels, dus mijn clubhuis wordt als Fort Knox!" Maar een nieuwe studie door Zahra Moussevi en haar team van universiteiten en onderzoekscentra in Australië besloot dit idee op de proef te stellen. Ze vroegen de robot niet alleen om een slot te bouwen; ze observeerden 44 echte professionele ontwikkelaars die probeerden deze sloten te bouwen, zowel met de hulp van de robot als zonder.

Dit is wat ze vonden, geserveerd met een vleugje realiteit.

De robot is een geweldige helper, maar een slechte beveiligingsbewaker

Eerst het goede nieuws: Copilot is een fantastische snelheidsduivel. Wanneer de ontwikkelaars een complex slot moesten bouwen (specifiek een Google OAuth-systeem voor toegang tot gebruikersgegevens), hielp de robot hen om de klus veel sneller te klaren.

Zonder de robot kreeg slechts 45% van de ontwikkelaars (10 van de 22) het slot überhaupt werkend.
Met de hulp van de robot kreeg 91% van de ontwikkelaars (20 van de 22) het werkend.
De robot verkortte ook de tijd die nodig was om de complexe taak te voltooien met 63%, waarbij de gemiddelde tijd daalde van 62 minuten naar 23 minuten.

Dus, als je doel simpelweg is om de deur te bouwen en te laten draaien, is de robot een grote overwinning.

Maar hier is de adder onder het gras: Alleen omdat de deur gebouwd is, betekent het nog niet dat hij op slot zit. Sterker nog, geen enkele van de ontwikkelaars, of ze nu de robot gebruikten of niet, slaagde erin om een volledig veilig slot te bouwen voor de taken die ze kregen toegewezen. Elke poging bij de geëvalueerde taken bevatte ten minste één grote fout.

De "Vertrouw mij"-valstrik

De studie keek naar twee specifieke soorten sloten: JSSE (voor veilige internetverbindingen) en Google OAuth (voor het inloggen bij apps). Ze ontdekten dat de robot de beveiligingsproblemen niet oploste; in veel gevallen hielp het de ontwikkelaars juist om de kapotte sloten sneller te bouwen.

De "Vertrouw iedereen"-fout: Stel je een bewaker voor die iedereen binnenlaat omdat ze er vriendelijk uitzien. In de studie stelden sommige ontwikkelaars (en de robot) het systeem zo in dat het "alle certificaten vertrouwt". Dit is alsof je tegen je bewaker zegt: "Als iemand een pasje laat zien, laat ze dan binnen, zelfs als het een nep pasje is." Dit is een enorm beveiligingslek.
De "Geheime Code"-fout: Sommige ontwikkelaars schreven hun geheime wachtwoorden direct in de code, zoals het onder de deurmat leggen van je huissleutel. De robot suggereerde dit soms ook!
De "Geen controle"-fout: Bij het verbinden met een server moet je controleren of je daadwerkelijk met de juiste persoon praat. Veel implementaties sloegen deze stap over, waardoor de deur open kwam te staan voor een "Man-in-the-Middle"-aanvaller (iemand die zich voordoet als je vriend om je spullen te stelen).

De onderzoekers ontdekten dat hoewel de robot hielp bij sommige kleine fouten, het de grote beveiligingsfouten niet voorkwam. Sterker nog, 100% van de geëvalueerde taken resulteerde in code met beveiligingsproblemen. De robot maakte de code niet veiliger dan de menselijke werkzaamheden alleen; het zorgde er alleen voor dat de onveilige code sneller verscheen.

De blinde vlek van de mens

Dit is het meest verrassende deel van het verhaal. De onderzoekers vroegen de ontwikkelaars: "Denk je dat je code veilig is?"

Ondanks dat geen enkele code daadwerkelijk veilig was, zeiden de meeste ontwikkelaars: "Ja, ik denk dat ik dit veilig heb opgelost!"
Slechts een handjevol mensen realiseerde zich dat ze een fout hadden gemaakt.
Wanneer ze met de robot praatten, vroeg bijna niemand: "Hé, is dit wel veilig?" Ze vroegen alleen: "Maak het werkend."

Het is alsof een groep mensen een brug bouwt en een robot om hulp vraagt. De robot helpt hen om de stenen snel te leggen, maar niemand controleert of de brug daadwerkelijk gewicht kan dragen. Wanneer er wordt gevraagd: "Denk je dat deze brug het houdt?", zeggen de meeste mensen: "Zeker!", ook al staat de brug op instorten.

Kunnen we de robot beter leren?

De onderzoekers probeerden nog één ding. Ze vroegen de ontwikkelaars om de robot specifiek te vertellen: "Hey, controleer dit op beveiliging!" of "Je bent een expert in beveiliging, los dit op!"

Wanneer zij dit deden, herstelde de robot inderdaad sommige van de fouten in het eenvoudigere slot (JSSE).
Echter, voor het complexere slot (OAuth) miste de robot nog steeds veel kritieke beveiligingslekken, zelfs toen er expliciet werd gevraagd om voorzichtig te zijn.

De kern van het verhaal

Deze studie suggereert dat hoewel AI-assistenten zoals Copilot geweldig zijn in het helpen van ons om snel en correct code te schrijven, ze geen magisch schild tegen hackers zijn.

De Robot: Geweldig in snelheid en functionaliteit, maar geen beveiligingsexpert.
De Mensen: Vaak te vertrouwend op de robot en controleren de beveiliging zelf niet goed genoeg.
Het Resultaat: We bouwen systemen die veilig lijken, maar die in werkelijkheid vol gaten zitten.

De onderzoekers concluderen dat we niet simpelweg op de robot kunnen vertrouwen om ons veilig te houden. We moeten degene zijn die de moeilijke beveiligingsvragen stellen, het werk controleren en ervoor zorgen dat de "sloten" die we bouwen ook daadwerkelijk op slot zitten. De robot is een krachtig hulpmiddel, maar het is geen vervanging voor een beveiligingsbewust verstand.

Technische Samenvatting: Het begrijpen van de impact van AI-code-assistenten op het gebruik van Security API's

Probleemstelling

Security Application Programming Interfaces (API's), zoals SSL/TLS en OAuth, zijn fundamenteel voor de moderne softwarebeveiliging, maar worden frequent misbruikt vanwege hun complexiteit, ontoereikende documentatie en een gebrek aan ontwikkelaarstraining. Dergelijk misbruik leidt tot ernstige kwetsbaarheden, waaronder Man-in-the-Middle (MitM) aanvallen en datalekken. Hoewel LLM-gebaseerde AI-code-assistenten zoals GitHub Copilot steeds vaker worden geadopteerd om de ontwikkeling te versnellen, blijft hun impact op het veilige gebruik van deze kritieke API's onderbelicht.

Bestaand onderzoek heeft zich grotendeels gericht op modeloutputs gegenereerd vanuit vooraf gedefinieerde prompts zonder tussenkomst van de ontwikkelaar, of op algemene kwetsbaarheidspatronen in plaats van specifieke API-misbruik. Er is een kritiek gat in het begrip van hoe professionele ontwikkelaars met AI-assistenten interageren bij het implementeren van security API's, hoe deze tools de uiteindelijke beveiliging van de code beïnvloeden, en in welke mate ontwikkelaars beveiligingsproblemen herkennen en mitigeren in AI-ondersteunde workflows.

Methodologie

De auteurs voerden een empirische binnen-onderwerp studie uit met 44 professionele Java-ontwikkelaars. Het onderzoeksontwerp vergeleek twee condities voor elke deelnemer:

Experimentele Conditie: Het voltooien van een taak met GitHub Copilot-assistentie.
Controle Conditie: Het voltooien van een andere taak zonder enige AI-assistentie.

Taken:
Deelnemers kregen twee programmeertaken toegewezen met betrekking tot verschillende security API's:

JSSE Taak: Het implementeren van een createSSLSocket methode om veilige SSL/TLS-verbindingen op te zetten.
Google OAuth Taak: Het implementeren van een authorize methode voor een desktopapplicatie om toegang te krijgen tot gebruikersgegevens van Gmail via OAuth.

Procedure:

Deelnemers werkten in een gecontroleerde AWS virtuele omgeving met VS Code.
De studie maakte gebruik van counterbalancing om leer- en vermoeidheidseffecten te mitigeren, waarbij deelnemers werden verdeeld in vier groepen op basis van taakvolgorde en de beschikbaarheid van Copilot.
Sessies werden schermopnames en deelnemers voltooiden post-taak enquêtes over hun beveiligingsbewustzijn en zelfevaluatie van de codeniveaus-beveiliging.
Evaluatie: Code werd geanalyseerd op functionele correctheid en beveiliging. De beveiligingsanalyse omvatte een handmatige review door twee security experts met behulp van een taxonomie van security API-misbruiken (Mousavi et al.). Een logistisch regressiemodel werd gebruikt om de impact van Copilot en de achtergrond van de deelnemer op de uitkomsten te analyseren. Daarnaast omvatte een post-studie analyse het opnieuw prompten van Copilot met security-gerichte instructies om te testen of het in staat is om misbruiken te identificeren en te herstellen.

Belangrijkste Bijdragen

Deze studie presenteert de eerste ontwikkelaar-gecentreerde empirische investigatie naar het gebruik van AI-code-assistenten voor security API-taken in realistische settings. De primaire bijdragen zijn:

Empirisch Bewijs over de Impact van Copilot: Een vergelijkende analyse van Copilot-ondersteunde versus niet-ondersteunde ontwikkeling met betrekking tot functionele correctheid en veilig API-gebruik.
Identificatie van Persisterende Misbruiken: Een gedetailleerde categorisering van security API-misbruiken die voortbestaan, worden geïntroduceerd of gedeeltelijk worden gemitigeerd bij het gebruik van Copilot.
Analyse van Ontwikkelaar-bewustzijn: Een onderzoek naar hoe ontwikkelaars met Copilot omgaan met betrekking tot beveiliging, inclusief hun promptstrategieën en hun vermogen om onveilige implementaties te herkennen.
Inzichten in Prompt Engineering: Een evaluatie van de vraag of gerichte security-georiënteerde prompts effectief kunnen sturen om Copilot meer veilige code te laten genereren.

Belangrijkste Resultaten

Functionele Correctheid (RQ1)

Copilot verbeterde de functionele correctheid aanzienlijk, met name voor de complexere OAuth-taak.

JSSE Taak: Alle deelnemers produceerden functionele code ongeacht het gebruik van Copilot, hoewel Copilot-gebruikers de taak sneller voltooiden (14 min vs. 26 min).
OAuth Taak: Succesratio's namen toe van 45% (onondersteund) naar 91% (met Copilot-assistentie), waarbij de voltooiingstijden met 63% afnamen.
Statistische Significantie: Logistische regressie bevestigde een statistisch significant positief effect van Copilot op functionele uitkomsten ( $p = 0.007$ ).

Beveiligingsuitkomsten (RQ2)

Ondanks verbeteringen in functionaliteit, produceerde geen enkele deelnemer een volledig veilige implementatie in de beide condities.

JSSE Misbruiken: Drie typen werden geïdentificeerd: Onveilige SSL/TLS standaarden (M1), het vertrouwen op alle certificaten (M2), en het ontbreken van hostname verificatie (M3). Copilot vertoonde een lichte, niet-significante reductie in M1 en M2, maar voorkwam M3 niet.
OAuth Misbruiken: Zes kritieke misbruiken werden gevonden, waaronder lokale opslag van secrets (M4), lokale opslag van tokens (M5), gebrek aan state parameters (M6), gebrek aan SP authenticatie (M7), gebrek aan PKCE (M8), en inadequate transmissiebescherming (M9).
Algemene Impact: Copilot verbeterde het veilige API-gebruik niet significant. De mate van misbruik was hoog in beide condities, waarbij 100% van de implementaties minstens één beveiligingsfout bevatte.

Security Awareness (RQ3)

Ontwikkelaars toonden beperkt beveiligingsbewustzijn tijdens de interactie met Copilot.

Prompting: Slechts 7 van de 44 deelnemers noemden expliciet beveiliging in hun prompts. In de meeste gevallen was de beveiligingstaal letterlijk overgenomen uit de taakbeschrijving in plaats van een oprechte zorg. Slechts twee deelnemers toonden een bewuste beveiligingsoverweging in hun prompts.
Zelfevaluatie: Er was een significante mismatch tussen de waargenomen en werkelijke beveiliging. De meeste deelnemers geloofden dat hun oplossingen veilig waren, ondanks de aanwezigheid van kritieke kwetsbaarheden.
Post-Studie Prompting: Wanneer expliciet geprompt werd om "de code te beoordelen en te verbeteren op basis van best practices voor beveiliging", corrigeerde Copilot succesvol sommige JSSE-misbruiken (bijv. M1 en M2) en bood aanbevelingen voor OAuth-tokenopslag. Het faalde echter in het adresseren van andere kritieke OAuth-problemen zoals het ontbreken van state parameters of PKCE, wat wijst op beperkingen in de security-redenering voor complexe flows.

Betekenis en Claims

Het artikel claimt dat de beveiligingsuitdagingen in AI-ondersteunde ontwikkeling niet alleen een beperking zijn van de output van het AI-model, maar ook een ontwikkelaar-bewustzijns-probleem zijn. Zelfs wanneer zij werden geïnformeerd dat beveiliging zou worden geëvalueerd, hielden ontwikkelaars zich zelden bezig met de tool vanuit een beveiligingsperspectief en slaagden zij er vaak niet in onveilige code te herkennen.

De studie concludeert dat hoewel AI-assistenten zoals Copilot de productiviteit en functionele correctheid verhogen, ze momenteel niet in staat zijn ontwikkelaars een volledig veilige implementatie te laten produceren van security API's. De auteurs benadrukken dat:

Blind vertrouwen op AI-gegenereerde code ernstige kwetsbaarheden introduceert.
Security-georiënteerde prompting verbeteringen kan opleveren, maar geen panacee is voor alle typen misbruik.
Effectief gebruik van AI in veilige ontwikkeling vereist dat ontwikkelaars een sterke basis behouden in beveiligingsprincipes en de AI-gegenereerde code kritisch beoordelen.

De auteurs positioneren dit werk als een fundamentele stap naar het begrijpen van de intersectie tussen AI en softwarebeveiliging, en roepen op tot toekomstig onderzoek naar security-bewuste tooling, verbeterde API-bruikbaarheid en een betere afstemming van LLM's op best practices voor beveiliging.