In een vorige LinkedIn post over vibe coding dat verkeerd afliep, had ik het over de gevaren van gewoon meegaan met de “vibes” en waarom we moeten blijven waken over de AI gegenereerde code. Deze blogpost gaat over een ander onderwerp, namelijk secure coding bij het gebruik van een AI assistant tool of een ontwikkelingsplatform dat AI-generated code achter de schermen gebruikt.
Secure coding en AI zijn niet altijd de beste vrienden. Laten we beginnen met het uitleggen van een misschien minder bekende cyberaanval die een “supply chain attack” wordt genoemd en hoe deze in verband staat met AI-generated code. Het is de natte droom van een hacker om te infiltreren in de originele broncode of bibliotheken die worden gebruikt door softwaretoepassingen over de hele wereld. De missie van de hacker is om kwaadaardige code te planten waarmee gegevens en wachtwoorden kunnen worden gestolen. De softwaretoepassing wordt gebouwd met de kwaadaardige code erin en vervolgens verzonden door een vertrouwde software distributeur. Hoogstwaarschijnlijk blijft deze kwaadaardige code lange tijd onopgemerkt, waardoor de hacker genoeg tijd heeft om je vertrouwde gegevens te stelen.
Deze “supply chain attack” is niet nieuw en vereist veel vaardigheden en tijd om voor te bereiden, maar als hij slaagt, is het waarschijnlijk de krachtigste cyberaanval. Stel je eens voor wat er zou kunnen gebeuren als een webserver of een populaire online vergaderapplicatie die over de hele wereld wordt gebruikt, bij de bron wordt gecompromitteerd. In mei 2001 werd de open-source Apache webserver, die op dat moment meer dan 60% van alle websites ter wereld hostte, bijna slachtoffer van een supply chain attack. Een openbare server die de broncode repositories en binaire releases van de Apache webserver hostte, werd gecompromitteerd. Gelukkig werd deze kwetsbaarheid op tijd ontdekt door de open source gemeenschap om te voorkomen dat de hackers kwaadaardige code konden injecteren.
Een recent voorbeeld van een supply chain attack vond een week geleden plaats op 8 september. Ongeveer 20 npm-pakketten werden gecompromitteerd die in totaal 2 miljard keer per week worden gedownload. De gecompromitteerde npm-pakketten werden gedistribueerd via het vertrouwde npm-register, maar bevatten kwaadaardige code die je gebruikersnaam en wachtwoord onderschepte om je portemonnee met cryptovaluta te stelen. De kwaadaardige code was ook versluierd om zo lang mogelijk verborgen te blijven. De hacker kon infiltreren door controle te krijgen over een Github-account van een vertrouwde open source-medewerker. Het begon allemaal met een phishing e-mail om MFA (Multi Factor Authentication) in te schakelen die legitiem leek, maar werd verzonden vanaf een kwaadaardige domeinnaam nmpjs.help die slechts een paar dagen eerder op 5 september was geregistreerd.
Nu er steeds meer code wordt gegenereerd door een AI-agent of een vibe coding platform, is AI-generated code dan nog steeds kwetsbaar voor supply chain attacks?
Het antwoord is simpelweg ja. Hoewel AI-agenten steeds beter worden in het genereren van syntactisch correcte codevoorbeelden, zijn ze nog steeds erg slecht in het genereren van secure code. Een recent GenAI beveiligingsrapport laat zien dat AI in de loop der jaren bijna exponentieel beter is geworden in het genereren van syntactisch correcte code die ook daadwerkelijk compileert. De grafiek laat echter ook een vlakke lijn zien voor schendingen van AI-code ten opzichte van de OWASP Top 10 Beveiligingsbedreigingen (zie rode lijn). De OWASP Top 10, zoals code-injectie, wordt eenvoudig gedetecteerd door statische code analyse programma’s zoals de SonarQube OWASP-plugin.
Maar waarom genereert een AI-agent niet vanaf het begin veilige code?
Je moet onthouden dat een AI-agent een “inferrer” is, het is niet iets deterministisch zoals een code compiler. Dit betekent dat een AI-agent het meest waarschijnlijke volgende onderdeel (of token, als je wilt) zal kiezen om te genereren voor de programmeercode. Een van de redenen waarom een agent niet altijd veilige code schrijft, is dat een AI-agent getraind wordt op veel publieke codevoorbeelden die vrij beschikbaar zijn in technische artikelen op het internet.
Deze codevoorbeelden worden vaak gebruikt om een bepaalde coderingstechniek of programmeerconcept te demonstreren en zijn vaak alleen voor demonstratiedoeleinden. Ze geven vaak een tutorial over hoe je snel aan de slag kan gaan, waarbij minder veilige technieken worden gebruikt zoals shared access keys en het niet implementeren van strikte autorisatiecontrole. Deze artikelen besteden geen aandacht aan secure coding technieken omdat ze een bepaald concept willen uitleggen. Dingen als security by design en zero trust architecture (“never trust, always verify”) worden weggelaten om te focussen op het concept waar het om gaat.
We blijven nog steeds op hetzelfde onderwerp van een supply chain attack. Zoals we allemaal weten, kan een AI-agent last hebben van hallucinaties, waarbij hij vaak zeer overtuigende antwoorden geeft die simpelweg niet kloppen. Er is een nieuwe term die “package hallucinations” heet voor AI-generated code. AI-generated code verwijst naar softwarepakketten die gebruikt zouden moeten worden, maar gewoon niet bestaan in de echte wereld.
Het grootschalige onderzoek dat is gepubliceerd in de wetenschappelijke paper “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs” testte 576.000 door AI gegenereerde codevoorbeelden. Bijna 20% daarvan bevatten koppelingen naar bibliotheken met broncode die gewoon niet bestaan. De resultaten varieerden een beetje afhankelijk van de programmeertaal die werd gebruikt om de code te genereren. Bij verschillende LLM’s kwamen dezelfde niet-bestaande code libraries terug in de gegenereerde code. Als hacker zou je dit patroon kunnen detecteren en de softwarepakketten publiceren die de AI-agent zei te gebruiken.
Het verschil is dat de gehallucineerde softwarepakketten nu bestaan in de echte wereld waarnaar de AI-agent verwijst. Dit type van supply chain attack staat ook bekend als slopsquatting. Hackers registreren de aanbevolen “hallucinated packages” op vertrouwde distributieplatforms. Deze softwarepakketten bevatten kwaadaardige code om je softwaretoepassing bij de bron te vergiftigen. Het probleem is dat je de gegenereerde code te veel vertrouwt, maar niet controleert of de voorgestelde code libraries die je gaat downloaden ook betrouwbaar zijn.
Over vibe coding gesproken, het vibe coding platform Lovable had ook zijn aandeel in beveiligingsproblemen met AI-gegenereerde code. Ongeveer 10% van de ingezette webapplicaties die zijn gescand op beveiligingsproblemen, waren blootgesteld aan hackers die toegang kregen tot gegevens zoals persoonlijke en financiële informatie. API-sleutels van cloud providers zijn openbaar beschikbaar. API-sleutels van cloudplatformen zijn bijzonder aantrekkelijk voor hackers omdat ze hiermee hun phishingsites en andere kwaadaardige toepassingen gratis kunnen uitvoeren op een cloudplatform. Nogmaals, het is een goed geheugensteuntje om altijd een budgetlimiet in te stellen op je cloud provider account.
Veel gebruikers van vibe coding hebben geen technische achtergrond en hebben vaak weinig of geen kennis van secure coding. Ze vertrouwen erop dat het vibe coding platform de beveiligingsaspecten van de geïmplementeerde webapplicatie afhandelt, maar deze platforms hebben nog een lange weg te gaan. Zoals Lovable zei in een post op X van 29 mei, “We’re not where we want to be in terms of security, and we’re committed to continuing to improve the security posture for all Lovable users”.
Ik blijf waarschijnlijk in herhaling vallen, een AI-agent kan een geweldig hulpmiddel zijn voor een software engineer, maar zorg ervoor dat je nog steeds de controle behoudt. Werp altijd een kritische blik op de source code (al dan niet AI-generated) en volg zeker de AI-agent niet blindelings.