Sleutels in code
Een wachtwoord of API-sleutel die in een bestand belandt, is een patroon. Daar is een scanner uitstekend in.
Een beveiligingsscanner in je terminal
Er zit inmiddels een beveiligingsscanner in de terminal waar je agent draait: hij kijkt mee terwijl er code ontstaat en waarschuwt als er iets bekends langskomt. Dat is een echte verbetering. Het is ook precies het soort gereedschap waarvan mensen denken dat het meer dekt dan het doet.
01/10
Waarom dit er nu is
De cijfers over AI-code werden te groot om te negeren.
Metingen op AI-gegenereerde code laten sinds vorig jaar consequent hetzelfde zien: een aanzienlijk deel van de applicaties die zo ontstaan, gaat live met een kritieke kwetsbaarheid erin. Afhankelijk van de meting gaat het om ruim de helft tot bijna twee derde.
De oorzaak is geen slordigheid maar een verschil in doel. Een klassieke kwetsbaarheid komt voort uit een menselijke vergissing. Een kwetsbaarheid in AI-code komt voort uit een model dat optimaliseert voor werkende code in plaats van veilige code. Het resultaat werkt, en dat is precies wat er gevraagd werd.
Een scanner die meekijkt tijdens het bouwen, is het antwoord op de vraag hoe je dat afvangt zonder het tempo te verliezen. Hij is er dus niet omdat de modellen slechter zijn geworden, maar omdat er meer code doorheen komt dan iemand nog kan lezen.
02/10
Wat er in de bekende gevallen misging
Drie incidenten, en geen ervan zou door een scanner zijn gevangen.
Bij een startpagina die begin 2026 live ging, lagen binnen drie dagen anderhalf miljoen inlogsleutels en tienduizenden e-mailadressen op straat. De hele applicatie was uit gesprekken met een AI-assistent ontstaan en niemand had de code gelezen. De fout zat niet in een regel code maar in wat er ontbrak: rechten op de gegevens.
Bij een andere app konden gebruikers elkaars privéberichten zien. De toegangscontrole was gegenereerd, deed het, en klopte alleen niet. Ook dat is geen patroon dat een scanner herkent — het is logica die verkeerd redeneert.
En bij een breed gebruikt bouwplatform bleken databases stelselmatig zonder rechtenregels te worden aangemaakt, waardoor honderdzeventig live applicaties open stonden. Er was geen enkele foutmelding; de apps deden het allemaal. Dat is precies de categorie waar deze scanner niet over gaat.
03/10
Wat hij goed vangt
Bekende fouten
Invoer die ongefilterd in een zoekopdracht belandt, een onveilige functie, een verouderd pakket met een bekend lek.
Instellingen die openstaan
Een dienst die zonder authenticatie bereikbaar is, of rechten die op alles staan.
04/10
Wat hij niet ziet
- Fouten in de logica van je rechten. Dat gebruiker A de gegevens van gebruiker B kan opvragen, is geen patroon maar een gevolg van hoe jouw regels zijn geschreven.
- Een database die openstaat omdat de rechtenregels ontbreken. Er is dan niets fout aan de code; er ontbreekt iets buiten de code.
- Instructies die van buiten binnenkomen en door je AI-functie worden opgevolgd. Dat gedrag zit niet in je code maar in wat je model met tekst doet.
- Wat er gebeurt als iemand je app op een manier gebruikt die jij niet had bedacht. Dat is geen scanwerk maar denkwerk.
05/10
Hoe je hem gebruikt zonder erop te leunen
Als eerste zeef, niet als goedkeuring.
De verstandige houding is die van een spellingcontrole: hij haalt er domme fouten uit en hij zegt niets over of je verhaal klopt. Dat betekent dat een schone uitslag geen bericht is dat je klaar bent, maar dat de bekende categorie is afgevinkt.
Wat je erbij doet, is een korte eigen ronde langs de dingen die geen patroon zijn. Kan een ingelogde gebruiker bij andermans gegevens? Wat gebeurt er als iemand een veld anders invult dan bedoeld? Welke gegevens gaan er de deur uit en waarheen?
Die ronde kost een halfuur en vindt in de praktijk andere dingen dan de scanner. Samen dekken ze het meeste af; los van elkaar geeft geen van beide een compleet beeld.
06/10
Het rondje dat je er zelf bij doet
Vijf vragen, een halfuur, en het vindt andere dingen dan de scanner.
Kan een ingelogde gebruiker bij de gegevens van een andere gebruiker? Probeer het echt: log in als de een, vraag iets op van de ander. Dat is de test die in de bekende gevallen niet was gedaan.
Wat gebeurt er als iemand een veld anders invult dan bedoeld? Een negatief aantal, een datum in het verleden, een tekst van tienduizend tekens. Je hoeft niet alles af te lopen; drie velden geven je al een beeld van hoe streng je systeem is.
Welke gegevens gaan de deur uit en waarheen? Kijk in het netwerkverkeer van je eigen app welke verzoeken er naar buiten gaan. Bij apps die op een bouwplatform draaien, staan daar vaker partijen tussen dan mensen verwachten.
En tot slot: staat er ergens een sleutel in code die de browser downloadt? Dat is het enige punt uit dit rijtje dat de scanner ook vindt, en het is meteen het punt dat het vaakst voorkomt.
07/10
Wanneer je verder gaat dan dit
Wel zinvol
- Je verwerkt persoonsgegevens van derden
- Je hebt zakelijke klanten met een vragenlijst
- Er zit betalingsverkeer of medische informatie in
Niet zinvol
- Een proefversie voor jezelf en twee collega's
- Iets zonder inlog en zonder opslag
- Een interne tool op een gesloten netwerk
08/10
Wat het waarschuwen zelf oplevert
Het onderschatte voordeel van een scanner die meekijkt, is niet dat hij fouten vindt maar dat hij ze vindt op het moment dat je er nog in zit. Een melding drie weken later is een klus; een melding tijdens het bouwen is een correctie van twee minuten.
Dat verandert ook wat je leert. Wie tien keer een waarschuwing krijgt over sleutels in code, gaat vanzelf anders werken. Dat effect is op de lange termijn waarschijnlijk waardevoller dan de gevonden fouten zelf.
Waar het tegen je gaat werken, is als er zoveel meldingen komen dat je ze wegklikt. Dat gebeurt vooral bij bestaande projecten die je er voor het eerst overheen haalt. Ruim in dat geval eerst één categorie helemaal op, in plaats van overal een beetje.
09/10
Wat wij op een bouwdag doen
We laten de scanner meelopen en behandelen zijn uitslag als de eerste van twee rondes. De tweede is met de hand: rechten controleren op de manier waarop een buitenstaander het zou proberen, en kijken welke gegevens de deur uit gaan.
Voor een prototype dat aan echte mensen wordt getoond, is dat de ondergrens. Niet omdat er veel op het spel staat, maar omdat testgebruikers echte e-mailadressen achterlaten en die net zo goed op straat kunnen liggen als die van betalende klanten.
10/10
Veelgestelde vragen
Vervangt dit een beveiligingsonderzoek?
Nee. Het vangt de bekende categorie af. Een onderzoek door mensen zoekt naar wat er in jouw specifieke opzet mis kan gaan, en dat is een andere vraag.
Moet ik hem aanzetten voor een klein project?
Ja, want het kost niets en de meest voorkomende fout — een sleutel die in code belandt — komt ook in kleine projecten voor.
Wat doe ik met honderd meldingen op een bestaand project?
Niet allemaal tegelijk. Kies één categorie, ruim die helemaal op, en ga dan pas verder. Overal een beetje opruimen levert een lijst op die nooit korter wordt.
Zijn er valse meldingen?
Zeker, vooral bij patronen die in jouw situatie geen probleem zijn. Markeer die expliciet als bekeken in plaats van ze te negeren, anders lees je ze elke keer opnieuw.
Helpt dit tegen prompt injection?
Nauwelijks. Dat is gedrag van je AI-functie, niet een patroon in je code. Daar heb je andere maatregelen voor, zoals beperken wat je model mag aanroepen.
Kan mijn agent de gevonden fouten ook meteen oplossen?
Vaak wel, en voor de eenvoudige categorie is dat prima. Bij alles wat met rechten of authenticatie te maken heeft, wil je de wijziging zelf lezen voordat hij live gaat.
