AI vindt kritieke kwetsbaarheden sneller dan Teams ze kunnen oplossen

In de afgelopen 90 dagen hebben we autonome pentests uitgevoerd tegen verschillende productiesystemen — en de resultaten zijn moeilijk te negeren.
Moderne applicaties zijn niet alleen kwetsbaar. Ze zijn continu kwetsbaar.
Het probleem is niet dat teams niet op beveiliging testen. Het is dat aanvallers nu op machinesnelheid opereren, terwijl testen en herstel nog steeds op menselijke tijdlijnen plaatsvinden.
Naarmate AI het ontdekken van kwetsbaarheden versnelt, wordt het venster tussen het introduceren en uitbuiten van een bug kleiner. Als testen en fixes niet even snel bewegen, wordt die kloof het aanvalsoppervlak.

Wat we in de praktijk zien

Bij 28 bedrijven identificeerden onze agents:

• ~2000 kwetsbaarheden in totaal

• 44,6% kritiek of hoog (829 bevindingen)

• Gemiddeld 21,6 kwetsbaarheden per scan (mediaan: 15)

• 65,1% van de scans bracht ten minste één kritiek probleem aan het licht

• Piek: 88 kwetsbaarheden in één scan

Dit zijn geen theoretische risico's. Elke bevinding is gevalideerd met een werkende proof-of-concept-exploit.
Bijna de helft van alle kwetsbaarheden die we vonden is ernstig, en de meeste systemen hebben minstens één kritiek probleem.
Wat nog zorgwekkender is, is het type kwetsbaarheden achter deze cijfers. Het zijn geen simpele configuratiefouten of verouderde afhankelijkheden. Het zijn diepere problemen in hoe applicaties zijn ontworpen en zich gedragen.

Dit zijn geen simpele bugs

De meest voorkomende problemen die we zien zijn logische fouten.
Een logische fout betekent dat het systeem zich precies gedraagt zoals geprogrammeerd, maar dat het ontwerp zelf onveilig is.
Dit zijn geen configuratiefouten of verouderde bibliotheken. Het zijn bugs in hoe de applicatie daadwerkelijk werkt, hoe data stroomt, hoe machtigingen worden afgedwongen en hoe systemen elkaar vertrouwen.

Zo ziet dat er in de praktijk uit:

• IDOR (Insecure Direct Object Reference) — 177 bevindingen
  Aanvallers kunnen eenvoudig toegang krijgen tot of gegevens van andere gebruikers wijzigen door simpelweg identificatiegegevens te veranderen (bijv. gebruikers-ID's, bestands-ID's). Dit kan gevoelige gegevens op grote schaal blootleggen of zelfs accountovernames mogelijk maken.

• SSRF (Server-Side Request Forgery) — 122 bevindingen
  Aanvallers kunnen de server misleiden om namens hen verzoeken te doen, vaak naar interne systemen. Dit kan interne API's, cloudreferenties of infrastructuur blootleggen die nooit publiek toegankelijk zou mogen zijn.

• Ontbrekende authenticatie — 105 bevindingen
  Gevoelige eindpunten of acties zijn toegankelijk zonder in te loggen. Dit betekent dat iedereen op internet kritieke functionaliteit kan aanroepen of beschermde gegevens kan benaderen.

Deze kwetsbaarheden zijn bijzonder gevaarlijk omdat ze misbruik maken van hoe de applicatie zich gedraagt, niet alleen van hoe deze is geconfigureerd.
Traditionele scanners hebben hier moeite mee omdat ze gedrag niet begrijpen. Ze zoeken naar handtekeningen, niet naar logica.

Waarom AI meer vindt

Tot voor kort vereiste het vinden en misbruiken van dit soort kwetsbaarheden tijd, vaardigheid en handmatig werk.
Dat is veranderd.

AI-agenten kunnen nu met applicaties omgaan zoals een menselijke aanvaller dat zou doen, maar op een compleet andere schaal en snelheid.
Ze scannen eindpunten niet alleen, ze verkennen ze.

• Ze testen randgevallen

• Ze combineren meerdere stappen

• Ze itereren snel over duizenden mogelijkheden

In plaats van te controleren op bekende problemen, onderzoeken ze actief hoe een applicatie zich gedraagt en zoeken ze naar manieren om deze te breken. Ze slapen nooit. Hun werkdag eindigt nooit. Ze kennen de wereldwijde kennisbank uit het hoofd.
Deze verschuiving drijft de resultaten die we zien: consistente ontdekking van kritieke problemen in de meerderheid van de scans.

Waarom open source het ontdekken van kwetsbaarheden kan versnellen

Open source verandert hoe kwetsbaarheden worden ontdekt.
Stel je voor dat je een slot probeert te kraken. Als je de interne werking van het slot kent, is het veel makkelijker om het te kraken.
Wanneer AI-systemen toegang hebben tot broncode, kunnen ze elk codepad rechtstreeks analyseren in plaats van gedrag van buitenaf af te leiden.
In gecontroleerde benchmarktests met behulp van de publiek beschikbare XBow-validatiesuite, verhoogde toegang tot broncode de detectie van kwetsbaarheden met ongeveer 20% vergeleken met black-boxtesten.
We zien deze kloof ook in praktijkscenario's.
Met volledig zicht kunnen AI-agenten:

• Gegevensstromen van begin tot eind traceren

• Gebroken aannames in bedrijfslogica identificeren

• Randgevallen veel efficiënter verkennen

Dit maakt logische fouten aanzienlijk eenvoudiger om te vinden en uit te buiten.
Naarmate meer applicaties open worden gebouwd en AI-systemen verbeteren, blijft de snelheid van kwetsbaarheidsontdekking toenemen.
Dat gezegd hebbende, broncode die niet open is, maakt je niet automatisch veilig.
Security through obscurity is nooit een echte verdediging geweest. Een vastberaden aanvaller met genoeg rekenkracht en genoeg tokens om te verbranden kan nog steeds enumereren, fuzzen en uiteindelijk uitbuitbare paden vinden, zelfs zonder directe toegang tot de code.
De conclusie gaat dus niet over het kiezen tussen open of closed source. Het gaat erom hoe je systemen test en beveiligt aan te passen.
Ongeacht de architectuur missen traditionele punt-in-timebeoordelingen de plank. Codebases ontwikkelen zich op machinesnelheid, en dat geldt ook voor de aanvalsoppervlakken.

Het echte probleem: hogere snelheid = lagere kosten

Een paar jaar geleden kostte het vinden en misbruiken van kwetsbaarheden tijd, vaardigheid en geduld.
Vandaag is die tijdlijn ingestort.
AI-systemen kunnen:

• Duizenden tests parallel uitvoeren

• Continu nieuwe codepaden verkennen

• Exploits automatisch aan elkaar koppelen

Dit betekent dat kwetsbaarheden sneller dan ooit worden ontdekt, vaak binnen uren of dagen nadat ze zijn geïntroduceerd.
Maar de meeste organisaties hebben zich nog niet aangepast aan deze verschuiving.
Beveiligingstests worden nog steeds behandeld als een periodieke gebeurtenis:

• Een keer per jaar

• Misschien een keer per kwartaal

En herstel verloopt vaak nog trager, wachtend op prioritering, engineeringcapaciteit en releasecycli. Zelfs de tijd die nodig is om code naar productie te pushen, creëert gaten die snellere systemen kunnen misbruiken.
Dit creëert een steeds groter wordende kloof:

• Kwetsbaarheden worden ontdekt op machinesnelheid

• Fixes worden uitgerold op menselijke tijdlijnen

Die kloof is het echte aanvalsoppervlak.
Als een kritieke kwetsbaarheid dagen of weken bestaat voordat deze is opgelost, maakt het niet uit hoe ze is gevonden. Ze is uit te buiten.
Het traditionele model van “testen, rapporteren, later oplossen” houdt simpelweg geen stand wanneer zowel aanvallers als systemen voor kwetsbaarheidsontdekking continu actief zijn.
Dat model is al achterhaald.

Wat echt werkt

De verschuiving gaat niet over tools. Het gaat over de aanpak.
Beveiliging moet verschuiven van:

• Punt-in-timetesten → continue tests

In de praktijk is dit niet alleen een verandering in tooling.
Het vereist dat opnieuw wordt nagedacht over hoe beveiliging in de ontwikkelingscyclus past.
Continue testing combineert doorgaans:

• Geautomatiseerde systemen die tests continu draaien, niet slechts één keer per jaar

• Beveiliging die rechtstreeks in CI/CD-pijplijnen is geïntegreerd

• Ontwikkelaars die eigenaarschap nemen en problemen oplossen als onderdeel van hun normale werkprocessen

• Periodieke menselijke tests voor diepere, complexere aanvalspaden

Dit is niet iets wat de meeste teams met alleen extra personeel kunnen oplossen.
Handmatig testen schaalt niet mee met de snelheid van moderne ontwikkeling of moderne aanvallers.
Daarom zien we een verschuiving naar automatisering en, in veel gevallen, het uitbesteden van continue tests aan systemen die op machinesnelheid kunnen opereren.
De urgentie hier is echt.

Wat nu?

AI versnelt het ontdekken van kwetsbaarheden al. Aanvallers wachten niet op je volgende geplande pentest.
Als je applicatie dagelijks verandert, moeten je beveiligingstests en je vermogen om problemen op te lossen dat tempo bijhouden.
Ongeacht de architectuur missen traditionele punt-in-timebeoordelingen de plank. Codebases ontwikkelen zich op machinesnelheid, en dat geldt ook voor de aanvalsoppervlakken.
Open source-systemen moeten de extra blootstelling die met zichtbaarheid van code gepaard gaat erkennen en daarvoor verantwoordelijkheid nemen. Gesloten-source-systemen kunnen ondertussen niet op obscuriteit vertrouwen en zullen hun beveiligingshouding ook moeten verbeteren.
De kloof tussen hoe snel we software bouwen en hoe vaak we het testen, wordt groter.
AI versnelt beide kanten, maar op dit moment hebben aanvallers het voordeel.
Als je beveiliging niet actief opschaalt om aan de dreiging te voldoen, zullen je systemen falen.

De hierboven genoemde benchmark (XBow) is openbaar beschikbaar op GitHub. Onze resultaten combineren gecontroleerde benchmarktests met praktijkgegevens van productiesystemen op ons platform.