Anthropic heeft de Claude Security-plugin voor Claude Code in bèta geïntroduceerd. Claude Code is Anthropic's terminalgebaseerde agentische codeerassistent, en de plugin breidt deze uit naar beveiligingsanalyse, een terrein dat traditioneel wordt bediend door gespecialiseerde tools voor static application security testing (SAST). De plugin voert rechtstreeks binnen een bestaande Claude Code-sessie een multi-agent kwetsbaarheidsscan van een repository uit en zet geselecteerde bevindingen om in patchbestanden die de gebruiker handmatig beoordeelt en toepast. Anthropic benadrukte bij de lancering de flexibiliteit van de tool en merkte op dat deze zowel een uitgebreide scan van een volledige codebase kan uitvoeren als wijzigingen vanuit de terminal kan inspecteren vlak vóór een commit.

Wat de plugin toevoegt

De plugin introduceert één opdracht, /claude-security, die volgens de officiële documentatie een menu met drie taken toont:

• Codebase scannen — de volledige repository of een afgebakend deel daarvan
• Wijzigingen scannen — de diff van een branch, de diff van een pull request of een individuele commit
• Patches voorstellen — bevindingen uit een rapport omzetten in .patch-bestanden

Installatie vereist twee opdrachten uit de officiële Anthropic-marketplace. Als de marketplace niet wordt gevonden, voer dan eerst /plugin marketplace add anthropics/claude-plugins-official uit. De broncode van de plugin is openbaar beschikbaar in de claude-plugins-official-repository, momenteel op versie 0.10.0.

Hoe de scanpipeline is opgebouwd

De scan is geïmplementeerd als een dynamische workflow — een JavaScript-orkestratiescript dat werk over subagents verdeelt. Het script definieert zes fasen:

1. Inventory: verdeel de repository in componenten. Elke map op het hoogste niveau moet worden gescand of expliciet met een reden worden overgeslagen.
2. Threat model: één modelleur per component, die entry points, sinks, trust boundaries en bestanden oplevert die een onderzoeker volledig moet lezen.
3. Research: één onderzoeker per component × categoriecel.
4. Sweep: hiaten opvullen in gebieden die de matrix niet heeft afgedekt.
5. Panel: adversariële verificatie via drie lenzen, met één stemmer per lens.
6. Adversarial (alleen bij maximale inspanning): marginale te behouden bevindingen opnieuw aan een panel voorleggen en daarna elke overblijver red-teamen.

Het onderzoek werkt met vier vaste categorieën: injection-and-input, auth-and-access, memory-and-unsafe en crypto-and-secrets. De lens memory-and-unsafe wordt weggelaten voor componenten die volledig zijn geschreven in geheugenveilige talen, wat betekent dat een pure Python- of TypeScript-component drie lenzen krijgt in plaats van vier.

De operationele schaal van een run wordt bepaald door vier afzonderlijke inspanningsniveaus: low, medium, high en max. Afhankelijk van het gekozen niveau worden specifieke drempels afgedwongen: het maximumaantal componenten is begrensd op 12 voor de niveaus low en medium en wordt uitgebreid naar 24 voor high en max; matrixcellen krijgen op lagere niveaus 1 onderzoeker toegewezen, oplopend naar 2 op de niveaus high en max; en het aantal gap-fill sweeps schaalt van 0 bij low naar 1 bij medium en tot 2 bij high en max. Bij een beperkte scope of een kleine diff wordt het proces teruggebracht tot een configuratie met één onderzoeker in plaats van de volledige matrix in te zetten. Dit zorgt ervoor dat de evaluatie strikt in verhouding blijft tot het doel, terwijl dezelfde verificatiestandaard behouden blijft.

Het systeem gebruikt agents per modelniveau: de orchestrator draait op Opus, terwijl de repository-cartograaf en de read-only codeverkenner op Sonnet draaien. Het sessiemodel wordt overgenomen door onderzoekers en verificateurs, en scanagents zijn uitsluitend beperkt tot read-only tools.

Hoe een bevinding een plek in het rapport verdient

False positives vormen al lange tijd een hardnekkige uitdaging bij geautomatiseerde kwetsbaarheidsdetectie, waardoor beveiligingsteams vaak ruisrijke rapporten moeten triëren. De architectuur van de plugin pakt dit aan door te vereisen dat een kandidaatbevinding niet in het rapport komt alleen omdat een onderzoeker deze heeft geïdentificeerd. De bevinding wordt pas opgenomen nadat deze een panel heeft doorstaan.

Elke kandidaat wordt beoordeeld door drie onafhankelijke verificateurs, één per lens: REACHABILITY, IMPACT en DEFENSES. Elke verificateur retourneert een gestructureerd oordeel van TRUE_POSITIVE of FALSE_POSITIVE met één of twee regels waarin het doorslaggevende bestand:regel wordt genoemd. Het quorum om een bevinding te behouden is 2 van 3. Als minder dan drie stemmers reageren, kan de kandidaat helemaal niet worden behouden.

Het panelresultaat begrenst ook de gerapporteerde confidence van de bevinding. Een unaniem 3/3-panel staat een confidence-plafond van high toe; een 2/3-quorum begrenst dit op medium. Een bevinding kan niet meer confidence claimen dan de verificatie heeft verdiend.

Cruciaal is dat de telling in Python wordt berekend door de rapportrenderer en niet wordt beweerd door het model dat de bevindingen heeft geproduceerd. De verification.status van de revisiestempel wordt alleen op verified gezet wanneer het stemrecord aantoont dat het panel voor elke bevinding in het rapport is uitgevoerd; anders wordt deze gemarkeerd als unverified, met een opgegeven reden. Daardoor is de eigen weergave van de zorgvuldigheid van het rapport iets dat kan worden gecontroleerd, in plaats van iets dat op vertrouwen moet worden aangenomen.

Wat een scan naar schijf schrijft

Elke scan maakt binnen de repository een van een tijdstempel voorziene map CLAUDE-SECURITY-<timestamp>/ aan met drie artefacten:

• CLAUDE-SECURITY-RESULTS.md — het voor mensen leesbare rapport. Elke bevinding bevat een ID zoals F1, plus severity (HIGH/MEDIUM/LOW), confidence, CWE ID, de exacte sink-regel, impact, exploit-scenario, preconditions en een recommendation. Het gebruik van CWE-identifiers (Common Weakness Enumeration) brengt bevindingen in lijn met de breed gebruikte MITRE-classificatiestandaard, waardoor resultaten interoperabel zijn met bestaande workflows voor kwetsbaarheidstracking en remediatie.
• CLAUDE-SECURITY-RESULTS.jsonl — dezelfde bevindingen, één JSON-object per regel.
• CLAUDE-SECURITY-REVISION-.json — de revisiestempel: welke commit is gescand, met welk inspanningsniveau, de aantallen per severity en hoe grondig de run is geverifieerd. De bestandsnaam bevat -dirty wanneer niet-gecommitte wijzigingen deel uitmaakten van de gescande tree.

Die map is de enige wijziging die een scan aan de checkout aanbrengt, en wordt geleverd met een eigen .gitignore zodat een onbedoelde git add geen rapport in een commit kan meenemen. Door die .gitignore te verwijderen, kan het rapport worden gecommit voor een audit trail.

Patches en de drie claims die elke patch moet verdienen

De fix-taak ontwikkelt elke patch in een scratch clone van de repository, zodat de working tree en index nooit worden aangeraakt. Een agent die onafhankelijk is van de agent die de patch heeft geschreven, beoordeelt vervolgens de staged diff en voert de eigen testsuite van het project uit tegen de wijziging.

Een patchbestand wordt alleen geschreven als de verificateur alle drie de volgende punten met vertrouwen kan bevestigen: de wijziging verhelpt die specifieke bevinding, introduceert geen nieuwe kwetsbaarheid en laat het gedrag verder ongewijzigd — waarbij een wijziging in welke inputs de code accepteert telt als een gedragswijziging. Elke aanpassing die de beveiliging verzwakt terwijl deze beweert de kwestie te verhelpen, zoals een versoepelde authenticatiecontrole of een uitgeschakelde test, wordt automatisch afgewezen. Wanneer de verificateur niet voor alle drie de criteria kan instaan, wordt in plaats van een patch een korte toelichting gegeven waarom dat niet kan.

Patches worden geplaatst in de map patches/ van het rapport als F<n>.patch. Niets wordt automatisch toegepast. De patchnotitie geeft expliciet aan wanneer geen repositorytest de gewijzigde code dekt, waarmee wordt verduidelijkt dat de verificatie dan op code review berust in plaats van op testuitvoering. Anthropic raadt aan elke patch via een afzonderlijk pull request toe te passen.

Vereisten, kosten en het vertrouwensmodel

De plugin vereist een betaald abonnement met Claude Code v2.1.154 of later, met dynamische workflows ingeschakeld in /config. Daarnaast is Python 3.9.6 of later vereist op het systeem-PATH als python3 (waarbij alleen de standaardbibliotheek wordt gebruikt), evenals Git voor het scannen van wijzigingen en patching. Linux, macOS en Windows worden ondersteund, en scans tellen mee voor de tokenlimieten van het abonnement.

Omdat de scan in de sessie van de gebruiker onder diens rechten draait, voegt deze zelf geen isolatie toe. Dat betekent dat gecommitte .claude/-instellingen, hooks en CLAUDE.md nog steeds van toepassing zijn. Hoewel repository-inhoud als data wordt behandeld in plaats van als instructies, is dit geen verdediging tegen vijandige repositories; Anthropic adviseert sandbox-runtime te gebruiken om onbekende codebases in een sandbox te plaatsen.

Daarnaast zijn scans niet-deterministisch en vervangen ze geen traditionele statische analyse, dependency-scans of codebeoordelingen. De plugin komt terecht in een landschap met gevestigde tools zoals Semgrep, Snyk en SonarQube, maar onderscheidt zich door zijn multi-agent pipeline die semantische analyse van codepaden uitvoert in plaats van primair te vertrouwen op pattern-matchingregels. Als bètaproduct op versie 0.10.0 kunnen scope, nauwkeurigheid en functieset zich nog ontwikkelen.

Bronnen: documentatie van de Claude Security-plugin, Claude Security-productpagina, Pluginbron, claude-plugins-official, @claudeai-aankondiging en Claude Security public beta-blog