Het gesprek over AI in security is de afgelopen jaren radicaal omgeslagen. Waar eerst de vraag centraal stond of een AI-model net zo goed kwetsbaarheden kon vinden als een securityspecialist, weten we inmiddels dat AI op grote schaal potentiële kwetsbaarheden kan signaleren. Daarmee wordt het vinden van kwetsbaarheden toegankelijk voor iedereen: van een developer tot een potentiële hacker, zo waarschuwt ook het NCSC.
De echte vraag gaat niet meer over het vinden van kwetsbaarheden. Het gaat over wat je met al die bevindingen doet. Ook het prioriteren, valideren en oplossen van potentiële kwetsbaarheden kost tijd. Hoe langer de lijst met potentiële bevindingen (en hoe meer false positives), hoe intensiever dit proces wordt.
Daarnaast gaat security niet alleen om het vinden en oplossen van kwetsbaarheden. De echte winst ontstaat wanneer je de onderliggende oorzaak begrijpt en die kennis terugbrengt in het ontwikkelproces. Zo los je niet alleen één probleem op, maar voorkom je dat dezelfde fout ergens anders terugkomt.
Die verschuiving van "vinden" naar "beoordelen" wordt door bekende en toonaangevende organisaties onderschreven. Cloudflare trekt dezelfde conclusies en beschrijft precies waarom. Hun belangrijkste inzicht: AI vindt altijd wel iets.
"Vraag een model om bugs te vinden en het zal ze vinden, of de code ze nu wel of niet bevat. Bevindingen zijn omgeven met disclaimers als 'mogelijk', 'potentieel' en 'het zou in theorie kunnen'. Zulke onzekere bevindingen komen veel vaker voor dan de goed onderbouwde."
Cloudflare noemt dat "een goede bias voor een verkennend hulpmiddel, maar funest voor een triageproces: elke speculatieve bevinding kost menselijke aandacht en tokens om te ontkrachten, en bij duizenden bevindingen stapelen die kosten zich op". De kern van hun boodschap: dat probleem los je niet op met een beter model, maar met gespecialiseerde tooling. Zo ontwikkelde Cloudflare een systeem met verschillende validatiestappen, waar een bevinding doorheen moet komen voordat er een mens naar gaat kijken. Zonder die stappen heb je vooral een snellere manier om veel ruis te produceren.
Een belangrijk inzicht is dat een aanvaller hetzelfde probleem heeft. Die kan dezelfde modellen draaien, maar staat voor dezelfde berg speculatieve bevindingen. Wie het beste kan beoordelen wat er in jóuw omgeving écht gevaarlijk is, heeft daarmee een reële voorsprong.
Een kwetsbaarheid bestaat binnen de context van een applicatie en een organisatie. Of iets exploiteerbaar is, hangt af van jouw omgeving: welke versies je draait, wat er publiek bereikbaar is, wat er achter je firewall staat en meer. Daarnaast is er een impact, die afhangt van jouw specifieke organisatie.
Een AI-tool ziet code, maar kent deze context niet. Het weet niet dat een storing in een betalingssysteem direct omzet kost, dat een ogenschijnlijk onschuldige exportfunctie de volledige klantenadministratie bevat, of dat een verouderd beheerpaneel alleen intern bereikbaar is. Juist die context bepaalt welke bevinding vandaag moet worden opgelost en welke kan wachten. Dat oordeel vereist toegang tot jouw systemen, kennis van jouw risicoprofiel en inzicht in wat er voor jouw bedrijf belangrijk is.
AI helpt ons om grote hoeveelheden code sneller te doorgronden en potentieel interessante locaties te ontdekken. Hebben we een vermoeden van een kwetsbaarheid, dan gebruiken we AI bijvoorbeeld om sneller een proof-of-concept te schrijven.
De tooling waar AI toegang krijgt is hierbij cruciaal. Voor de HTTP Terminator vertaalde PortSwigger-onderzoeker James Kettle bijvoorbeeld vier jaar aan specialistische ervaring naar een methode die het systeem op grote schaal kon toepassen. AI genereerde aanvalsvectoren op basis van deze expertise, die vervolgens automatisch getest en gevalideerd konden worden. Zo vergrootte AI het bereik en de snelheid van een door de onderzoeker ontwikkelde methodiek.
Zonder gespecialiseerde tooling, een doordachte onderzoeksmethode en praktische validatie ontstaat al snel veel ruis. Daarom ontwikkelen wij zelf ook gespecialiseerde tools voor belangrijke onderdelen van de applicatiebeveiliging. De volgende twee praktijkvoorbeelden laten zien hoe AI tijdens onze onderzoeken concrete waarde toevoegde.
Tijdens onze eerste experimenten lieten we AI zelfstandig broncode analyseren. Van de honderden potentiële bevindingen, waaronder veel false positives, viel er één direct op: AI had verder gezocht in een endpoint waarin we zelf al een SSRF-kwetsbaarheid hadden gevonden. Daarbij legde AI het verband tussen een niet-gevalideerde parameter en een optimalisatiepad voor beeldverwerking, waardoor een aanvaller zonder authenticatie gecontroleerde data buiten de cachemap kon schrijven.
De benodigde payload was sterk afhankelijk van ongebruikelijke applicatielogica en een specifieke eigenschap van de programmeertaal. AI hielp deze context snel te doorgronden en een passende payload te ontwikkelen. Binnen de testomgeving bevestigde we de hypothese dat het mogelijk was om naar willekeurige plekken bestanden te schrijven. Door bestanden op een strategische locatie te plaatsen, kon deze schrijfprimitive worden uitgebreid naar remote code execution.
AI versnelde het verdiepende onderzoek en de ontwikkeling van een passende payload. Daardoor konden we binnen dezelfde onderzoeksduur naast de SSRF ook remote code execution onderbouwen. Zo bereikten we meer diepgang zonder in te leveren op de breedte of kwaliteit van het onderzoek. Deze case liet ons al vroeg zien hoe AI bestaand onderzoek kan verdiepen en aanvullende impact sneller aan het licht kan brengen.
In een recenter hardwareonderzoek identificeerden we een buffer overflow in microcontrollerfirmware die mogelijk op afstand kon worden geactiveerd. Omdat onze onderzoeken een breed beeld van de beveiligingshouding geven, was dit soort diepgaande exploitontwikkeling binnen de beschikbare tijd voorheen niet altijd mogelijk.
We gaven AI de gerichte taak om het aanvalspad van externe invoer naar de kwetsbare geheugenoperatie te reconstrueren en de voorwaarden voor exploitatie vast te stellen. Onder toezicht van onze specialisten kreeg AI via GDB en JTAG interactieve toegang tot de firmware. De inhoudelijke sturing door een expert die de waargenomen interacties kon duiden, was hierbij essentieel. Zonder deze sturing had AI de neiging om bij onverwachte resultaten richtingloos nieuwe hypotheses te testen. Door na iedere test de heap, registers en crashinformatie te analyseren, konden we hypotheses gericht aanscherpen en aangepaste payloads testen.
Deze korte iteraties brachten de validatie verder dan een reproduceerbare crash. We bewezen dat aanvaller-gecontroleerde bytes kritieke heapmetadata konden overschrijven en uiteindelijk zonder authenticatie tot uitvoering van willekeurige code konden leiden. AI versnelde daarmee het technische vervolgonderzoek, terwijl de specialisten de onderzoeksrichting, exploitvalidatie en risicobeoordeling bepaalden.
Software wordt door mensen gemaakt en fouten maken hoort bij ontwikkelen. Niet alle beveiligingsrisico’s zijn direct zichtbaar, zeker niet wanneer verschillende onderdelen van een applicatie samenkomen. AI-tools versnellen het ontwikkelproces en produceren snel overtuigend ogende code, maar kunnen ook subtiele fouten introduceren in bijvoorbeeld invoervalidatie, autorisatie of gegevensverwerking.
Daarom kijken we verder dan afzonderlijke kwetsbaarheden. We combineren AI-ondersteund onderzoek met specialistische kennis, handmatige validatie en bedrijfscontext. In een uitgebreide rapportage schetsen we een zo volledig mogelijk beeld van de beveiligingshouding, de onderliggende patronen en het daadwerkelijke risico op incidenten, onderbouwd met gevalideerde kwetsbaarheden, heldere prioriteiten en concrete verbeteracties.
Met kennisdeling en strategisch advies helpen we voorkomen dat dezelfde fouten elders terugkeren. Zo werkt je ontwikkelteam niet alleen aan veiligere code, maar ook aan een ontwikkelproces waarin security een blijvende plek heeft.
