Ruim de helft van de AI-patches dicht je lek niet: zo controleer je het zelf

Van elke vier beveiligingslekken die je door ChatGPT of Claude laat dichten, gaat er maar één echt dicht. Dat blijkt uit 6.080 patches die het securityteam van 1Password door twee topmodellen liet schrijven. Het vervelende zit niet in de patches die zichtbaar mislukken, maar in de patches die er perfect uitzien: nette diff, keurige commit-boodschap, en toch blijft het gat open. Precies deze week, nu de Nederlandse Cyberbeveiligingswet in werking is getreden, wordt dat meer dan een codeprobleem.

Wat testte Off-by-1 Labs precies?

Onderzoeker Keith Hoodlet liet twee cyber-gecertificeerde modellen 6.080 patches schrijven voor zes recent bekendgemaakte kwetsbaarheden in open source-software, en beoordeelde daarna elke patch afzonderlijk. Off-by-1 Labs is de securityonderzoeksgroep van wachtwoordmanager 1Password. De opzet was bewust breed: 540 patches per kwetsbaarheid per model, verdeeld over drie verschillende omgevingsconfiguraties en negen promptsjablonen. Zo kon niemand achteraf zeggen dat het aan één ongelukkige prompt lag.

De geteste modellen waren ChatGPT-5.5 met OpenAI's Trusted Access for Cyber-regime en Claude Opus 4.8 onder Anthropics Cyber Verification Program. Dus niet twee willekeurige chatbots, maar juist de configuraties die de labs zelf geschikt vinden voor securitywerk. Vierhonderd patches werden onderweg gemarkeerd en uit de rapportage gehaald.

Even voor de beeldvorming, want deze rekensom maakt het tastbaar: een patch kostte gemiddeld 2,11 dollar bij ChatGPT-5.5 en 2,81 dollar bij Opus 4.8. Eén kwetsbaarheid 540 keer laten patchen door Opus komt daarmee op ruim 1.400 euro aan tokens. Voor dat bedrag krijg je, gemiddeld genomen, 140 patches waar je iets aan hebt.

Waarom ziet een kapotte patch er zo overtuigend uit?

Omdat het model optimaliseert op iets dat lijkt op een oplossing, niet op iets dat de oplossing is. De onderzoekers noemden dat verschijnsel FLAWED: Fix-Like Artifacts With Embedded Defects, ofwel artefacten die eruitzien als een fix maar een defect in zich dragen. Dit is alsof een loodgieter de druipende leiding strak inpakt met tape. De druppel op je vloer is weg, dus het probleem lijkt opgelost, terwijl het water nu achter de muur wegloopt.

Nog vervelender is wat er in de geslaagde categorie zit. Meer dan een derde van de patches die als succes werden beoordeeld, bleek fragiel: ze blokkeren precies het aanvalspad uit de CVE-melding en niets daarbuiten. Verandert de aanvaller één parameter, dan staat het lek weer open.

Het scherpste voorbeeld komt uit de test met de webserver freenginx. Daar deed ChatGPT 270 pogingen. Van die 270 werden er 114 als geslaagd beoordeeld, en alle 114 introduceerden een nieuw probleem. Geen enkele uitzondering.

“Modellen die vandaag uitblinken in het vinden van een breed scala aan kwetsbaarheden, zijn op dit moment alleen effectief in het patchen van een smal deel daarvan.”

Keith Hoodlet, Off-by-1 Labs

De cijfers op een rij

De onderzoekers verdeelden elke patch over vijf categorieën, van volledig gerepareerd tot dubbel gebroken.

Alleen S1 is wat je wilt. S2 lijkt aantrekkelijk maar is in productie vaak net zo duur: je lek is dicht en je facturatiemodule rekent voortaan anders. Alles vanaf S3 is een schijnoplossing.

Zo controleer je een AI-patch in vijf stappen

De kern van de aanbeveling van Off-by-1 Labs is één woord: uitvoeren. Beoordeel een patch niet door ernaar te kijken, maar door de exploit te draaien. Dat is wat de onderzoekers execution-grounded verificatie noemen, en het is precies wat de meeste teams overslaan omdat de diff er goed uitziet.

Stap 1. Schrijf eerst een test die het lek aantoont. Nog voordat je het model iets vraagt. Die test moet falen op de huidige code. Heb je die test niet, dan kun je achteraf nooit vaststellen of de patch werkt.

Stap 2. Geef het model de diagnose, niet alleen de melding. Dit is het meest onderbelichte cijfer uit het onderzoek: met een correcte beschrijving van de onderliggende fout haalden de modellen ongeveer 67 procent slagingspercentage, met een onjuiste beschrijving zakte dat naar circa 17 procent. Je eigen analyse is dus vier keer zoveel waard als een betere prompt.

Stap 3. Laat het model zijn eigen werk niet beoordelen. Draai de test uit stap 1 tegen de gepatchte code. Slaagt de test, dan pas verder.

Stap 4. Draai je volledige testsuite tegen de S2-val. Een fix die het lek dicht maar gedrag verandert, telt in dit onderzoek voor één op de vijf patches. Zonder regressietests merk je dat pas als een klant belt.

Stap 5. Zoek de generalisatie. Varieer de exploit: een andere encoding, een ander pad, een net andere payload. Blijft het dicht, dan heb je een echte fix. Valt het om, dan had je een fragiele S1.

Voor stap 2 werkt onderstaand promptsjabloon goed. Het dwingt je om de diagnose expliciet te maken en verbiedt het model om zelf conclusies te trekken over de uitkomst.

Diagnose (door mij vastgesteld, niet aannemen maar gebruiken):
- Bestand + regel: {pad}:{regel}
- Onderliggende fout: {bijv. lengte wordt gecontroleerd na de kopieeractie}
- Aanvalspad dat dit misbruikt: {korte beschrijving}
- Reproductietest die nu FAALT: {pad naar testbestand}

Opdracht:
1. Schrijf een patch die de onderliggende fout wegneemt, niet alleen dit ene aanvalspad blokkeert.
2. Verander geen bestaand gedrag. Wijzigt gedrag toch, benoem dat expliciet en waarom het onvermijdelijk is.
3. Beweer NIET dat de fix werkt. Ik draai de test zelf.
4. Noem twee varianten van dit aanvalspad die jouw patch zou moeten tegenhouden.

Punt 4 is de goedkoopste kwaliteitscheck die er is: laat het model zelf de varianten opschrijven waarmee jij het daarna probeert om te trekken.

Wat betekent dit nu de Cyberbeveiligingswet geldt?

Sinds 15 augustus 2026 is de Cyberbeveiligingswet, de Nederlandse invulling van de Europese NIS2-richtlijn, in werking. Organisaties die eronder vallen moeten zich registreren, een risicoanalyse uitvoeren en op basis daarvan passende maatregelen nemen, en incidenten binnen 24 uur melden bij het CSIRT en de toezichthouder. Dat staat op de informatiepagina van het NCSC.

Vertaald naar de werkvloer: "de AI heeft het gepatcht" is geen maatregel die je aantoonbaar kunt maken. Een testrapport waaruit blijkt dat de exploit vóór de patch slaagde en erna faalde, is dat wel. Het verschil kost je een half uur per fix.

Overigens raakt dit ook bedrijven die zelf buiten de wet vallen. De zorgplicht strekt zich uit tot de toeleveringsketen, dus bouw je software of hosting voor een partij die er wél onder valt, dan komen die eisen via je contract alsnog bij jou terecht. Voor kleinere bedrijven is dat vaak de eerste keer dat securityverificatie een harde leveringsvoorwaarde wordt. De MKB-cijfers van TheAIDaily laten zien hoe ver Nederlandse bedrijven daar nu mee zijn.

Wanneer kun je een AI-patch wél vertrouwen?

Bij enkelvoudige, goed begrensde fouten waarvan jij de oorzaak al kent. Een ontbrekende invoercontrole, een verkeerd ingestelde permissie, een vergeten escaping in één functie: daar zijn de modellen aantoonbaar goed in, zeker met de juiste diagnose erbij. Het onderzoek is glashelder over de grens: hoe complexer de patch, hoe groter de kans op een FLAWED-resultaat.

Dat sluit aan bij wat Anthropic zelf publiceerde over het gebruik van Claude Code: ongeveer 80 procent van de uitvoeringsbeslissingen (hóé iets gebouwd wordt) ligt bij het model, terwijl zo'n 70 procent van de planningsbeslissingen bij de mens blijft. Bij beveiliging is de planning nu precies het deel dat je niet moet weggeven. Wie zijn agent toch verder wil laten gaan, doet er goed aan eerst harde grenzen in te stellen met hooks en deny-regels en te weten wat er sinds 14 augustus standaard zonder toestemming gebeurt.

Waar de grens ligt tussen AI-patch en mensenwerk

De les uit 6.080 patches is niet dat AI geen beveiligingswerk kan doen. Het is dat de beoordeling van het resultaat nooit bij dezelfde partij mag liggen die het schreef. Modellen zijn inmiddels sterk in het vínden van kwetsbaarheden, en dat is ook precies waar tools als Claude Security hun waarde bewijzen. Het dichten is een ander vak.

Concreet voor komende week: pak de laatste drie beveiligingsfixes die via een AI-assistent in je codebase zijn beland en probeer voor elk daarvan de originele exploit opnieuw uit. Lukt dat nog, dan weet je nu waar je moet beginnen. Off-by-1 Labs heeft de FLAWED-tooling en de volledige dataset van 6.080 patches vrijgegeven, zodat je dezelfde meting op je eigen code kunt draaien. Meer van dit soort analyses lees je in onze dagelijkse AI-nieuwsbrief.