Vibe coding, het bouwen van software door grotendeels op gevoel en via natuurlijke taal samen te werken met een AI-coding-assistent, is in korte tijd van curiositeit naar mainstream werkwijze gegaan. Met GitHub Copilot, Claude Code, Cursor en ChatGPT bouwen ontwikkelaars en zelfs niet-ontwikkelaars in dagen wat vroeger weken kostte.
Snelheid is niet het probleem. Het probleem is wat er onopgemerkt meekomt: onveilige patronen, ontbrekende autorisatiecontroles, kwetsbare dependencies en applicaties die weliswaar werken, maar niet bestand zijn tegen een geoefende aanvaller. In dit artikel leggen we uit waarom dat gebeurt, wat de concrete risico’s zijn, en hoe je een AI-gebouwde applicatie alsnog productieklaar en veilig maakt.
Inhoudsopgave
- Wat is vibe coding, en waarom groeit het zo snel?
- Waarom AI dramatisch versnelt, maar niet automatisch beveiligt
- De concrete risico’s van AI-gegenereerde code
- Waarom hosting alleen niet genoeg is
- OWASP Top 10: het fundament van applicatiebeveiliging
- Secure Development Lifecycle en Security by Design
- DevSecOps: beveiliging in de pijplijn, niet achteraf
- ISO 27001 en NEN 7510-principes toegepast op softwareontwikkeling
- Least privilege en defense in depth in de praktijk
- Hoe MonkeySoft AI-gegenereerde code beoordeelt en hardened
- Pentest remediation: van bevindingen naar opgeloste kwetsbaarheden
- Praktijkvoorbeelden: van vibe-coded prototype naar productieklare applicatie
- Veelgestelde vragen
- Conclusie
Wat is vibe coding, en waarom groeit het zo snel?
Kort antwoord: vibe coding is softwareontwikkeling waarbij een ontwikkelaar via prompts en gevoel samenwerkt met een AI-assistent, met als resultaat sterk versnelde ontwikkeling maar minder diepgaand begrip van elke gegenereerde regel code.
De term omschrijft een werkwijze die inmiddels bij vrijwel elk softwarebedrijf voorkomt: een ontwikkelaar beschrijft in natuurlijke taal wat een feature moet doen, de AI-assistent genereert de implementatie, en de ontwikkelaar test of het werkt en itereert verder op basis van gevoel in plaats van regel-voor-regel review. Voor prototyping en interne tools is dit razendsnel en effectief.
De groei is verklaarbaar: AI-coding-assistenten zijn de afgelopen jaren sterk verbeterd, de tools zijn breed beschikbaar en goedkoop, en de druk om snel te leveren is in vrijwel elke organisatie toegenomen. Het resultaat is dat steeds meer productiecode, ook bij bedrijven met gevoelige klantdata, deels of grotendeels AI-gegenereerd is.
Waarom AI dramatisch versnelt, maar niet automatisch beveiligt
Kort antwoord: AI-modellen optimaliseren voor werkende code die aan de prompt voldoet, niet voor code die bestand is tegen misbruik, en missen bovendien de bredere context van de bestaande codebase.
Een AI-coding-assistent kent geen volledig beeld van de architectuur, de bestaande autorisatielogica, de tenant-scheiding tussen klanten, of de historische beveiligingsincidenten van een organisatie. Het model genereert het meest waarschijnlijke antwoord op een prompt, gebaseerd op trainingsdata die een enorme hoeveelheid voorbeeldcode bevat, waarvan een deel verouderd of onveilig is.
Daarnaast geldt een menselijk effect: wanneer code “gewoon werkt”, is de neiging om verder te bouwen groter dan de neiging om kritisch te reviewen. Dat effect is niet nieuw, maar wordt door de snelheid van AI-generatie versterkt: er wordt simpelweg meer code geaccepteerd per uur, met minder tijd per regel voor reflectie.
De concrete risico’s van AI-gegenereerde code
Kort antwoord: de meest voorkomende risico’s bij AI-gegenereerde code zijn onveilige patronen, ontbrekende autorisatiecontroles, zwakke input-validatie, onveilige API’s, kwetsbare dependencies en ontbrekende logging.
Onveilige code en verouderde patronen
AI-modellen zijn getraind op grote hoeveelheden publieke code, waaronder verouderde tutorials en voorbeelden die niet meer als best practice gelden. Het resultaat: code die functioneel werkt, maar patronen gebruikt die al jaren als onveilig worden beschouwd, bijvoorbeeld directe string-concatenatie in database-queries in plaats van parameterized queries.
Ontbrekende autorisatiecontroles
Een AI-assistent implementeert vaak precies wat gevraagd wordt: een endpoint dat data teruggeeft. Of die data ook echt bij de aanvragende gebruiker hoort, wordt zelden proactief gecontroleerd, tenzij dat expliciet in de prompt staat. Dit leidt tot broken access control, structureel de meest voorkomende kwetsbaarheidscategorie in moderne webapplicaties.
Zwakke input-validatie
Invoervelden en API-parameters worden door AI vaak functioneel correct verwerkt, maar niet consequent gevalideerd op lengte, type, formaat of kwaadaardige inhoud. Dat maakt de weg vrij voor injection-aanvallen en onverwacht applicatiegedrag.
Onveilige API’s
API-endpoints die door AI worden gegenereerd, missen regelmatig rate limiting, correcte authenticatie-eisen per endpoint, of consistente foutafhandeling die geen interne details lekt aan een aanvaller.
Dependency-kwetsbaarheden
AI-assistenten stellen geregeld pakketten voor die verouderd zijn, bekende kwetsbaarheden bevatten, of in het ergste geval helemaal niet bestaan: een gehallucineerde pakketnaam die een aanvaller vervolgens zelf als malware kan registreren, een reeel supply-chain-risico dat inmiddels ook door onderzoekers is gedocumenteerd.
Ontbrekende logging en auditing
Zonder expliciete instructie genereert AI zelden de logging die nodig is om een incident achteraf te herleiden: wie deed wat, wanneer, en met welk resultaat. Zonder auditing is detectie van misbruik nagenoeg onmogelijk.
Waarom hosting alleen niet genoeg is
Kort antwoord: veilige hosting beschermt de infrastructuur, niet de applicatielogica; een kwetsbaarheid in de code blijft misbruikbaar ongeacht hoe goed de server daaronder beveiligd is.
Een veelvoorkomende misvatting: “onze hosting is beveiligd, dus onze applicatie is veilig.” Hosting bij een gerenommeerde partij regelt netwerkbeveiliging, patchmanagement van het besturingssysteem en beschikbaarheid. Het regelt niet of een API-endpoint in de applicatie zelf de juiste gebruiker controleert, of een wachtwoordveld correct wordt gehasht, of een dependency een bekende kwetsbaarheid bevat.
| Laag | Wat het beschermt | Wat het niet beschermt |
|---|---|---|
| Infrastructuur / hosting | Netwerk, besturingssysteem, beschikbaarheid | Applicatielogica, autorisatie, data-validatie |
| Applicatiecode | Autorisatie, input-validatie, sessiebeheer | Verouderde dependencies, infrastructuurconfiguratie |
| Dependencies | Functionaliteit van gebruikte libraries | Kwetsbaarheden in die libraries zelf, zonder scanning |
| Proces (SDLC/DevSecOps) | Consistente kwaliteit over tijd | Eenmalige historische code die nooit is gereviewd |
Elke laag heeft een eigen verantwoordelijkheid. Een organisatie die alleen in hosting investeert, laat de andere drie lagen onbeheerd.
OWASP Top 10: het fundament van applicatiebeveiliging
Kort antwoord: de OWASP Top 10 is de internationaal meest gebruikte referentielijst van kritieke applicatierisico’s, en vormt het raamwerk waartegen AI-gegenereerde code het meest waardevol getoetst wordt.
| OWASP-categorie | Typisch risico bij vibe-coded applicaties |
|---|---|
| Broken access control | Ontbrekende autorisatiecheck op een AI-gegenereerd endpoint |
| Cryptographic failures | Wachtwoorden of tokens onvoldoende of niet versleuteld opgeslagen |
| Injection | Onvoldoende input-validatie in AI-gegenereerde queries of commando’s |
| Insecure design | Functionaliteit werkt, maar het onderliggende ontwerp houdt geen rekening met misbruikscenario’s |
| Security misconfiguration | Standaardinstellingen van frameworks/libraries ongewijzigd overgenomen |
| Vulnerable and outdated components | Door AI voorgestelde dependencies met bekende kwetsbaarheden |
| Identification and authentication failures | Zwakke sessieafhandeling of ontbrekende multi-factor authenticatie |
| Security logging and monitoring failures | Geen auditlog van gevoelige acties |
Deze lijst wordt periodiek bijgewerkt door OWASP op basis van reeel waargenomen kwetsbaarheden wereldwijd, en is de standaard-toetssteen bij elke serieuze code review of pentest.
Secure Development Lifecycle en Security by Design
Kort antwoord: een Secure Development Lifecycle bouwt beveiligingscontroles in elke fase van softwareontwikkeling in, van ontwerp tot release, in plaats van beveiliging pas te toetsen nadat de code al geschreven is.
Security by Design betekent dat beveiligingsoverwegingen onderdeel zijn van het ontwerp, niet een controle die achteraf wordt uitgevoerd. Concreet omvat een Secure Development Lifecycle:
- Threat modelling bij nieuwe features met verhoogd risico: welke aanvalspaden zijn realistisch, en zijn die afgedekt?
- Code review door een mens, met specifieke aandacht voor AI-gegenereerde bijdragen
- Geautomatiseerde securitytests in de CI/CD-pijplijn: statische analyse, dependency-scanning, linting
- Periodieke penetratietests via betrouwbare pentestpartners, vooral vóór en na grote releases
Bij AI-assisted development voegt dit een extra dimensie toe: AI-gegenereerde code wordt behandeld als een voorstel, niet als vertrouwde code, totdat het diezelfde review heeft doorstaan als handgeschreven code. Geen uitzonderingen, geen “AI-korting” op reviewstrengheid.
DevSecOps: beveiliging in de pijplijn, niet achteraf
Kort antwoord: DevSecOps integreert beveiligingscontroles direct in de CI/CD-pijplijn, zodat kwetsbaarheden worden gevonden vóórdat code productie bereikt, niet erna.
In een DevSecOps-werkwijze draaien bij elke commit of pull request automatisch: dependency-scans die kwetsbare of niet-bestaande pakketten signaleren, statische code-analyse (SAST) die veelvoorkomende kwetsbaarheidspatronen detecteert, en geautomatiseerde tests die functionaliteit borgen. Een wijziging die deze checks niet doorstaat, wordt niet gemerged.
Voor organisaties die vibe coding gebruiken, is dit precies de vangrail die ontbreekt zodra een AI-assistent code direct in een repository plaatst zonder deze pijplijn. Onze integratie- en automatiseringservaring vertaalt zich rechtstreeks naar het opzetten van deze pijplijnen voor klanten.
ISO 27001 en NEN 7510-principes toegepast op softwareontwikkeling
Kort antwoord: ISO 27001 en NEN 7510 bieden een gestructureerd kader voor informatiebeveiliging dat, toegepast op softwareontwikkeling, vereist dat toegang, wijzigingen en risico’s aantoonbaar beheerst worden, ook wanneer AI een deel van de code schrijft.
Vanuit deze normen volgen concrete eisen die direct van toepassing zijn op AI-assisted development: gescheiden ontwikkel-, test- en productieomgevingen, gedocumenteerde wijzigingsbeheerprocessen, en een aantoonbare koppeling tussen elke wijziging en een beoordeeld risico. MonkeySoft past deze principes zelf toe op de eigen ontwikkelpraktijk, zoals we eerder beschreven in hoe wij werken volgens ISO 27001, NEN 7510 en ISO 42001, inclusief een specifiek AI-beleid met een verplichte merge-gate voor AI-gegenereerde wijzigingen.
Voor zorginstellingen en organisaties die met gezondheids- of vergelijkbaar gevoelige gegevens werken, is NEN 7510 relevanter dan de generieke ISO 27001-norm, met strengere eisen aan toegangscontrole en logging, precies de gebieden waar AI-gegenereerde code het vaakst tekortschiet.
Least privilege en defense in depth in de praktijk
Kort antwoord: least privilege beperkt elke gebruiker en elk systeemonderdeel tot precies de toegang die nodig is, en defense in depth zorgt dat het falen van één beveiligingslaag niet meteen tot een volledige inbreuk leidt.
Twee fundamentele beveiligingsprincipes die bij AI-gegenereerde code extra aandacht verdienen:
- Least privilege: AI-assistenten hebben de neiging tot ruimere permissies dan strikt noodzakelijk, vooral bij infrastructuurcode (IaC). Een database-gebruiker met volledige rechten, terwijl leesrechten hadden volstaan, is een veelvoorkomende bevinding.
- Defense in depth: vertrouw niet op een enkele controle. Input-validatie op de frontend zonder validatie op de backend, of autorisatie alleen op UI-niveau zonder controle op API-niveau, zijn typische enkelvoudige-laag-fouten die met AI-gegenereerde code vaker voorkomen omdat de “voor de hand liggende” laag wel wordt geimplementeerd, en de onderliggende laag niet.
Hoe MonkeySoft AI-gegenereerde code beoordeelt en hardened
Kort antwoord: MonkeySoft reviewt AI-gegenereerde code op architectuur, autorisatie en OWASP-risico’s, herstelt gevonden kwetsbaarheden, en helpt teams een structurele werkwijze inrichten zodat vibe coding en beveiliging niet langer tegenover elkaar staan.
Concreet omvat onze aanpak:
- Code review op AI-gegenereerde applicaties, met specifieke aandacht voor autorisatielogica, tenant-isolatie en dependency-hallucinatie
- Threat modelling voor nieuwe of gewijzigde functionaliteit met verhoogd risico
- Dependency- en supply-chain-scanning, inclusief verificatie dat gebruikte pakketten daadwerkelijk bestaan en van een vertrouwde bron zijn
- OWASP-gebaseerde remediation: concrete fixes voor gevonden kwetsbaarheden, niet alleen een rapport
- Promptverbetering voor AI-coding-tools, zodat toekomstige AI-generaties vanaf het begin beter aansluiten op secure coding-standaarden
- Modernisering van bestaande applicaties naar een architectuur die logging, monitoring en CI/CD-beveiliging ondersteunt
Dit sluit aan op onze bredere maatwerk software-dienstverlening: dezelfde secure development lifecycle die wij voor eigen producten toepassen, passen we toe op AI-gegenereerde en vibe-coded applicaties van klanten.
Pentest remediation: van bevindingen naar opgeloste kwetsbaarheden
Kort antwoord: een pentestrapport levert alleen waarde op als de gevonden kwetsbaarheden daadwerkelijk en verifieerbaar worden opgelost, iets waar veel organisaties na een assessment op vastlopen.
Een professionele penetratietest levert een rapport op met bevindingen, vaak gerangschikt op risiconiveau. Het daadwerkelijke werk begint daarna: elke bevinding vertalen naar een concrete codewijziging, de fix verifieren zonder nieuwe risico’s te introduceren, en de resultaten documenteren voor een volgende audit of certificeringstraject.
MonkeySoft ondersteunt organisaties specifiek in deze remediation-fase: het interpreteren van technische bevindingen, het prioriteren op basis van daadwerkelijk risico, en het implementeren van de fix zelf, inclusief hertest. Voor organisaties die na een pentest met een lange lijst bevindingen blijven zitten zonder intern capaciteit om ze op te lossen, is dit vaak de ontbrekende schakel tussen “we hebben een rapport” en “we zijn daadwerkelijk veiliger”.
Praktijkvoorbeelden: van vibe-coded prototype naar productieklare applicatie
Kort antwoord: de meest voorkomende scenario’s zijn een snel gebouwd prototype dat klanten gaat krijgen, een interne tool die opeens bedrijfskritisch wordt, en een AI-gegenereerde API die zonder rate limiting of autorisatie live staat.
- Van prototype naar klantomgeving: een applicatie die in een paar dagen met AI is gebouwd voor intern gebruik, gaat naar een pilot met externe klanten. Autorisatie die voor één interne gebruiker nooit een probleem was, wordt bij meerdere klanten met elk hun eigen data plots kritiek.
- Interne tool wordt bedrijfskritisch: een AI-gegenereerd dashboard voor een klein team groeit uit tot een systeem waar de hele organisatie op vertrouwt, zonder dat logging, back-up of toegangsbeheer is meegegroeid.
- API zonder rate limiting: een AI-gegenereerde integratie-API werkt functioneel prima, tot een geautomatiseerd script de endpoint duizenden keren per minuut aanroept en zowel prestaties als databeveiliging in gevaar brengt.
In elk scenario is de oplossing niet “AI-tools stoppen met gebruiken”, maar de applicatie alsnog laten voldoen aan de beveiligingseisen die bij de nieuwe context horen. De gemeenschappelijke deler in alle drie de voorbeelden is dat de oorspronkelijke context waarin de applicatie is gebouwd, niet meer overeenkomt met de context waarin hij nu draait. Een risicoanalyse die meegroeit met het daadwerkelijke gebruik, in plaats van eenmalig bij de start, voorkomt dat dit soort verschuivingen onopgemerkt blijven tot er iets misgaat.
Voor MKB-bedrijven die snel willen blijven bouwen met AI-tools, maar niet willen inleveren op beveiliging, is de praktische route meestal dezelfde: benoem vooraf welke applicaties en features een verhoogd risico dragen (klantdata, betalingen, gezondheidsgegevens, externe toegang), en koppel daar automatisch een securityreview aan, in plaats van te vertrouwen op het toeval dat iemand het report.
Vraag een gratis adviesgesprek aan over een code review of security-assessment van je AI-gegenereerde applicatie, of bekijk onze AI Code Security-dienst voor een volledig overzicht van onze aanpak.
Veelgestelde vragen
- Wat is vibe coding precies?
- Vibe coding is een ontwikkelstijl waarbij een ontwikkelaar grotendeels op gevoel en via prompts samenwerkt met een AI-coding-assistent, zonder elke gegenereerde regel code diepgaand te doorgronden. Het versnelt ontwikkeling, maar verschuift het risico naar onopgemerkte architecturale en beveiligingsfouten.
- Is AI-gegenereerde code onveilig?
- Niet per definitie, maar AI mist vaak context zoals bestaande autorisatielogica en tenant-isolatie. Zonder gerichte review komen kwetsbaarheden als ontbrekende autorisatiecontroles en zwakke input-validatie geregeld door in productie.
- Is hosting bij een veilige provider voldoende voor een veilige applicatie?
- Nee. Veilige hosting beschermt de infrastructuur, niet de applicatielogica. Een kwetsbaarheid in autorisatie of een verouderde dependency blijft misbruikbaar, ongeacht hoe goed de server daaronder beveiligd is.
- Wat is de OWASP Top 10?
- Een periodiek bijgewerkte lijst van OWASP met de tien meest kritieke risicocategorieen voor webapplicaties, zoals gebroken toegangscontrole en kwetsbare componenten. De meest gebruikte referentie wereldwijd voor applicatiebeveiliging.
- Hoe helpt MonkeySoft bij het beveiligen van AI-gegenereerde code?
- MonkeySoft voert code reviews en threat modelling uit, controleert dependencies op kwetsbaarheden en hallucinatierisico, herstelt pentestbevindingen, en helpt secure coding-standaarden en DevSecOps in te richten, conform de principes van OWASP, ISO 27001 en NEN 7510.
- Wat is pentest remediation?
- Het daadwerkelijk oplossen van kwetsbaarheden uit een penetratietest, inclusief verificatie dat de fix het probleem wegneemt zonder nieuwe risico’s te introduceren. Zonder remediation levert een pentestrapport geen beveiligingsverbetering op.
Conclusie
Vibe coding is geen tijdelijke hype, het is de nieuwe manier waarop een groot deel van de software wordt gebouwd. Dat is geen probleem op zich. Het probleem ontstaat wanneer snelheid niet wordt opgevolgd door review, threat modelling, dependency-scanning en een structurele secure development lifecycle.
Hosting alleen beschermt niet tegen een kwetsbaarheid in de applicatielogica. OWASP, Secure SDLC, DevSecOps en de principes van ISO 27001 en NEN 7510 bieden samen het kader om AI-versnelde ontwikkeling en beveiliging te combineren, in plaats van het een voor het ander te laten inruilen.
Drie stappen om mee te beginnen:
- Laat een AI-gegenereerde applicatie die richting productie of klanten gaat, eerst reviewen op autorisatie, input-validatie en dependencies
- Zet geautomatiseerde security-checks in de CI/CD-pijplijn, zodat dit niet telkens handmatig moet gebeuren
- Heb je al een pentestrapport liggen? Zorg dat de bevindingen daadwerkelijk en verifieerbaar worden opgelost
MonkeySoft helpt organisaties AI-gegenereerde en vibe-coded applicaties productieklaar en veilig te maken. Neem contact op met MonkeySoft voor een vrijblijvend gesprek over jouw situatie.
Bronnen: OWASP Top 10 | NCSC.nl