Code kan foutloos werken en toch iemand de kans geven om geld te stelen, privégegevens in te zien of de controle over te nemen.
CounterProof is een onafhankelijk team dat uw code probeert te kraken voordat iemand anders dat doet. Bij elk probleem dat we melden, laten we het bewijs zien: waar het in de code zit, hoe we het hebben gecontroleerd en wat nog onzeker is. U krijgt een ondertekend rapport dat u kunt delen met klanten, verzekeraars, investeerders en toezichthouders.
Een model dat zijn eigen werk nakijkt, is geen onafhankelijke review.
Vraag een onafhankelijke review aan →Niemand koopt een code review om de review zelf. Het gaat om wat die mogelijk maakt.
U leest dit niet omdat u vanochtend wakker werd met de wens om een beveiligingsbeoordeling te laten doen. Iets vraagt u om bewijs.
Drie van deze vier nemen nooit genoegen met uw eigen woord over uw eigen code. Onafhankelijkheid is precies wat zij kopen, en het is de enige eigenschap die geen team voor zijn eigen werk kan leveren. De vierde, de toezichthouder, accepteert vaak uw eigen beoordeling, en houdt u daarna aan elk document dat eronder ligt. Hoe dan ook moet het bewijs standhouden. Dat is wat wij leveren.
Waar review past in uw kwetsbaarhedenbeheer, fase voor fase →
Vinden werd goedkoop. Bewijzen werd moeilijk.
Elke opdracht levert een CounterProof Assessment op onder een vast opdrachtnummer (CPR-YYYY-NNN) waarnaar uw maintainers, een overnemende partij of uw fix-commits kunnen verwijzen. Elke bevinding is ofwel bevestigd tegen uw broncode (exact bestand en regel, reproductiepad, classificatie van de impact) ofwel uitdrukkelijk aangemerkt als alleen aannemelijk. Geen opvulling, niets uit een scanner, niets waar u niets mee kunt. Het dossier vermeldt ook wat we hebben gecontroleerd en niet hebben gevonden: een vastgelegd negatief resultaat is hier een volwaardig deel van de oplevering, geen mislukte opdracht.
Elke bevinding vermeldt het bewijsniveau dat ze werkelijk heeft bereikt: broncodetrace, compileerbewijs (de build laten falen en daarna slagen, precies zoals de bevinding voorspelt), test of live reproductie, en voor elke probabilistische bewering een proportie met een interval, waarbij de logs per poging bewaard blijven. Ze suggereert nooit een hoger niveau. Elke verwijzing in de vorm pad:regel wordt machinaal gecontroleerd tegen de exacte revisie die we hebben beoordeeld, voordat het rapport de deur uitgaat. U kunt ons werk nacontroleren. Dat is bewust zo.
Wij zitten op het punt waar een bevinding een beslissing wordt die iemand later moet kunnen verantwoorden: toetsing, afsluiting en het ondertekende dossier. Niet in de race van scanners om kandidaten. Het vinden is een bijproduct van een opdracht; het dossier is het product.
Als een bevinding de toets niet doorstaat (die van u, van uw maintainers of van onze eigen hercontrole), trekken we haar schriftelijk in, met de reden, onder hetzelfde opdrachtnummer. Dat doen we uit eigen beweging; de andere partij hoeft er niet om te vragen. Het intrekkingslogboek is geen erkenning van een fout; het is het mechanisme.
Voorbeeld: de vorm van een bevindingIllustratief voorbeeld, niet afkomstig uit een klantopdracht; de identificatoren zijn plaatshouders. Rapporten worden in het Engels opgesteld.
“De getuigen zijn nu gratis. De kritische editie niet.”
De markt is gaan concurreren op het aantal bevindingen dat een tool kan genereren, maar een bevinding is een getuige, geen vonnis. Een verwijzing als bestand:regel kan een lezer in een minuut openen en controleren; een kaal “Critical” niet. In onze dossiers volgt de ernst uit het bewijsniveau en is die nooit een input voor de marketing. De getuigen zijn nu gratis. De kritische editie niet. Een bevinding is geen vonnis →
Vier stappen. U kent de scope voordat u betaalt, en het dossier blijft daarna van u.
Een eerste opdracht hoeft niet alles te omvatten wat u levert. Een kleine, goed gekozen scope (één module, één vertrouwensgrens) levert hetzelfde verdedigbare dossier op in een omvang die u kunt beoordelen, en kan het eerste bewijsstuk voor deel II, punt 3 zijn dat een fabrikant in zijn dossier opneemt.
Vloeiendheid is geen teken van kwaliteit. Het is de manier waarop het misgaat.
Wie zelf een regel code schrijft, twijfelt eraan. Die persoon weet dat het een gok was, en die twijfel is een veiligheidsmechanisme: juist daardoor gaat iemand het testen.
Een model schrijft dezelfde regel vloeiend, in precies de toon die het gebruikt voor de regels die wél kloppen. Voor wie meeleest, oogt vloeiendheid als vakmanschap. Een junior engineer geeft u iets wat zichtbaar ruw is, en u controleert het. Een model geeft u tweehonderd gepolijste regels met voor elke regel een zelfverzekerde reden, en u controleert het niet.
De valkuil is niet dat modellen vaker fout zitten dan mensen. Het is dat hun foute antwoorden in dezelfde toon binnenkomen als hun goede: van buitenaf niet te onderscheiden, omdat ze van binnenuit niet te onderscheiden zijn.
Vervolgens schrijft hetzelfde proces de test die de code goedkeurt, en het commentaar dat haar uitlegt. Alle drie zijn het eens, want alle drie komen van dezelfde plek. Die overeenstemming leest als drie onafhankelijke bevestigingen. Het is er één.
“Hun foute antwoorden komen binnen in dezelfde toon als hun goede.”
De nuttige vraag is dus niet of een model goede code kan schrijven; dat kan het, met een methode eromheen. De vraag is wat uw reviewproces eigenlijk meet als alles wat het controleert uit dezelfde bron komt: de code, de test, de uitleg, en steeds vaker ook de tool die u bouwde om ze te controleren. Goed gedaan is het resultaat goed. Slecht gedaan leest het precies hetzelfde.
Een review vindt wat de reviewer kan vinden.
Laat één model over een codebase lopen en een kort rapport vertelt u iets beperkts: dat model, met die prompts en tools, op die dag, heeft dit gevonden. Wat het niet vond, staat niet in het rapport, en kan er per definitie niet in staan.
Laat hetzelfde model nog eens over dezelfde code lopen en reken op een andere set. Code review door een LLM gedraagt zich meer als fuzzing dan als een statische analysetool: reken op andere bevindingen bij een exacte herhaling, bij een kleine wijziging in de prompt en bij een nieuwe modelgeneratie; en net als fuzzing is het nooit af. (Thomas Dullien, “An age of experimentation”, BlueHat Asia 2026.)
Hoeveel dat uitmaakt, hangt af van hoe ver de blinde vlekken van verschillende reviewers overlappen; voor code review heeft niemand dat gemeten. Onderzoek naar gecorreleerde fouten, in modelpopulaties met modellen van verschillende leveranciers, vond aanzienlijke overlap op multiplechoicebenchmarks en op een taak waarin cv's werden gescreend; of dat ook geldt voor het vinden van kwetsbaarheden, is niet aangetoond. Wat het wel laat zien, is dat verschillende leveranciers niet automatisch onafhankelijk van elkaar zijn.
Meerdere dingen kunnen begrenzen wat één ronde heeft gemist: een bewijs, een testsuite, een fuzzer, een specialist, bewust ingebrachte fouten, of een reviewer die verschilt van de eerste. Wat het niet kan begrenzen: dezelfde ronde met meer overtuiging lezen.
We hebben niet aangetoond dat review door meerdere reviewers meer echte fouten vindt; het experiment dat we ontwierpen om dat te testen, is stopgezet voordat het liep, en dat zeggen we openlijk. Het beperktere punt is het punt waar we achter staan: een schone ronde van één reviewer is een afgebakend resultaat, en wie die leest als bewijs dat de code schoon is, trekt een conclusie die dat resultaat niet draagt. Het volledige argument (Engelstalig) →
We hebben het uitgebreide argument op papier gezet, inclusief de grenzen van onze eigen methode en wat we niet hebben aangetoond: een inleiding in begrijpelijke taal en het volledige paper erachter, gepubliceerd als preprint onder doi:10.5281/zenodo.22030516 (CC BY 4.0), in het Engels. Het is niet peer-reviewed, en dat staat er ook in.
U kunt dezelfde modellen draaien. Onafhankelijk zijn kunt u niet.
Wie meerdere AI-modellen over de eigen code laat lopen, kopieert onze tooling en verliest de eigenschap waar het om gaat. Uw team kiest wat de reviewers te zien krijgen, formuleert de vragen en beoordeelt de antwoorden, en elk van die keuzes brengt uw aannames regelrecht terug in de review. Dat is geen gebrek aan discipline; het zit in de structuur. De maker van een systeem kan niet zijn eigen scheidsrechter zijn.
Zelfs een foutloze interne review blijft dus uw eigen woord over uw eigen code. Wat zij kopen, is een derde partij die bereid is te tekenen. Wij zijn geen aangemelde instantie en we certificeren geen conformiteit; wij leveren het onafhankelijke bewijs dat uw beoordeling ondersteunt en dat zo is opgezet dat ieder ander het opnieuw kan toetsen.
Voor de methode maakt het niet uit wie (of wat) uw code heeft geschreven. Onafhankelijkheid ontbreekt net zo vaak bij code die door mensen is geschreven. Code die door machines is geschreven, maakt het gat alleen onmogelijk te negeren.
U zou dit toch ontdekken. Beter dat u het van ons hoort.
CounterProof maakt deel uit van een groep die infrastructuur bouwt voor betalingen en voor de bewaring van digitale activa. Daar is deze methode gesmeed, en dat betekent dat een gelieerde onderneming in een aangrenzende markt actief kan zijn, of met u kan concurreren, als u in die markten bouwt.
Daarom vertellen we u vóór elke opdracht schriftelijk wat de groep precies bouwt en waar ze actief is. U beslist of dat acceptabel is, en u beslist dat voordat u ons iets hebt betaald. Is het niet acceptabel, dan is dat een legitiem antwoord en horen we het liever aan het begin.
Wat onze claim van onafhankelijkheid wel en niet dekt, precies: wij geven geen beoordeling af over code die is geschreven door CounterProof of door een onderneming uit onze groep. Die grens is structureel. Het is een uitspraak over wiens code we beoordelen, geen bewering dat we nergens in de buurt van uw sector commerciële belangen hebben. De onze staan hierboven genoemd, en u beslist of die acceptabel zijn voordat u ons iets hebt betaald.
De beweringen die we niet namens u doen, staan apart vermeld: Wat we niet zullen beweren (Engelstalig) →
Drie mensen, met naam en toenaam, publiek aanspreekbaar.
Een ondertekende beoordeling betekent dat er iemands naam onder staat. Dit zijn de mensen, en welke naam waarvoor instaat.
We zijn een familiebedrijf (vader, zoon en dochter), en het reviewteam bestaat uit twee mensen. Beide feiten haalt een due-diligenceteam zelf boven water, dus zeggen we ze liever hier: een reviewteam van twee mensen neemt minder opdrachten aan dan een bureau, wijst alles buiten zijn domein af en kan een zwakke ronde niet verstoppen achter een merknaam. Dat is de afweging, en het is de reden dat de methode is opgeschreven en gemechaniseerd in plaats van in iemands hoofd te zitten.
Wat we lezen, en wat we controleren.
De verordening noemt cryptowallets nergens. Ze is van toepassing op producten met digitale elementen. Vanaf december 2027 eist ze ook doeltreffende en regelmatige tests en evaluaties van de beveiliging van het product. In onze lezing raakt die plicht aan de vraag of een maker een fout vindt voordat een aanvaller dat doet. Deze notitie legt het toepassingsgebied, de meldtermijnen en de rol van een onafhankelijke review uit.
Vinden werd goedkoop; de rest van de levenscyclus niet. Een rondgang langs de fasen (identificeren, beoordelen, beslissen, verhelpen, rapporteren, bewaren) met wat de EU Cyber Resilience Act in elke fase vraagt, en waar een onafhankelijke adversariële review past: in de fasen na de eerste.
Vier heel verschillende praktijken gaan inmiddels onder deze naam. Ze bekijken allemaal uw code zoals een aanvaller dat zou doen. Geen ervan geeft u op zichzelf zowel een ondertekend rapport van reviewers buiten uw organisatie als een duidelijke vermelding van hoe ver elke bevinding is bewezen. Hieronder: wat wij leveren, wat een tweede AI-model niet kan, en de grenzen die we noemen voordat u koopt.
Neem contact op voordat de deadline u inhaalt.
Mail ons wat u wilt laten beoordelen, welke beslissing het assessment moet onderbouwen en wanneer u het nodig hebt. Elenora Soons, onze accountmanager, plant dan een gesprek met het reviewteam in.