AI vindt kritieke kwetsbaarheden sneller dan Teams ze kunnen oplossen

Afgelopen 90 dagen hebben we autonome pentests uitgevoerd op 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 geen beveiligingstests doen. Het is dat aanvallers nu op machineniveau opereren, terwijl testen en remediëring nog steeds volgens menselijke tijdlijnen verlopen.
Terwijl AI het ontdekken van kwetsbaarheden versnelt, wordt het venster tussen het introduceren van een bug en het misbruiken ervan steeds kleiner. Als testen en fixes niet even snel meebewegen, wordt die kloof het aanvalsoppervlak.

Wat we in de praktijk zien

Over 28 bedrijven hebben onze agents het volgende geïdentificeerd:

• ~2000 totaal aantal kwetsbaarheden

• 44,6% kritisch of hoge ernst (829 bevindingen)

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

• 65,1% van de scans vond ten minste één kritiek probleem

• Piek: 88 kwetsbaarheden in één enkele scan

Dit zijn geen theoretische risico’s. Elke bevinding wordt 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 gaat niet om 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 precies zo werkt als geprogrammeerd, maar dat het ontwerp zelf onveilig is.
Dit zijn geen configuratiefouten of verouderde bibliotheken. Het zijn bugs in hoe de applicatie echt werkt, hoe data stroomt, hoe machtigingen worden afgedwongen en hoe systemen elkaar vertrouwen.

Dit ziet er in de praktijk zo uit:

• IDOR (Insecure Direct Object Reference) — 177 bevindingen
  Aanvallers kunnen gegevens van andere gebruikers openen of aanpassen door simpelweg identifiers te veranderen (bijv. user IDs, file IDs). 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, cloud-credentials of infrastructuur blootleggen die nooit publiek toegankelijk had mogen zijn.

• Ontbrekende authenticatie — 105 bevindingen
  Gevoelige endpoints of acties zijn toegankelijk zonder in te loggen. Dat betekent dat iedereen op internet kritieke functionaliteit kan aanroepen of beschermde data kan openen.

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

Waarom AI meer vindt

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

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

• Ze testen edge cases

• Ze koppelen meerdere stappen aan elkaar

• Ze itereren snel over duizenden mogelijkheden

In plaats van bekende problemen te controleren, onderzoeken ze actief hoe een applicatie zich gedraagt en zoeken ze naar manieren om die te breken. Ze slapen nooit. Hun werkdag eindigt nooit. Ze hebben de kennisbank van de wereld gememoriseerd.
Deze verschuiving drijft de resultaten die we zien: consistente ontdekking van kritieke problemen bij het merendeel 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 open probeert te krijgen. Als je weet hoe het slot van binnen werkt, is het veel makkelijker om het te kraken.
Wanneer AI-systemen toegang hebben tot broncode, kunnen ze elke codepath rechtstreeks analyseren in plaats van gedrag van buitenaf af te leiden.
In gecontroleerde benchmarktests met de publiek beschikbare XBow validation suite, verhoogde toegang tot broncode de detectie van kwetsbaarheden met ongeveer 20% vergeleken met black-box testing.
Dat verschil zien we ook in reële scenario’s.
Met volledig zicht kunnen AI-agents:

• Datastromen end-to-end volgen

• Gebroken aannames in business logic identificeren

• Edge cases veel efficiënter verkennen

Dit maakt logische fouten aanzienlijk makkelijker te vinden en te misbruiken.
Naarmate meer applicaties open worden gebouwd en AI-systemen verbeteren, blijft de snelheid van het ontdekken van kwetsbaarheden toenemen.
Dat gezegd hebbende: closed source betekent niet automatisch dat je veilig bent.
Security through obscurity is nooit een echte verdediging geweest. Een vastberaden aanvaller met genoeg rekenkracht en genoeg tokens om te verbranden, kan nog steeds paden enumereren, fuzzing toepassen en uiteindelijk misbruikbare routes ontdekken, zelfs zonder directe toegang tot de code.
De les is dus niet dat je moet kiezen tussen open of closed source. Het gaat erom hoe je systemen test en beveiligt aan te passen.
Ongeacht de architectuur missen traditionele point-in-time assessments de plank. Codebases evolueren op machineniveau, en het aanvalsoppervlak ook.

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 codepaths verkennen

• Exploits automatisch aan elkaar koppelen

Dat 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 aan deze verschuiving aangepast.
Beveiligingstests worden nog steeds behandeld als een periodiek moment:

• Eén keer per jaar

• Misschien één keer per kwartaal

En remediëring gaat vaak nog trager, doordat er gewacht wordt op prioritering, engineeringcapaciteit en releasecycli. Zelfs de tijd die het kost om code naar productie te pushen, creëert gaten die snellere systemen kunnen misbruiken.
Dat zorgt voor een steeds groter wordende kloof:

• Kwetsbaarheden worden ontdekt op machineniveau

• Fixes worden uitgerold volgens menselijke tijdlijnen

Die kloof is het echte aanvalsoppervlak.
Als een kritieke kwetsbaarheid dagen of weken blijft bestaan voordat die is opgelost, maakt het niet uit hoe die is gevonden. Ze is misbruikbaar.
Het traditionele model van “testen, rapporteren, later oplossen” houdt simpelweg geen stand wanneer zowel aanvallers als ontdeksystemen continu draaien.
Dat model is al achterhaald.

Wat echt werkt

De verschuiving draait niet om tools. Het draait om de aanpak.
Beveiliging moet verschuiven van:

• Point-in-time testing → continu testen

In de praktijk is dit niet alleen een toolingwijziging.
Het vereist een andere manier van denken over hoe beveiliging in de ontwikkelcyclus past.
Continu testen combineert meestal:

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

• Beveiliging die direct in CI/CD-pipelines is geïntegreerd

• Ontwikkelaars die issues bezitten en oplossen als onderdeel van normale workflows

• Periodieke menselijke tests voor diepere, complexere aanvalspaden

Dit is niet iets wat de meeste teams alleen met meer mensen 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 continu testen aan systemen die op machineniveau 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 meebewegen.
Ongeacht de architectuur missen traditionele point-in-time assessments de plank. Codebases evolueren op machineniveau, en het aanvalsoppervlak ook.
Open source-systemen moeten de extra blootstelling erkennen en dragen die komt met zichtbaarheid van de code. Closed source-systemen kunnen ondertussen niet vertrouwen op obscuriteit en zullen hun beveiligingshouding ook moeten verbeteren.
De kloof tussen hoe snel we software bouwen en hoe vaak we die testen wordt groter.
AI versnelt beide kanten, maar op dit moment hebben aanvallers het voordeel.
Als je beveiliging niet actief opschaalt om het dreigingsniveau bij te houden, zullen je systemen falen.

De hierboven genoemde benchmark (XBow) is publiek beschikbaar op GitHub. Onze resultaten combineren gecontroleerde benchmarktests met praktijkdata uit productiesystemen op ons platform.