Loading…
Bij Google schrijft AI inmiddels driekwart van alle nieuwe code, en ook bij ons groeit dat aandeel in hoog tempo. Maar de techniek is goed in werkende code, niet in veilige code. Er zit een scheiding in wat AI voor je doet: het schrijft de code, niet de beveiliging. Hieronder wat dat betekent.
In het kort
Nieuwe code komt steeds vaker uit AI
Sundar Pichai, CEO van Google, meldde in april 2026 dat 75 procent van alle nieuwe code bij Google door AI wordt gegenereerd en daarna door engineers wordt goedgekeurd. Een half jaar eerder was dat 50 procent. De techniek eronder is ook meetbaar beter geworden. Op SWE-bench, de test waarbij een AI echte problemen uit bestaande software moet oplossen, loste de beste AI in 2023 nog maar 4 procent van de opgaven op. Volgens de meest recente cijfers van Stanford zitten de sterkste modellen inmiddels in de buurt van de 100 procent.
Wij zien het in ons eigen werk terug. Een groeiend deel van de code in de portalen en applicaties die wij opleveren komt uit AI-tools, en dat aandeel groeit elk kwartaal. Daardoor is beveiliging bij ons bijna dagelijks onderwerp van gesprek. Hoe sneller je bouwt, hoe belangrijker het wordt om te weten wat er niet automatisch goed gaat.
Werkende code is niet automatisch veilige code
Securitybedrijf Veracode test sinds 2025 hoe veilig AI-gegenereerde code is, inmiddels over meer dan 150 taalmodellen. In 45 procent van de gevallen bevat de code een kwetsbaarheid uit de OWASP Top 10, de standaardlijst van de meest voorkomende beveiligingsfouten in webapplicaties. Bij de herhaling van de test dit voorjaar zat de syntactische correctheid boven de 95 procent, dus de code werkt bijna altijd, terwijl het securitypercentage rond de 55 procent bleef hangen. Modellen leren van publieke code, waarvan een flink deel zelf onveilig of verouderd is, en ze weten niet wat er in jouw situatie gevoelig ligt.
Je vraagt om een functie, je krijgt een functie. Om een slot vraag je niet, dus dat krijg je ook niet.
Overigens wordt AI wel snel beter in het opsporen en oplossen van kwetsbaarheden van fouten in de code. Leveranciers bouwen beveiliging steeds vaker standaard in hun tools, dus de verwachting is dat deze kloof kleiner wordt. Voorlopig is deze kloof er nog en zullen de bouwers zelf nog dus goed op moeten letten.
Fouten vallen in drie lagen
Kijk je terug op wat er in de praktijk misgaat, dan valt dat vrijwel altijd in dezelfde drie categorieën uiteen. Onderaan zit de code zelf, met de klassieke programmeerfouten. Daarboven zit de configuratie: alle instellingen rondom die code, waar één vergeten vinkje in één keer alles kan openzetten. Bovenaan zitten de mensen die er dagelijks mee werken, de laag die volgens de cijfers het vaakst een rol speelt bij datalekken. Wie alleen naar de code kijkt, ziet dus een derde van het risico.
Laag 1: de code
Op codeniveau gaat het om herkenbare fouten, zoals een invoerveld dat niet controleert wat erin wordt getypt, waardoor iemand via het zoekvak commando's naar de database kan sturen. Deze laag is het makkelijkst te ondervangen, met automatische scanners in het bouwproces en met review door iemand die weet waar hij op moet letten. De vraag die je stelt is bepalend: niet alleen "werkt het", maar ook "wat gebeurt er als iemand hier iets invult wat ik niet had bedoeld".
Laag 2: de configuratie
Dit is de laag waar AI je niets uit handen neemt, want het gaat niet om code maar om instellingen. De gevolgen van één fout zijn hier het grootst: één vergeten instelling kan een complete database openzetten.
Het bekendste voorbeeld is Row Level Security, kortweg RLS: een instelling in de database die per rij bepaalt wie iets mag zien of aanpassen. Staat die uit, dan kan iedereen die het adres van je database kent de hele inhoud opvragen, en dat adres staat in de code die elke browser downloadt. Een securityonderzoeker bekeek in mei 2025 ruim 1.600 apps die met een AI-bouwplatform waren gemaakt. Bij 170 daarvan kon je de database uitlezen zonder in te loggen, met echte klantgegevens erin.
Andere instellingen uit dezelfde categorie:
Er is een subtielere variant die we regelmatig tegenkomen. Een app controleert netjes of je bent ingelogd, maar vergeet te controleren of jij dit specifieke record mag zien. Je bent klant 123, je verandert het nummer in de adresbalk naar 124, en je leest het dossier van iemand anders. Ingelogd is niet hetzelfde als bevoegd. Deze fout heet IDOR en valt onder Broken Access Control, de nummer 1 in de OWASP Top 10.
Laag 3: de mensen
Het jaarlijkse onderzoek van Verizon naar datalekken, over meer dan 22.000 bevestigde incidenten, laat zien dat de menselijke factor bij 62 procent van de datalekken een rol speelt. Een hergebruikt wachtwoord, een link die iemand opende, een bestand dat op de verkeerde plek belandde.
Een nuance die vaak wordt overgeslagen. De mens is de meest voorkomende factor, maar niet meer de meest voorkomende ingang: het exploiteren van een technische kwetsbaarheid staat in 2026 bovenaan met 31 procent, gestolen inloggegevens zakten naar 13 procent. Over de hele aanval bekeken duiken die inloggegevens nog steeds in bijna vier op de tien datalekken op. Aanvallers komen binnen via een gat en gaan daarna verder met wachtwoorden.
Nieuw risico: het gebruik van niet-goedgekeurde AI-tools door medewerkers verdrievoudigde volgens hetzelfde onderzoek naar 45 procent. Broncode, klantgegevens en contracten verdwijnen zo naar tools die niemand overziet.
De maatregelen zijn niet spannend, wel effectief. Multi-factor authenticatie op alle beheeraccounts. Een wachtwoordmanager zodat elk account een uniek wachtwoord heeft. Lange wachtwoordzinnen boven korte cryptische reeksen, want dat is sinds 2025 ook het officiële advies van NIST. Test- en demoaccounts opruimen voordat een systeem live gaat.
Waarom het nooit één maatregel is
De verleiding is groot om te zoeken naar dé oplossing. Die bestaat niet. Beveiliging is de som van veel kleine dingen, waarvan elk afzonderlijk onbelangrijk lijkt. Snelheid vergroot dat effect: onderzoek naar codebases bij grote ondernemingen laat zien dat teams die met AI werken drie tot vier keer zoveel wijzigingen doorvoeren, en dat het aantal beveiligingsbevindingen daarin nog sneller stijgt. Meer tempo levert zelden één grote fout op, wel veel meer kleine.
Daarom testen wij niet alleen of iets werkt, maar ook of het misbruikt kan worden. Inloggen als gebruiker A en het nummer in de adresbalk veranderen naar dat van gebruiker B. Kijken wat er in de code zit die de browser downloadt. Hetzelfde formulier honderd keer versturen om te zien of je gestopt wordt.
Zelf een systeem bouwen met AI gegenereerde code? Let dan in ieder geval op deze punten:
Niet jouw expertise? Dan doen wij het
De meeste bedrijven hebben geen behoefte om na te denken over rate limiting, secrets en rolrechten. Dat hoeft ook niet als je dit uitbesteed. Bij elk project lopen wij deze punten af en maken we per situatie een keuze, want een klantportaal met persoonsgegevens vraagt iets anders dan een interne rapportagetool. Die afweging maken wij en we leggen uit waarom.
Weet je nog niet wat je nodig hebt? Begin dan met onze AI Audit. We nemen je bedrijf onder de loep, praten met de mensen die het werk doen, en brengen in kaart waar AI en automatisering jullie het meeste tijd en geld opleveren. Je krijgt een concreet rapport met prioriteiten, geen jargon en geen verplichtingen.
Bel of mail ons voor een kennismaking.
Bronnen
Cloud Security Alliance. (2026). AI-generated code vulnerability surge 2026 [Research note]. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/
OWASP Foundation. (2021). A01:2021 – Broken access control. OWASP Top 10:2021. https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
Palmer, M. (2025, 29 mei). Statement on CVE-2025-48757. https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/
Pichai, S. (2026, 22 april). Cloud Next '26: Momentum and innovation at Google scale. Google. https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/
Stanford Institute for Human-Centered Artificial Intelligence. (2025). The 2025 AI Index report. https://hai.stanford.edu/ai-index/2025-ai-index-report
Stanford Institute for Human-Centered Artificial Intelligence. (2026). The 2026 AI Index report. https://hai.stanford.edu/ai-index/2026-ai-index-report
Temoshok, D., Choong, Y.-Y., Regenscheid, A., Galluzzo, R., Fenton, J., Richer, J., & Lefkovitz, N. (2025). Digital identity guidelines: Authentication and authenticator management (NIST Special Publication 800-63B-4). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-63B-4
Veracode. (2026). Spring 2026 GenAI code security update: Despite claims, AI models are still failing security. https://www.veracode.com/blog/spring-2026-genai-code-security/
Verizon. (2026). 2026 Data breach investigations report. https://www.verizon.com/business/resources/reports/dbir/
Vond je dit artikel waardevol? Deel het.
