Klaar voor productie? Wat een quick audit van zestien uur boven water haalde

Wat ik doe is dit: ik help jouw vibe-coded MVP security-proof, schaalbaar en production-ready te maken. Maar misschien vraag je je af: hoe gaat zoiets precies in zijn werk? Om dat te laten zien, neem ik je mee in een traject dat ik voor een klant heb afgerond.

Bijna live, maar ook veilig?

Nova Software had een applicatie ontwikkeld: KOVdesk, een SaaS-platform voor kinderopvangorganisaties met meerdere vestigingen. Nova wilde het platform eerst bij een paar pilotklanten live zetten en later dat jaar breder in de markt brengen. Een groot deel van het platform was met behulp van AI gebouwd. Goed punt was dat tijdens de ontwikkeling al aandacht was besteed aan security.

Toch ontstond er twijfel over de veiligheid. Naarmate de applicatie groter en complexer werd, merkte het team dat het steeds moeilijker werd om te overzien of alle onderdelen werkelijk veilig waren.

Ze wilden vooral zeker weten dat ze hun klanten, en de gegevens van de kinderen en ouders die daar in stonden, niet in de problemen zouden brengen. De vraag aan mij was daarom helder:

→ Kun je onderzoeken of er kwetsbaarheden in KOVdesk zitten voordat we het in gebruik nemen?

Waarom de klant voor mijn aanpak koos

Nova kwam via een aanbeveling bij mij terecht. Tijdens onze eerste gesprekken legde ik uit hoe mijn manier van testen werkt. Daarbij combineer ik mijn eigen cybersecuritykennis met gespecialiseerde AI-agents die verschillende onderdelen van een applicatie en afzonderlijke aanvalsscenario’s onderzoeken.

Die aanpak sprak hen aan. Wanneer criminelen AI inzetten om sneller, breder en dieper naar kwetsbaarheden te zoeken, is het logisch om daar aan de verdedigende kant ook AI-enabled securitytesting tegenover te zetten.

En dat betekent dat je AI gericht inzet binnen een zorgvuldig onderzoeksproces dat door een cybersecurityexpert wordt aangestuurd, gemonitord en gevalideerd. Dat werd het uitgangspunt van deze audit.

Aansluiten op het developmentproces

Dit werd geen standaard automatische securityscan en ook geen traditionele pentest. Ik sloot rechtstreeks aan op het developmentproces. Het doel was om efficiënt en snel de belangrijkste risico’s te vinden, te bewijzen en deze vervolgens samen met het team van Nova op te lossen.

Vooraf organiseerden we een gezamenlijke meeting met de betrokkenen. We maakten kennis, bespraken hoe hun developmentproces eruitzag en ik legde praktisch uit hoe ik het onderzoek zou uitvoeren. Vervolgens stemden we pragmatisch af hoe we zouden samenwerken. We bespraken welke omgevingen ik kon gebruiken, hoe ik bevindingen zou delen, wie technische context kon geven en hoe ontdekte kwetsbaarheden zo snel mogelijk in het bestaande ontwikkelproces konden worden opgenomen.

Eerst begrijpen hoe het platform echt werkt

Voordat ik gericht naar kwetsbaarheden zoek, wil ik eerst precies begrijpen hoe een applicatie technisch in elkaar zit. Daarom begon ik met een uitgebreide inventarisatie van KOVdesk. Iedere functie, ieder invoerpunt en iedere belangrijke gegevensstroom werd langsgelopen.

Met behulp van AI bracht ik in kaart welke technieken en libraries werden gebruikt, hoe gegevens binnen het platform werden verwerkt en welke databases, externe leveranciers en koppelingen waren aangesloten. Ook onderzocht ik hoe gebruikers, rollen en organisaties van elkaar werden gescheiden, op welke plekken rechten werden gecontroleerd en welke technische oplossingsvormen in verschillende onderdelen van de software waren toegepast.

In deze fase was het doel nog niet om zo snel mogelijk een lange lijst met kwetsbaarheden te produceren. Ik wilde eerst een betrouwbare technische kaart van de applicatie maken. Pas wanneer je begrijpt hoe de verschillende onderdelen met elkaar samenhangen, kun je gericht onderzoeken waar de beveiliging mogelijk doorbroken kan worden. Wanneer tijdens die verkenning al verdachte of opvallende zaken naar voren kwamen, legde ik die natuurlijk direct vast.

Van technische inventarisatie naar aanvalsscenario’s

Vervolgens beoordeelde ik de technische inventarisatie samen met verschillende AI-agents. We keken waar mogelijke hotspots zaten, welke onderdelen extra aandacht verdienden en welke aanvalsscenario’s daadwerkelijk onderzocht moesten worden.

Daarbij ging het bijvoorbeeld om de vraag of gebruiker X gegevens van gebruiker Z kon bekijken of wijzigen, of iemand vanuit de omgeving van één klant toegang kon krijgen tot een andere tenant en of invoervelden, koppelingen, sessies of databaseverzoeken op een onverwachte manier konden worden misbruikt.

Gespecialiseerde AI-agents onderzochten die scenario’s afzonderlijk. Mogelijke kwetsbaarheden werden vervolgens nog onafhankelijk getriageerd op technische onderbouwing, impact en de aannemelijkheid van misbruik. Pas daarna beoordeelde ik de relevante bevindingen zelf en bepaalde ik welke verder onderzocht en praktisch gevalideerd moesten worden.

Zo combineer ik de schaal en snelheid van AI met menselijke controle. Het doel is namelijk niet om Nova Software op te zadelen met een lange lijst theoretische risico’s, maar om vast te stellen welke kwetsbaarheden in KOVdesk werkelijk aanwezig zijn en welke als eerste aandacht nodig hebben.

Een gebruiker kon gegevens van een andere klant wijzigen

Een van de ernstigste bevindingen in deze casus zat in de manier waarop wijzigingen in de database werden gecontroleerd. Het platform gebruikte een Supabase-database en werkte met verschillende klantomgevingen. Iedere klant hoorde alleen toegang te hebben tot de gegevens binnen zijn eigen tenant.

Bij normale verzoeken werd gecontroleerd of een gebruiker was ingelogd voor de juiste client-ID. Wie niet bij die klant hoorde, werd tegengehouden. Op het eerste gezicht leek die controle dus goed te werken.

Tijdens het onderzoek bleek echter dat meerdere databaseverzoeken in één bundel konden worden verstuurd. Daarbij werd de controle op de client-ID alleen correct toegepast op het eerste verzoek. Een gebruiker kon daardoor beginnen met een toegestaan verzoek binnen zijn eigen klantomgeving en vervolgens in dezelfde bundel een tweede wijziging uitvoeren binnen de omgeving van een andere klant.

De scheiding tussen tenants kon op die manier worden doorbroken. Een gebruiker van klant A kon dus gegevens wijzigen die bij klant B hoorden. Dat is een ernstige kwetsbaarheid.

Wat er had kunnen gebeuren

Die kwetsbaarheid kon een belangrijke stap vormen in een grotere aanval. Stel dat een aanvaller via phishing toegang zou krijgen tot één geldig gebruikersaccount, bijvoorbeeld van een testomgeving of één van de organisaties die KOVdesk gebruikt. Normaal gesproken zou hij dan beperkt moeten blijven tot die ene tenant.

Door deze kwetsbaarheid kon hij echter wijzigingen uitvoeren binnen de omgeving van andere organisaties. Daarbij zouden mogelijk ook gegevens aangepast kunnen worden die invloed hebben op accounts, rechten of de manier waarop gebruikers inloggen.

Een aanvaller zou vanuit één gecompromitteerd account dus verder het platform in kunnen bewegen. Gelukkig was KOVdesk nog niet in productie en kon Nova deze kwetsbaarheid verhelpen voordat de eerste klanten ermee gingen werken.

De belangrijkste kwetsbaarheden live bewijzen

De belangrijkste bevindingen valideerde ik vervolgens zelf in de testomgeving van Nova. Ik wilde niet alleen aantonen dat er iets verdachts in de code zat, maar bewijzen dat een kwetsbaarheid in de praktijk daadwerkelijk misbruikt kon worden.

Voor de analyse en voorbereiding gebruikte ik AI als assistent, maar het daadwerkelijke bewijs voerde ik zelf uit. Zo kon het developmentteam met eigen ogen zien dat bijvoorbeeld de tenantgrens in KOVdesk daadwerkelijk doorbroken kon worden. Dat maakt het verschil tussen een theoretische waarschuwing en een bewezen kwetsbaarheid.

Samen bepalen wat als eerste moest worden opgelost

Tijdens het onderzoek werkte ik nauw samen met de betrokken ontwikkelaars van KOVdesk. Zij konden meekijken met belangrijke bevindingen en direct aanvullende context geven.

Door de technische ernst en de bedrijfsmatige context te combineren, konden we veel gerichter prioriteren. We keken niet alleen naar de theoretische impact, maar ook naar de huidige inrichting van het platform, het geplande gebruik, toekomstige releases, de bereikbaarheid van de kwetsbaarheid en de mogelijke gevolgen voor klanten en gebruikers. Daardoor lag de aandacht steeds op de kwetsbaarheden die op dat moment als eerste moesten worden opgelost.

Een quick audit van zestien uur

Deze eerste audit had een omvang van zestien uur. Binnen die tijd bracht ik KOVdesk technisch in kaart, onderzocht ik verschillende aanvalsscenario’s en werkte ik de twee ernstigste bevindingen volledig uit. Andere aanwijzingen legde ik vast als mogelijke bevindingen voor een volgende ronde.

De zestien onderzoeksuren werden verspreid over ongeveer een maand. Daarin zaten ook het kennismakingsgesprek, de technische voorbereiding en een afsluitend gesprek waarin ik mijn bevindingen toelichtte.

Het voordeel van deze opzet is dat Nova niet direct een groot en kostbaar pentesttraject hoefde af te nemen. We konden beginnen met een afgebakende audit, de grootste risico’s aanpakken en daarna gericht verdergaan.

Direct aansluiten op de backlog

Bij een traditionele pentest ontvangt een klant na afloop meestal een uitgebreid rapport. Dat kan nuttig zijn, maar het betekent vaak ook dat de bevindingen intern nog moeten worden vertaald naar tickets, technische taken en concrete oplossingen.

Bij Nova koos ik voor een andere werkwijze. Ik sloot rechtstreeks aan op het bestaande proces voor issues, bugfixes en development. De bewezen kwetsbaarheden konden daardoor direct in de backlog worden opgenomen en aan de juiste ontwikkelaars worden gekoppeld.

Er ontstond een directe samenwerking tussen het developmentteam en mij als securityspecialist. Dat maakte de aanpak sneller, praktischer en beter afgestemd op de dagelijkse manier van werken van de ontwikkelaars.

In de volgende ronde opnieuw testen

Na deze eerste audit volgt een tweede ronde van opnieuw zestien uur. Daarin controleer ik allereerst of de ernstigste kwetsbaarheden daadwerkelijk goed zijn opgelost. Een aanpassing in de code betekent namelijk nog niet automatisch dat het probleem volledig verdwenen is.

Een oplossing kan de oorspronkelijke aanval blokkeren, maar tegelijkertijd een alternatieve route openlaten of een nieuw probleem veroorzaken. Daarom test ik de fixes opnieuw in de praktijk. Daarnaast gebruik ik de tweede ronde om een aantal nieuwe kwetsbaarheden verder te onderzoeken en aan te reiken. Het developmentteam van KOVdesk kan die vervolgens opnieuw verwerken en oplossen.

Zo ontstaat een cyclisch proces van onderzoeken, bewijzen, oplossen, opnieuw testen en verder verdiepen.

Security als doorlopend onderdeel van softwareontwikkeling

Deze manier van werken bied ik ook in abonnementsvorm aan. In plaats van één grote pentest op een vast moment, werken we dan in overzichtelijke rondes aan het steeds veiliger maken van de applicatie. Dat sluit veel beter aan op de werkwijze van developers.

Software is namelijk nooit echt af. Er komen nieuwe features bij, bestaande functies veranderen, libraries worden bijgewerkt en koppelingen worden aangepast. Een pentest is bovendien altijd beperkt in tijd, terwijl een criminele hacker die beperking niet heeft. Hacken kan zeer lucratief zijn, waardoor aanvallers bereid zijn veel tijd, rekenkracht en middelen in één interessant doelwit te investeren.

Met één eenmalige test kun je daarom nooit garanderen dat iedere kwetsbaarheid wordt gevonden. Door security regelmatig te laten terugkeren in het ontwikkelproces, kunnen we steeds opnieuw naar gewijzigde en risicovolle onderdelen kijken. Tegelijkertijd groeit mijn kennis van de applicatie. Ik hoef bij iedere ronde niet opnieuw vanaf nul te beginnen, omdat ik de architectuur, eerdere bevindingen, gegevensstromen en technische hotspots al ken.

Daardoor kan ik nieuwe wijzigingen sneller beoordelen en steeds gerichter onderzoeken.

Waarom een automatische scan niet genoeg was geweest

In deze casus had een automatische scan deze kwetsbaarheid waarschijnlijk niet zomaar aan het licht gebracht. De beveiligingscontrole werkte bij normale, afzonderlijke verzoeken namelijk zoals verwacht. Pas door verschillende handelingen te combineren en meerdere databaseverzoeken binnen één scenario te onderzoeken, werd zichtbaar dat de tenantcontrole kon worden omzeild.

Daarvoor was niet alleen tooling nodig, maar ook begrip van de architectuur, creatief denken over mogelijke aanvalsroutes en handmatige validatie.

Ook een traditionele pentest blijft per definitie beperkt door de beschikbare tijd en scope. Hoe breder en complexer een applicatie wordt, hoe groter de kans dat bepaalde aanvalsroutes tijdens één afgebakend onderzoek niet volledig worden uitgewerkt. Daarom geloof ik in een aanpak waarbij AI-enabled testen en menselijke cybersecuritykennis worden gecombineerd en regelmatig terugkeren binnen het ontwikkelproces.

De belangrijkste les voor andere SaaS-bedrijven

De belangrijkste les uit deze case is dat veel kwetsbaarheden vrijwel onzichtbaar blijven. Je kunt tijdens het ontwikkelen veel aandacht besteden aan security, automatische scans uitvoeren en AI vragen om mee te kijken naar je code of om te beoordelen of een bepaalde functie veilig is.

Maar je haalt dit soort kwetsbaarheden niet met één prompt uit een applicatie. Daarvoor moet je begrijpen hoe de volledige architectuur werkt, hoe controles op verschillende plekken met elkaar samenhangen en welke onverwachte combinaties een aanvaller zou kunnen gebruiken.

Dat vraagt om diepgaande cybersecuritykennis én om AI-enabled testen die door een expert worden aangestuurd.

Het resultaat: veiliger naar productie

Voor Nova Software betekende deze eerste audit dat een ernstige cross-tenant kwetsbaarheid werd ontdekt voordat KOVdesk in productie ging. Het developmentteam kon het probleem daardoor oplossen voordat de eerste klanten met het platform gingen werken.

Tegelijkertijd ontstond een praktische manier van samenwerken waarin security rechtstreeks aansluit op de developmentcyclus van KOVdesk. In volgende rondes worden oplossingen opnieuw getest en nieuwe risico’s onderzocht.

En dat is uiteindelijk waar goede securitytesting volgens mij om draait: niet één keer vertellen waar het mis kan gaan, maar samen zorgen dat de software bij iedere stap aantoonbaar veiliger wordt.

Om de klant te beschermen zijn namen en herkenbare details in deze casus aangepast.