Liever nieuwe posts als video? Abonneer op het aiMattie YouTube-kanaal — of bekijk alle video's in de playlist.
TL;DR
- Wat: AWS heeft de Deception Benchmark uitgebracht — een open dataset van bijna 15.000 codevoorbeelden waarmee je kunt meten hoe goed AI echte kwetsbaarheden onderscheidt van veilige code die er gevaarlijk uitziet.
- Waarom relevant: Als je AI-tools inzet voor beveiliging van software, wil je weten hoe vaak ze vals alarm slaan — en dat blijkt verrassend vaak te zijn.
- Wat je ermee kunt: Vraag je leverancier van beveiligingstools hoe hun systeem scoort op dit soort benchmarks, niet alleen óf het kwetsbaarheden vindt, maar hoe vaak het ernaast zit.
Ik kwam deze week een tweet tegen van Amazon Science over een benchmark die ze met "tientallen miljarden tokens" hebben gebouwd om AI-beveiligingsmodellen te testen. Wat mij direct opviel: geen enkel getest model haalde de lat die AWS zelf als minimum beschouwt voor productiegebruik. Dat vind ik het soort eerlijkheid waar je als ondernemer iets aan hebt.
Wat is de Deception Benchmark precies?
De Deception Benchmark is een open dataset die AWS op 9 september 2026 beschikbaar heeft gemaakt. Het bevat 14.822 codevoorbeelden, verspreid over 16 programmeertalen en meer dan 70 categorieën kwetsbaarheden (de zogeheten CWE-categorieën — dat is een gestandaardiseerde lijst van bekende zwakke plekken in software).
Het bijzondere zit in het woord "deception" — misleiding. De helft van de voorbeelden bevat code die er gevaarlijk uitziet, maar die in werkelijkheid veilig is. Denk aan code die een verdacht patroon bevat, maar waar tegelijkertijd een beveiliging actief is die misbruik onmogelijk maakt. De vraag aan het AI-model is dan: is dit écht een probleem, of lijkt het er alleen maar op?
Dat klinkt misschien abstract, maar het is vergelijkbaar met een rookmelder die afgaat bij elke geroosterde boterham. Technisch detecteert hij rook — maar het is geen brand. En als je rookmelder twintig keer per week vals alarm geeft, negeer je hem op een gegeven moment. Precies dát probleem probeert AWS hier meetbaar te maken.
Twee soorten uitdagingen
AWS onderscheidt twee typen tests in de benchmark:
- Code-level challenges (6.988 stuks): Twee versies van dezelfde code die op het oog bijna identiek zijn, maar waarvan er slechts één daadwerkelijk kwetsbaar is. Het verschil zit in subtiele details.
- Environment-gated challenges (2.707 stuks): Dezelfde code, maar dan in een andere omgeving geplaatst. Bijvoorbeeld: een stuk code dat kwetsbaar zou zijn op een open server, maar onschadelijk wordt als er een Kubernetes-netwerkregel actief is die het aanvalspad blokkeert.
Dat tweede type vind ik interessant, omdat het laat zien dat beveiliging niet alleen over code gaat, maar ook over de context waarin die code draait.
Hoe goed scoren AI-modellen?
AWS heeft 12 modellen van vijf aanbieders getest. Daaronder modellen van OpenAI, Anthropic, Meta, Amazon zelf en Mistral. Het resultaat is ontnuchterend.
AWS beschouwt een foutpercentage van minder dan 10% voor zowel valspositieven (veilige code onterecht als kwetsbaar markeren) als valsnegatieven (echte kwetsbaarheden missen) als een minimale eis voor productiegebruik. Geen enkel getest model haalde die grens op beide fronten.
Bij directe bevraging vlagden modellen tussen de 41% en 99% van de veilige code als kwetsbaar. Dat betekent dat bij het beste model nog steeds vier van de tien veilige stukken code onterecht als probleem worden aangemerkt. Bij het slechtste model is dat praktisch alles.
Er is ook een slimmere aanpak getest: modellen vragen om een daadwerkelijk exploitatiebewijs te leveren — een zogeheten "proof of exploit". Dat verminderde het aantal valspositieven met 17 tot 74 procentpunten, maar introduceerde een nieuw probleem: modellen misten dan 7% tot 44% van de échte kwetsbaarheden. Je ruilt dus het ene probleem in voor het andere.
Het beste resultaat kwam van Claude Opus 5, met een nauwkeurigheid van 79,3% bij de proof-of-exploit-methode — maar ook dan lag het valsnegatiefpercentage op 16,8%. Dat is boven de grens die AWS zelf als minimum hanteert.
Waarom dit ertoe doet voor ondernemers
Kun je je voorstellen wat dit betekent als je een softwarebedrijf runt, of als je een team hebt dat software ontwikkelt? Je koopt een AI-beveiligingstool die je codebase doorloopt en je krijgt een rapport met honderden waarschuwingen. Maar de helft daarvan blijkt vals alarm. Je ontwikkelaars besteden uren aan het onderzoeken van niet-bestaande problemen, raken gefrustreerd, en — dat is het echte risico — beginnen de tool te negeren. Waardoor echte kwetsbaarheden ook aan de aandacht ontsnappen.
Dit is niet alleen een technisch probleem. Het is een bedrijfsprobleem. Elke vals-positieve melding kost tijd. Tijd van mensen die je ook aan productontwikkeling of klantwerk had kunnen besteden.
Wat mij betreft is de belangrijkste les hier niet dat AI-beveiligingstools slecht zijn — ze vangen wel degelijk echte problemen — maar dat je ze niet blind kunt vertrouwen. AWS zegt het zelf: "Pair any AI-assisted review with human verification on high-risk code paths." Combineer AI-controle met menselijke verificatie, zeker bij kritieke onderdelen.
Wat maakt deze benchmark anders?
Er bestaan al benchmarks voor AI en code, maar de meeste testen of een model kwetsbaarheden kan vinden. De Deception Benchmark test iets anders: of een model kan inschatten wanneer iets geen kwetsbaarheid is, ook al lijkt het er wel op.
Dat onderscheid is wezenlijk. Het is het verschil tussen een arts die elke hoofdpijn als hersentumor diagnosticeert (hij mist geen enkele tumor, maar je vertrouwen in zijn oordeel is nul) en een arts die kan inschatten wanneer het gewoon spanningshoofdpijn is.
AWS heeft de labels van de dataset bewust niet openbaar gemaakt, zodat modelbouwers hun systemen niet op de antwoorden kunnen trainen. Aanbieders kunnen de dataset downloaden, hun model erop loslaten, en de voorspellingen insturen voor onafhankelijke scoring. Dat voorkomt dat de benchmark een geheugentest wordt in plaats van een echte vaardigheidstest.
Wat kun je hier als ondernemer mee?
Als je zelf geen software ontwikkelt, is deze benchmark niet iets waar je direct mee aan de slag gaat. Maar het geeft je wel een concreet handvat voor gesprekken met je IT-leverancier of ontwikkelteam.
Stel dat je een AI-beveiligingstool overweegt of al gebruikt. De vraag die je kunt stellen is niet "vindt deze tool kwetsbaarheden?", maar "hoe vaak slaat deze tool vals alarm, en hoe weten we dat?" Dat is een wezenlijk andere vraag — en een die volgens deze benchmark nog niet bevredigend beantwoord kan worden door de huidige generatie modellen.
AWS heeft de benchmark, het evaluatieproces en een whitepaper openbaar beschikbaar gemaakt op GitHub. Het feit dat ze dit vrijgeven — inclusief resultaten die hun eigen model (Nova 2 Lite) niet in het beste daglicht zetten — vind ik een teken dat ze het serieus menen met transparantie. Of dat puur altruïsme is of ook een strategische zet om de standaard te zetten waaraan concurrenten gemeten worden, laat ik aan de lezer.
Voor mij is dit vooral een signaal dat AI-beveiligingstools in een fase zitten waarin ze nuttig zijn als hulpmiddel, maar nog niet betrouwbaar genoeg als eindoordeel. En dat eerlijk benoemen is waardevoller dan het verzwijgen.
80% van de AI-projecten haalt productie nooit.
Ik bouw de 20% — van prototype naar draaiend systeem, binnen weken.