Claude Security is in openbare bèta: wat “Scan to Fix” wel en niet claimt

Het beveiligingsproduct van Anthropic’s is nu een publieke bèta voor Claude Enterprise, en de one-liner is een reeks in plaats van een adjectief: van scan tot fix, naadloos uitgevoerd. De mechaniek onder die regel staat duidelijk op de productpagina: Claude scant je codebase met Claude Mythos, valideert bevindingen en stelt patches voor die je kunt beoordelen en goedkeuren. Drie werkwoorden, één modelnaam en een scope-beperking die je makkelijk over het hoofd ziet: dit is een bèta, en die is bedoeld voor Enterprise-klanten, niet voor iedereen die toevallig een repository heeft.

De interessante vraag was nooit of een taalmodel een kwetsbaarheid kan vinden. Modellen doen dat al een tijdje, soms goed genoeg om de mensen die de code schreven in verlegenheid te brengen. De interessante vraag is wat er gebeurt tussen het moment waarop een bevinding verschijnt en het moment waarop die wordt gesloten, want in dat gat leven beveiligingsachterstanden: een wachtrij van plausibele problemen, door niemand gesorteerd, aan iedereen toegewezen, bij toeval gesloten. Het antwoord van Anthropic is een pijplijn met vier fasen, en elke fase doet een bewering die op zichzelf kan worden onderzocht.

Wat “openbare bèta voor Claude Enterprise” betekent

De beschikbaarheidsregel is ongewoon bot en het is de moeite waard die te citeren in plaats van te parafraseren: beschikbaar in publieke bèta voor Claude Enterprise. Daaronder staan twee knoppen: contact opnemen met sales, en de tutorial lezen. Geen van beide is een aanmeldformulier. In de praktijk betekent dat dat de koper een bedrijf is dat al een Enterprise-overeenkomst heeft en een securityteam dat genoeg aanzien heeft om om een nieuwe scanner te vragen, en niet een individuele engineer die iets op een zijproject wil richten.

Er is een tweede, lichtere manier om binnen te komen. De Claude Security-plugin voor Claude Code is in bèta. Het is een ander stuk software met een ander uitrolverhaal — scannen, valideren en patchen binnen Claude Code terwijl de code in je eigen omgeving blijft — en het is de versie die ertoe doet voor een team wiens obstakel niet het budget is, maar een regel over waar broncode naartoe mag.

De scan stopt niet.

Het eerste gedocumenteerde gedrag is de diepe eerste scan: Claude voert deze één keer uit over een codebase en blijft vervolgens scannen terwijl de code verandert. Het is een korte zin met een grote operationele consequentie. Een eenmalige scan is een foto. Codebases zijn geen foto's; ze zijn weer. Een bevinding die op de dag van de audit accuraat was en door drie daaropvolgende merges half is opgelost, is erger dan helemaal geen bevinding, omdat die aandacht opeist van de mensen die het opnieuw moeten lezen.

Continue scanning is ook het onderdeel van het product dat het moeilijkst te faken is. Het vereist dat de scanner begrijpt welke wijzigingen ertoe doen, wat een andere vaardigheid is dan het vinden van een kwetsbaarheid in een statische tree. De pagina beschrijft niet hoe die prioritering werkt, en dit artikel zal daar niet naar gissen.

De enige as waarop de bewering specifiek is

Anthropic beweert dat Claude Security datastromen door bestanden en repositories heen volgt om kwetsbaarheden te vinden die scanners op basis van patroonherkenning mogelijk niet detecteren. Dat is de meest controleerbare bewering in de hele productbeschrijving, omdat er een mechanisme in wordt genoemd in plaats van een uitkomst.

Patroonherkenning zoekt, zoals de naam al suggereert, naar een bekend slecht patroon: een functieaanroep met een besmet argument, een string die aan een query wordt geplakt, een bekende onveilige API. Het is snel, het is goedkoop, en daarom staan traditionele scanners tegelijk bekend om twee dingen — overal waar hetzelfde type bug opduikt deze opsporen, en het team bedelven onder bevindingen die onbereikbaar blijken te zijn. Het alternatief is een waarde volgen vanaf het punt waar die het systeem binnenkomt tot waar die wordt gebruikt, over de grenzen tussen bestanden en services heen. Daar schuilen de echte bugs, en daar wordt de analyse ook duur, omdat de tool meer context moet vasthouden dan er in één functie past.

Let echter op het voorbehoud in de zin. Mogelijk niet detecteren. Dat is het juiste woord om te gebruiken wanneer een leverancier geen benchmark heeft om naar te verwijzen, en het is ook de reden dat deze bewering tegen je eigen codebase moet worden getest in plaats van te worden aangenomen als een eigenschap van het product.

Adversariële verificatie, en een dreigingsmodel dat je kunt bewerken

De tweede fase is de fase die het probleem van valse positieven aansnijdt dat elk securityteam kent. Elke bevinding ondergaat adversariële verificatie voordat zij het team bereikt. Iets probeert de bevinding te ontkrachten voordat een mens haar ziet: om aan te tonen dat de input de sink niet daadwerkelijk kan bereiken, of dat het pad stroomopwaarts wordt afgeschermd, of dat de betreffende code dood is.

De tweede helft van diezelfde zin is stilletjes de interessantste ontwerpbeslissing op de pagina. Een dreigingsmodel dat je team kan bewerken, bepaalt wat het waard is om te markeren. In de praktijk legt dat de definitie van relevantie in handen van de klant. Een scanner die zelf de ernst bepaalt, zit er altijd net naast, want ernst is contextueel: een niet-geauthenticeerd endpoint in een interne beheertool is een ander probleem dan hetzelfde endpoint op het openbare internet, en geen enkele leverancier kan weten naar welke van de twee hij kijkt. Toestaan dat het dreigingsmodel bewerkt wordt, is de eerlijke erkenning daarvan.

Het creëert ook werk. Een dreigingsmodel dat niemand onderhoudt, wordt een filter dat de dingen verbergt waar niemand aan heeft gedacht, wat het tegenovergestelde is van waarvoor een scanner bedoeld is. De teams die hier waarde uit halen, zijn de teams die het dreigingsmodel als een levend document met een eigenaar behandelen, net zoals ze met de runbooks omgaan.

Een patch is de eenheid van output.

Elke bevinding bevat een aanbevolen patch die het team kan beoordelen en goedkeuren, en Claude markeert de bevinding als opgelost zodra de oplossing live gaat. Die zin bevat twee beweringen, en die verdienen het om apart te worden behandeld.

Het eerste is dat de output van een scan een wijziging is, geen ticket. Dat is het verschil tussen een engineer vertellen dat er een probleem in diens code zit en hem vertellen hoe de gecorrigeerde code eruitziet. Het comprimeert het minst plezierige deel van beveiligingswerk — andermans code goed genoeg begrijpen om die te repareren zonder kapot te maken wat die doet — en het comprimeert dat voor de persoon die de code het minst begrijpt. Dat is ook het risico: een patch die er correct uitziet en de review doorstaat omdat de reviewer moe was, is een nieuwe bug met een groen vinkje.

De tweede bewering gaat over afsluiting. Claude markeert een bevinding als opgelost zodra de oplossing wordt uitgerold, zodat bevindingen worden afgesloten in plaats van zich op te stapelen. Een achterstand is geen falen van detectie. Het is een falen van de administratie: dezelfde kwetsbaarheid wordt zeven keer gerapporteerd over zeven scans, en de wachtrij groeit sneller dan wie dan ook hem kan wegwerken. Een bevinding traceren tot de commit die deze oplost, is het mechanisme dat een continue scanner draaglijk maakt in plaats van demoraliserend.

Anthropic is er expliciet over dat de mens in het proces betrokken blijft, waarbij elke patch moet worden beoordeeld en goedgekeurd. Iedereen die dit inzet, zou die zin als de dragende zin moeten beschouwen in plaats van de disclaimer onderaan.

Twee releases, één richting

Claude Security verscheen niet op zichzelf. Anthropic bracht Code Review op 15 oktober 2026 uit als algemeen beschikbaar, en de continue scanning plus het bijhouden van fixes van Claude Security kwamen op 21 oktober 2026 in openbare bèta voor Claude Enterprise beschikbaar. Samen gelezen zeggen de twee iets over de richting: review verschuift van een poort waar een wijziging aan het eind doorheen gaat naar een proces dat meeloopt met de wijziging terwijl die wordt geschreven. De dagen tussen die twee data zijn kort genoeg om de producten te beoordelen als één verhaal over waar beveiligingswerk naartoe gaat, niet als twee losstaande releases.

Wat niet is gepubliceerd, en het getal dat uitsluitsel zou geven

De lijst met onbekenden is hier langer dan de lijst met beweringen, en dat is normaal voor een openbare bèta in plaats van een schandaal. Hoeveel van een codebase een scan dekt, is niet gepubliceerd. De scanduur is niet gepubliceerd. Percentages valse positieven zijn niet gepubliceerd. Detectiebenchmarks zijn niet gepubliceerd. Er is geen onafhankelijke evaluatie. Prijs per seat is niet gepubliceerd, en de lijst met ondersteunde talen ook niet.

Daarvan is de ontbrekende detectiebenchmark degene die een aankoopbeslissing verandert. Zonder die benchmark is “vangt wat patroonherkenningsscanners missen” een bewering die alleen een richting aangeeft en niet kan worden vergeleken met de scanner die al in het budget zit. De lijst met ondersteunde talen is het tweede punt: een polyglot repository is de normale situatie in een bedrijf van welke omvang dan ook, en een scanner die uitblinkt in drie talen en ontbreekt voor de andere vijf, is een scanner die een misleidend beeld geeft van het risico-oppervlak.

Niets hiervan betekent dat het product niet werkt. Het betekent dat de evaluatie door de koper moet worden uitgevoerd, met de eigen code van de koper, en dat een demo dat niet kan.

Hoe kun je het toch evalueren

Als je team het gaat uitproberen, is het nuttige experiment niet een nieuwe repository met een opzettelijk geplante zwakheid. Het is een repository die al een geschiedenis heeft: een service die vorig jaar een incident had, een bibliotheek met een bekende kwetsbaarheid waarvan het twee weken duurde om die te verhelpen, een module waar iedereen een beetje bang voor is. Richt de scan daarop en vergelijk wat die vindt met de bevindingen die je team al had opgeschreven. Recall op bekende problemen is meetbaar, zelfs wanneer een leverancier geen benchmark heeft gepubliceerd, omdat de ground truth in je eigen incidenttracker zit.

Ten tweede, let op het dreigingsmodel. Als het eerste dat je team doet het uitschakelen van de meeste categorieën is om de wachtrij kleiner te maken, dan heb je geleerd dat het standaardmodel niet past bij het risico dat je team daadwerkelijk draagt, en dan moet je het model aanpassen, niet het filter. Ten derde, meet de stap die ertoe doet: hoe lang het duurt vanaf het moment dat een bevinding verschijnt totdat een patch wordt samengevoegd. Dat getal is van jou, het is vergelijkbaar tussen tools, en het is het getal waarvan het product daadwerkelijk beweert dat het dat verbetert.

Waar een router staat, en waar niet

De grens is het vermelden waard. Claude Security is een Anthropic-applicatie. Wij hosten het niet, wij verkopen het niet, en we kunnen je niet vertellen wat het wel of niet in je repository heeft gevonden. De scanner draait op Claude Mythos, en we claimen niet dat model te hosten.

Wat wij doen is modellen draaien. Eén OpenAI-compatibel endpoint, één sleutel, meer dan 200 modellen erachter, de lijstprijs van de provider doorgegeven zonder opslag, en automatische failover tussen providers wanneer een van hen hapert. Claude Opus 5.5 staat in die catalogus tegen $4,00 per miljoen inputtokens en $20,00 per miljoen outputtokens, met een context van 1M tokens en cache-leesacties tegen $0,20 per miljoen. Dat is een feit over onze catalogus, geen bewering over de scanner.

Waar het relevant wordt, is het deel van een beveiligingsprogramma dat geen scanner is: de interne tool die duizend bevindingen samenvat tot iets wat een mens kan triageren, de agent die het advies opstelt, de reviewstap die een team rond zijn eigen regels wil bouwen. Dat zijn gewone modelaanroepen, en een router is een redelijke manier om ze uit te voeren zonder een leverancier hard te coderen. De routing-DSL is van belang wanneer de ene stap een klein model wil voor volume en de volgende een zorgvuldig model voor beoordeling; automatische failover is van belang wanneer de aanroep in een pipeline zit die om drie uur 's nachts draait en niemand meekijkt.

Wat de bèta je eigenlijk vraagt te vertrouwen

Zet de verpakking opzij en het product zet in op drie dingen. Dat een model dat over code redeneert dingen vindt die patroonherkenning niet vindt. Dat een tweede, adversariële doorgang genoeg is om de ruis laag te houden. Dat een bevinding pas af is wanneer een patch wordt uitgebracht en de wachtrij erachter sluit. De derde gok is de minst glamoureuze en het meest waarschijnlijk juist, omdat het een uitspraak is over proces in plaats van over intelligentie.

De eerste gok is degene die je moet testen. Anthropic heeft het mechanisme gepubliceerd — het traceren van datastromen door bestanden en repositories heen — en heeft geen enkel cijfer gepubliceerd dat laat zien hoe goed het werkt. Dat is geen reden om het product af te wijzen. Het is een reden om het te draaien tegen een repository waarvan je de geschiedenis al kent, en om het te beoordelen op de bevindingen die je kunt verifiëren in plaats van de bevindingen die indrukwekkend lijken in een demonstratie.