Er gaat op dit moment een nieuwe klasse software naar productie. Het werkt. Het heeft een UI. Het verwerkt betalingen, slaat persoonsgegevens op, soms koppelt het aan ERP-systemen. En niemand die het heeft opgeleverd, heeft de code echt gelezen.
Welkom in het vibe coding-tijdperk, en het beveiligingsprobleem waar veel te weinig over wordt gesproken.
Wat Is Vibe Coding?
Andrej Karpathy (ex-OpenAI) bedacht de term in februari 2025. Het idee: beschrijf wat je wilt in gewone taal, laat de AI de code schrijven, besteed er niet te veel aandacht aan. "Volledig meegaan in de vibes."
De tools die dit mogelijk maken: Lovable, Bolt.new, Cursor, v0, Replit, Claude Code, GitHub Copilot. Sommige zijn no-code platforms waar een niet-ontwikkelaar kan prompten tot een uitgerold webapplicatie. Andere zijn AI-codeerassistenten bovenop bestaande IDE's.
Collins Dictionary riep "vibe coding" uit tot Woord van het Jaar 2025. In 2026 gebruikt 92% van de Amerikaanse ontwikkelaars een of andere vorm van AI-codeerhulp. Naar schatting is 46% van alle code die via GitHub Copilot wordt geaccepteerd nu AI-gegenereerd, op weg naar 60% voor eind van het jaar.
63% van de vibe coding-gebruikers identificeert zichzelf als niet-ontwikkelaar. Dat is het deel dat je wakker zou moeten houden.
De Cijfers Zijn Slecht
Escape.tech scande meer dan 5.600 uitgerold vibe-coded applicaties en vond:
- 65% had beveiligingsproblemen
- 58% bevatte minimaal één kritieke kwetsbaarheid
- 400+ blootgestelde secrets in de dataset
- 175 gevallen van blootgestelde persoonsgegevens waaronder bankrekeningdata
Veracode testte 100+ LLM's op 80 codeertaken en vond dat 45% van de AI-gegenereerde code OWASP Top 10-kwetsbaarheden introduceert. Die score is niet verbeterd over meerdere testcycli van 2025 tot vroeg 2026, ondanks beweringen van leveranciers. Java scoort het slechtst met een foutkans van 72%. Zelfs Python en JavaScript schommelen tussen de 38-45%.
CodeRabbit's analyse van 470 GitHub pull requests laat zien dat door AI geschreven code XSS-kwetsbaarheden produceert met 2,74 keer de frequentie van door mensen geschreven code.
Een audit van Lovable-gebouwde apps in Zweden vond 170 van 1.645 productieapplicaties met exploiteerbare SQL injection en XSS-kwetsbaarheden. Dat is 10,3% van live apps die echte gebruikers bedienen.
Georgetown CSET vond XSS in 86% van de AI-gegenereerde codesamples, getest over vijf grote LLM's.
En de cijfer die het hardst aankomt: AI-ondersteunde ontwikkelaars bij Fortune 50-bedrijven produceren commits 3-4x zo snel als hun collega's, maar introduceren beveiligingsbevindingen op 10x het tempo. Je levert sneller op én maakt meer kapot, tegelijkertijd.
CVE's Worden Nu Toegeschreven aan AI-Tools
Georgia Tech's Systems Software and Security Lab lanceerde de Vibe Security Radar in mei 2025 om CVE's formeel toe te schrijven aan AI-codeertools. De methodiek: traceer de commit die een kwetsbaarheid oploste terug naar de bron om te bepalen of een AI-tool de fout introduceerde.
De trend is verontrustend:
- Januari 2026: 6 CVE's toegeschreven aan AI-gegenereerde code
- Februari 2026: 15 CVE's
- Maart 2026: 35 CVE's
Van de 74 bevestigde gevallen is Claude Code verantwoordelijk voor 27, GitHub Copilot voor 4, Devin voor 2, en Cursor en Aether elk voor 1.
Onderzoekers schatten dat het werkelijke aantal 5-10 keer hoger ligt, omdat de meeste AI-tools geen commit-metadata achterlaten, waardoor attributie onmogelijk wordt. Dat projecteert op 400-700 door AI geïntroduceerde kwetsbaarheden in open-source code in alleen al Q1 2026.
Het NCSC (de Britse tegenhanger van ons NCSC-NL) benoemde dit direct op de RSA Conference in maart 2026. CEO Richard Horne riep de securitygemeenschap op om safeguards te ontwikkelen rond vibe coding en omschreef de situatie als een "fundamenteel probleem met de kwaliteit van de technologie die we gebruiken."
De Kwetsbaarheidspatronen Zijn Voorspelbaar
Dit is het bruikbare gedeelte voor iedereen die beveiligingswerk doet: vibe-coded applicaties falen op consistente, herkenbare manieren. OX Security presenteerde op RSAC 2026 dat LLM's fungeren als "junior developers" met structurele blinde vlekken. De patronen:
Hardcoded secrets. AI-tools plaatsen Stripe-sleutels, OpenAI API-sleutels, databasegegevens en cloudtokens direct in frontend JavaScript. GitGuardian documenteerde 28,65 miljoen nieuwe hardcoded secrets in publieke GitHub-commits tijdens 2025, een stijging van 34% jaar op jaar. Commits met AI-hulp lekken secrets met een percentage van 3,2% versus 1,5% voor commits door mensen alleen. In april 2026 lekte één prominent vibe-coded AI-platform 1,5 miljoen API-sleutels omdat de oprichter het had uitgerold zonder een enkele beveiligingscontrole.
Gebroken toegangscontrole. De Tea-app lekte in 2025 privé DM's van gebruikers naar andere gebruikers, omdat de AI-gegenereerde toegangslogica geen server-side handhaving had. Client-side authenticatie die omzeild kan worden met browser-ontwikkelaarstools is extreem gebruikelijk in door Bolt en Lovable gegenereerde applicaties.
Ontbrekende Supabase RLS. De dominante stack voor vibe-coded SaaS is React-frontend + Supabase-backend + Vercel-deployment. Supabase gebruikt Row Level Security (RLS) policies om datatoegang te beperken. AI-tools genereren routinematig het databaseschema en de API-aanroepen, maar slaan RLS-configuratie volledig over, wat betekent dat elke geauthenticeerde gebruiker elke rij kan opvragen.
SSRF overal. Een studie van Tenzai in december 2025 testte vijf grote AI-codeeragents die identieke functies bouwden. Elk van hen introduceerde Server-Side Request Forgery. Vijf van de vijf, 100%. Het patroon: een AI-gegenereerde "haal URL op voor preview"-functie die elke URL accepteert, inclusief http://169.254.169.254/latest/meta-data/ (AWS instance metadata).
Slopsquatting. AI-modellen hallucineren pakketnamen op voorspelbare, reproduceerbare wijze. Aanvallers registreren die namen van tevoren op npm en PyPI. De aanval vereist geen phishing. Het exploiteert de statistische voorspelbaarheid van wat AI-tools hallucineren als je ze vraagt een bepaald type afhankelijkheid toe te voegen.
NEXT_PUBLIC-misbruik. In Next.js-projecten (de standaardkeuze van de meeste AI-codeerplatforms) wordt elke omgevingsvariabele met het voorvoegsel NEXT_PUBLIC_ gebundeld in de client-side JavaScript en is zichtbaar voor iedereen die de broncode bekijkt. AI-tools labelen gevoelige backend-variabelen routinematig onjuist.
Hoe Je een Vibe-Coded App Herkent
Hier wordt het interessant vanuit een pentest- en reconnaissanceperspectief. Onderzoekers analyseerden in een januari 2026-paper op arXiv 33.580 pull requests van vijf grote AI-codeeragents en behaalden een F1-score van 97,2% bij het identificeren van welk tool de code had gegenereerd, puur op basis van commit-metadata.
De gedragskenmerken per tool:
Claude Code: Hoge conditionele dichtheid (27,2%), verhoogde commentaardichtheid (19,8%). Code is goed gedocumenteerd en controlestroomintensief. Wordt bij misclassificatie het vaakst verward met Devin.
GitHub Copilot: Langere PR-beschrijvingen (38,4%), hoge wijzigingsconcentratie (24,9%). Gerichte codewijzigingen met gedetailleerde uitleg.
OpenAI Codex: Uitgebreide meerregelige commit-berichten (67,5%). Meer documentatie dan andere agents.
Cursor: Gebruikt regelmatig opsommingstekens (17,2%) en hyperlinks (12,8%) in PR-beschrijvingen. Gestructureerde, referentierijke beschrijvingen.
Devin: Meerregelige commit-berichten gecombineerd met verspreide wijzigingen over veel bestanden (8,2%), wat wijst op granulaire autonome commits.
Voor live applicaties waarvan je de broncode niet kunt zien, werkt fingerprinting op infrastructuur- en HTML-niveau:
Platformkenmerken:
- Een Lovable-build laadt
gpteng.co-scripts en heeft kenmerkende componentnaampatronen - Bolt-apps hebben specifieke Vite-buildhandtekeningen en kenmerkende
_app-structuren - Framer-gebouwde sites serveren assets via
framerusercontent.com - v0 genereert kenmerkende Tailwind-klassencombinaies en shadcn/ui-componentstructuren
- De meeste vibe-coded apps deployen naar Vercel; een domein als
project-naam-abc123.vercel.appis een vrijwel zekere aanwijzing, zelfs na overstap naar een eigen domein blijven de Vercel-response-headers aanwezig
Commitpatroonkenmerken (voor open repositories): Snelle opeenvolgende commits als "Fix bug in form validation", "Add responsive styles to hero section", "Implement contact form" binnen uren van elkaar zijn een sterke indicatie van AI pair programming. Menselijke ontwikkelaars werken niet zo.
Codestructuurkenmerken:
- Uniforme naamgevingsstijl voor functies door de gehele codebase (mensen zijn inconsequent)
- Geen dode code, geen uitgecommentarieerde experimenten, geen TODO/FIXME-archeologie
- Elk component netjes gescheiden, elk bestand de zelfde lengte
- Authenticatie- en database-toegangspatronen identiek gekopieerd over meerdere bestanden in plaats van geabstraheerd
Tools zoals isitvibecoded.com automatiseren dit, met coverage van 35+ AI-tools, een betrouwbaarheidsscore en de exacte HTML/script-indicatoren die het gebruikt.
Het Nederlandse NIS2-Probleem
Dit is specifiek relevant voor de Nederlandse en Belgische markt vanwege waar vibe-coded software terechtkomt.
NIS2 is van kracht en Nederlandse organisaties in essentiële en belangrijke sectoren dragen nu wettelijke verplichtingen rond supply chain-risicobeheer, kwetsbaarheidsmelding en incidentrapportage binnen 72 uur. Het probleem: een aanzienlijk deel van de interne tooling, klantportals en B2B SaaS die nu worden verkocht aan NIS2-verplichte organisaties, is gebouwd met AI-codeertools door oprichters of junior developers die nooit van OWASP hebben gehoord, laat staan van RLS-misconfiguraties.
Het supply chain-aanvalsoppervlak is reëel. Als jouw NIS2-verplichte klant gebruikmaakt van een vibe-coded leveranciersportaal zonder RLS-policies, liggen hun gegevens open. De meldplicht is aan hen, niet aan de startup-oprichter die het portaal in een weekend heeft gebouwd.
53% van de teams die AI-gegenereerde code hebben uitgerold, ontdekte later beveiligingsproblemen die de initiële review hadden overleefd. Die ontdekking vindt vaak plaats tijdens een incident, niet tijdens een geplande audit.
Wat Je Er Concreet Aan Kunt Doen
Als je bouwt met vibe coding-tools:
Voer deze vijf controles uit voordat je iets uitrolt met echte gebruikers of echte data:
grep -r "NEXT_PUBLIC_" .env- gevoelige informatie hoort niet in een NEXT_PUBLIC-variabele- Controleer elke Supabase-tabel op RLS:
SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';- als rowsecurity false is op een tabel met gebruikersdata\, heb je een probleem - Doorzoek de gebouwde JS-bundle op zichtbare secrets:
grep -E "(sk_live|pk_live|eyJ|AIza|AKIA)" dist/ - Bekijk elke
fetch()-aanroep die gebruikersinvoer als URL accepteert - Controleer CORS-headers op je API:
curl -H "Origin: https://kwaadaardig.nl" -v https://jouwapp.nl/api/alles
Tools die het waard zijn voor de lancering: Snyk (afhankelijkheids-CVE's), Semgrep (codepatronen), en een live scanner zoals VibeCheck of Vibe App Scanner voor configuratieproblemen die Snyk niet oppikt.
Als je vibe-coded apps test voor een klant:
De standaard OWASP-checklist geldt nog steeds, maar prioriteer deze bevindingen op basis van wat AI-tools consequent missen:
- Supabase/Firebase RLS-policies (de meest voorkomende bevinding in AI-app-audits)
- SSRF via elke URL-accepterende functie (5/5 AI-tools introduceerden dit in gecontroleerde tests)
- Client-side auth bypass (controleer of authenticatiehandhaving uitsluitend in frontend JavaScript zit)
- Blootgestelde
.env-bestanden en secrets in gebouwde JS (tool: trufflesecurity/trufflehog) - MCP-serverconfiguratie als de app AI-agents integreert (CVE-2025-54136 MCPoison is het controleren waard)
Het goede nieuws: de kwetsbaarheidspatronen zijn voorspelbaar genoeg dat een gerichte checklist het merendeel van het kritieke aanvalsoppervlak afdekt. Het slechte nieuws: de meeste traditionele SAST-tooling is gebouwd voor door mensen geschreven code en weet niet dat het op RLS-misconfiguraties of NEXT_PUBLIC-misbruik moet controleren.
De Conclusie
Vibe coding gaat nergens heen. 46% van de code op GitHub is al AI-gegenereerd. De Nederlandse IT-sector rolt nu vibe-coded tools uit in productie, ook in gereguleerde omgevingen. De beveiligingsaannames in die code zijn fout, op consistente en exploiteerbare manieren.
De vraag is niet of je AI-codeertools moet gebruiken. De vraag is of je een beveiligingsgate hebt tussen "AI heeft dit gegenereerd" en "dit staat in productie en verwerkt klantdata."
De meeste organisaties hebben die gate niet. Dat is het probleem, en de kans.
