Korte versie
AI vindt sinds 2025 echte lekken in software die al jaren meegaat, zoals een kritiek lek in SQLite en een van de PHP-lekken van oktober 2026. Volgens Google verdubbelde het aantal gemelde kwetsbaarheden per maand in 2026, en ook het aantal misbruikte lekken nam fors toe. Aanvallers gebruiken dezelfde AI. Een AI-scan alleen is niet genoeg: die levert veel meldingen die niet kloppen of niet ertoe doen. Bij onze lokale security audit draait de analyse op onze eigen hardware, controleert een mens elke bevinding en krijg je een rapport met ernst en concrete oplossingen. We auditen alleen met schriftelijke toestemming van de eigenaar.
Op 21 oktober 2026 gingen Smartschool, Knack en DigiD uit voorzorg offline door twee lekken in PHP. Een van die lekken was gevonden met een AI-model. Dat is goed nieuws voor wie software beschermt. Het is ook slecht nieuws, want aanvallers hebben dezelfde tools. Wie nu een online webapp heeft, met een login, een klantenzone of een koppeling met andere systemen, doet er goed aan die te laten auditen vóór iemand anders dat doet.
Een AI-scan alleen lost dat niet op. In dit artikel lees je wat een AI security audit is, waarom de verhoudingen zo snel veranderen, waarom je een expert nodig hebt die de resultaten controleert, en hoe onze lokale audit werkt.
Wat is een AI security audit?
Een security audit is een grondige controle van een website of webapplicatie op zwakke plekken in de beveiliging. Je kijkt naar de code, de instellingen, de gebruikte bibliotheken en de manier waarop gebruikers inloggen en gegevens opvragen. Bij een AI security audit doorzoekt een AI-model die onderdelen. Het model leest veel meer code dan een mens in dezelfde tijd kan lezen, en het volgt paden door de code die je bij een snelle controle mist.
De AI vindt mogelijke problemen. Een expert beslist wat ermee gebeurt. De expert controleert of een melding klopt, of ze in jouw webapp echt te misbruiken is en hoe ernstig het risico is. Pas dan komt een bevinding in het rapport. Die tweede stap maakt het verschil tussen een lange lijst waarschuwingen en een lijst die je kunt afwerken.
Waar het in de praktijk vaak misloopt, staat in de OWASP Top 10:2025, de bekendste lijst van risico’s voor webapplicaties. Bovenaan staat Broken Access Control: een gebruiker ziet of wijzigt gegevens waar hij niet aan mag komen. Daarna volgen verkeerde instellingen, problemen in de toeleveringsketen van software (bibliotheken en pakketten van derden), zwakke versleuteling en injectie. Een goede audit loopt die risico’s na voor jouw webapp.
Waarom AI de verhoudingen verandert
Lange tijd was het zoeken naar lekken handwerk. Onderzoekers lazen code regel per regel en schreven eigen tools. Daniel Stenberg, de oprichter van het opensourceproject curl, vertelde in juni 2026 aan Cybernews dat ze weken nodig hadden om iets te vinden. Dat is in korte tijd veranderd.
AI vindt lekken die mensen misten
In juli 2025 meldde Google dat zijn AI-agent Big Sleep een kritiek lek in de databasesoftware SQLite had gevonden (CVE-2025-6965). Volgens Google was dat lek alleen bekend bij aanvallers en stond het op het punt misbruikt te worden. Google kon het misbruik voorkomen.
Dichter bij huis werden ook de twee kritieke PHP-lekken van 21 oktober 2026 deels met AI gevonden. Volgens OpenAI vond het beveiligingsbedrijf Calif een van die lekken met een AI-model, terwijl Wiz beide lekken los daarvan ontdekte. Wat dat lek voor WordPress-sites betekende, lees je in mijn artikel over het PHP-lek en WordPress.
Het gaat ook niet om een paar losse gevallen. De Google Threat Intelligence Group telde in januari 2026 5.045 gemelde kwetsbaarheden en in augustus 2026 10.740: een verdubbeling. Wat AI vindt, is bovendien vaker ernstig. De helft van de kwetsbaarheden die met AI gevonden werden, laat een aanvaller op afstand code uitvoeren. Bij gemelde kwetsbaarheden in het algemeen is dat 26%.
Aanvallers gebruiken dezelfde tools
OpenAI schrijft het zelf in dezelfde bekendmaking over PHP: AI kan lekken met impact op het hele internet vinden, maar dezelfde mogelijkheden kunnen ook aanvallers helpen om snel aanvalstools te bouwen. Volgens Google nam ook het misbruik toe: van gemiddeld 10,5 misbruikte kwetsbaarheden per maand in 2025 naar 18 per maand in de eerste acht maanden van 2026.
IBM X-Force bekeek 223 publiek gemelde kwetsbaarheden die met AI gevonden werden. 55,2% kreeg de ernst hoog of kritiek, en 91% was op afstand bereikbaar. IBM trekt er een duidelijke les uit: zoeken wordt makkelijker, de moeilijkheid verschuift naar kiezen wat eerst moet en het op tijd oplossen.
Voor de eigenaar van een webapp betekent dat iets eenvoudigs. Met AI gaat het zoeken naar lekken veel sneller, voor verdedigers én voor aanvallers. De vraag is alleen wie het lek in jouw webapp het eerst vindt.
Waarom een AI-scan zonder expert niet genoeg is
Je kunt vandaag zelf een AI-model vragen om je code op lekken te controleren. Dat levert snel een lange lijst op. Het probleem zit in wat er op die lijst staat.
Curl, dat miljarden installaties telt, was een van de eersten die de gevolgen zag. Stenberg schreef in januari 2026 dat het aandeel echte lekken in de binnengekomen meldingen in 2025 zakte van meer dan 15% naar minder dan 5%. Een groot deel van de rest waren AI-rapporten die niet klopten: verzonnen functies, problemen die niet bestonden, gewone fouten die als kritiek lek werden voorgesteld.
Starting 2025, the confirmed-rate plummeted to below 5%. Not even one in twenty was real.
De AI-modellen zijn sindsdien beter geworden. In hetzelfde gesprek met Cybernews vertelde Stenberg dat de meldingen nu vaker technisch kloppen. Toch blijft het zware werk bij de mens. Elke melding moet iemand lezen, begrijpen en controleren, en de ernst inschatten. Voorstellen voor een oplossing zijn volgens Stenberg zelden helemaal juist: er moet nog altijd een mens aan te pas komen om de fout echt te herstellen.
Wat de expert toevoegt
Precies daar zit de waarde van een expert in je audit. Drie dingen kan een AI-scan niet alleen:
- Context begrijpen. Een melding over een open beheerpagina is kritiek op een live webshop en onschuldig op een testserver zonder echte gegevens. Wie de webapp kent, maakt dat onderscheid.
- Prioriteiten leggen. Tien meldingen van gemiddelde ernst zijn minder dringend dan één lek waarmee een klant de facturen van een andere klant ziet. Je wilt weten wat deze week moet en wat kan wachten.
- Een veilige oplossing kiezen. Een snelle fix die een lek dicht en ondertussen de login breekt, helpt niemand. Een expert test de oplossing in de context van de hele webapp.
Een AI-scan zonder controle levert dus vooral werk op: iemand moet elke melding nalopen. Bij een audit gebeurt dat nalopen vóór het rapport, niet erna.
Security audit, AI-scan of penetratietest?
De termen lopen vaak door elkaar. Deze tabel zet de drie naast elkaar.
| Onderdeel | AI-scan zonder controle | Security audit met AI en expert | Penetratietest |
|---|---|---|---|
| Wat het doet | Een model doorzoekt code of een site en geeft meldingen | AI zoekt, een expert controleert en ordent elke bevinding | Een tester valt de webapp aan zoals een aanvaller |
| Kijkt naar | Wat je aanlevert | Code, configuratie, bibliotheken en instellingen | De draaiende webapp, van buitenaf |
| Valse meldingen | Veel, niet gefilterd | Uitgefilterd vóór het rapport | Weinig, alles is getest |
| Ernst en prioriteit | Vaak overdreven of ontbrekend | Per bevinding, voor jouw situatie | Per bewezen aanvalspad |
| Waar je code naartoe gaat | Vaak naar een AI-dienst in de cloud | Bij ons: blijft lokaal | Niet nodig, de test gebeurt van buitenaf |
| Wanneer zinvol | Als eerste verkenning door een ontwikkelaar | Voor lancering, na grote wijzigingen, periodiek | Als je moet bewijzen wat er misbruikt kan worden |
Een penetratietest is geen vervanging van een audit, en omgekeerd. Een audit vindt zwakke plekken in de code die een aanvaller nog niet heeft gevonden. Een penetratietest bewijst wat een aanvaller er vandaag mee kan doen. Voor de meeste kleine en middelgrote bedrijven is een audit de logische eerste stap.
Hoe onze lokale security audit werkt
We doen de audit lokaal, op onze eigen hardware. Dat is een bewuste keuze. Je code en je gegevens gaan niet naar een AI-dienst in de cloud, en ze verlaten ons kantoor niet. Zo hoef je niet te kiezen tussen een grondige controle en de vertrouwelijkheid van je software.
- Toestemming en afsprakenWe starten pas na schriftelijke toestemming van de eigenaar van de webapp. Samen leggen we vast wat we controleren, welke omgeving en tot waar we gaan.
- Lokale analyse met AIEen AI-model op onze eigen hardware doorzoekt de code, de configuratie en de gebruikte bibliotheken op mogelijke lekken. Er gaat niets naar een externe AI-dienst.
- Elke bevinding gecontroleerdEen expert loopt elke melding na: klopt ze, is ze in jouw webapp te misbruiken en hoe ernstig is ze. Meldingen die niet kloppen, vallen weg.
- Rapport met ernst en oplossingJe krijgt alleen bevestigde bevindingen, met de ernst, de plek in de code en een concrete aanbeveling om het op te lossen.
- Oplossen, als je dat wiltJe kunt de oplossingen zelf of door je eigen ontwikkelaar laten uitvoeren, of ze aan ons toevertrouwen.
De AI doet het zoekwerk dat anders dagen zou duren. De expert doet wat AI niet goed kan: beoordelen, kiezen en uitleggen. Je krijgt dus geen ruwe AI-output, maar een rapport waar je mee aan de slag kunt. Garanties dat een webapp na een audit “100% veilig” is, geven we niet. Niemand kan dat eerlijk beloven. Wat je wel krijgt, is een duidelijk beeld van de risico’s die we vonden en hoe je ze aanpakt.
Alleen met toestemming van de eigenaar
Een security audit is geen hack, en dat verschil zit in de toestemming. In Nederland is binnendringen in een systeem zonder toestemming computervredebreuk. Ook in België is het strafbaar. De Belgische wetgever keurde in februari 2023 wel een wettelijk kader voor ethische hackers goed, maar dat beschermt alleen wie zich strikt aan de procedure van het Centrum voor Cybersecurity België houdt.
Wij werken daarom alleen voor de eigenaar van de webapp, of voor wie schriftelijk namens die eigenaar mag beslissen. Bouwde een bureau je webapp en draait ze bij een andere partij, dan regelen we vooraf wie toestemming geeft voor welk deel. Een audit op een app waarvan je niet de eigenaar bent, doen we niet.
Wanneer laat je je webapp auditen?
Een audit is geen jaarlijkse formaliteit. Er zijn momenten waarop hij echt het verschil maakt:
- Vóór de lancering van een nieuwe webapp, zeker als er een login, betalingen of persoonsgegevens in zitten.
- Na een grote wijziging: een nieuwe koppeling met een ander systeem via een API, een nieuwe klantenzone of een andere manier van inloggen.
- Als je webapp snel gebouwd is met AI-tools. Een app uit Lovable of een andere AI-bouwer werkt vaak meteen, maar of de toegangsregels kloppen, zie je niet aan de buitenkant. Wat er nog meer ontbreekt bij zo’n site, lees je in mijn artikel over Lovable SEO.
- Als je webapp of je website draait op oudere software of plugins die niet meer bijgewerkt worden. Een audit vervangt geen goed onderhoud, maar toont wel waar het risico het grootst is.
- Na een groot lek in software die je gebruikt, zoals het PHP-lek van oktober 2026, als je wilt weten of er meer aan de hand is dan die ene update.
Twijfel je of je webapp in aanmerking komt, of wil je weten wat een audit voor jouw situatie zou inhouden? Op onze pagina over de security audit van je website of webapp lees je wat we controleren en wat je krijgt. Of neem meteen contact op: we bekijken samen welke webapp het is, wie de eigenaar is en wat we zouden controleren.
