Claude Code Security scant codebases op 'complexe kwetsbaarheden'

Claude Code kan voortaan codebases scannen op kwetsbaarheden. De webdienst zoekt dan niet alleen naar de aanwezigheid van tokens of bekende bugs, maar analyseert de code en maakt zelf inschattingen. Gebruikers kunnen vervolgens een pullrequest doen om voorgestelde verbeteringen te mergen.

Anthropic noemt de dienst Claude Code Security. Dat is een manier voor de webdienst om codebases te scannen en suggesties te doen om de beveiliging te verbeteren. Dat werkt anders dan hoe security- en pentests nu vaak werken, waarbij onderzoekers een codebase scannen op een vaste lijst met bekende bugs of kwetsbaarheden. In zo'n geval zoekt een tool bijvoorbeeld naar de aanwezigheid van tokens of wachtwoorden die hardcoded zijn opgenomen of naar verouderde versleutelingsprotocollen, maar volgens Anthropic worden daarmee 'complexe kwetsbaarheden, zoals gebrekkig toegangsbeheer,' vaak over het hoofd gezien.

Niet geheel verrassend zegt Anthropic dat Claude precies die fouten kan vinden. "Claude Code Security leest en redeneert over je code op een manier zoals een menselijke securityonderzoeker dat zou doen: door te begrijpen hoe componenten samenwerken, te bekijken hoe data door een app loopt en complexe kwetsbaarheden te vinden die regelgebaseerde tools missen."

Pullrequests

Claude Code Security controleert ieder resultaat om dat te verifiëren of juist te ontkrachten en zo valse positieven tegen te gaan. Claude geeft suggesties voor verbeteringen die ook een beoordeling krijgen van hoe ernstig de kwetsbaarheid is. Als de bevindingen kloppen, kunnen ze als een pullrequest richting het beveiligingsteam worden gestuurd. Die kunnen dat dan zelf weer controleren en bij akkoord mergen.

De tool werkt door GitHub-repo's te koppelen en Claude daar toegang toe te geven. Anthropic erkent ook dat aanvallers dergelijke tools kunnen inzetten om kwetsbaarheden in software te vinden, maar het bedrijf zegt dat Claude Code Security 'die macht terug in handen van verdedigers moet leggen door code te beschermen tegen nieuwe vormen van AI-gedreven aanvallen', zonder duidelijk toe te lichten wat het daarmee bedoelt. De tool is beschikbaar als 'beperkte onderzoekspreview' voor Enterprise- en Team-klanten. Maintainers van opensourcerepo's krijgen eerder toegang, zegt Anthropic.

Reacties (24)

[djwice]

Om zelf iets vergelijkbaars lokaal op te zetten met een taalmodel naar keuze, lees hier hoe je de omgeving kunt opzetten:
https://red.anthropic.com/2026/zero-days/

Op dit moment is qwen3-coder-next een sterk codering model, maar wellicht is een model dat vooral goed tools aan kan sturen en redeneren voor dit doel nog sterker. Denk bijvoorbeeld aan Foundation-Sec-8B-Reasoning van Cisco Foundation AI.


Uiteraard kun je ook gewoon een Anthopic API gebruiken via een provider naar keuze.

[Reactie gewijzigd door djwice op 23 februari 2026 08:53]

[Jerie]

Uiteraard kun je ook gewoon een Anthopic API gebruiken via een provider naar keuze.

Ja, dat 'kan'.

Voor proprietary code zou ik het eerst even met management en legal bespreken.

Voor FOSS lijkt dat overkill, maar dan nog is de analyse die ze maken in bezit van Anthropic of de provider. De vraag is of je dat moet willen. Pentest rapportages blijven doorgaans ook privé.

[djwice]

Pen-tests worden ook ingezien door de externe pen-testers die je inhuurt en het platform dat ze gebruiken voor rapportage.

Maar helemaal mee eens: stem eerst af met de opdrachtgever welk AI model en welke AI hosting gebruikt wordt.

Maar goed, dat is eigenlijk altijd zo met elk software component toch?

In dit geval kun je - als je de hardware hebt - prima een lokaal model gebruiken in een geïsoleerde omgeving. Bijvoorbeeld een Kali Linux omgeving.

Pen-testen heb ik niet zo'n hoge pet van op overigens, ik vind meestal in een half uur dingen die de tester over het hoofd zag. Veel is tegenwoordig standaard werk uitgevoerd door mensen die niet altijd precies weten wat ze doen en waarom. Dus steeds meer kun je de requests van een pen-test gewoon 'opnemen' en generiek maken en later nog eens uitvoeren (in parallel in je pipeline).
En dat al je API's voorzien van stricte input en output validaties en de meeste aanvallen zullen afgeslagen zijn. Ga je dan ook nog naar een stateless design, met security best practices, dan is de aanvalsvector die rest vooral je processen.

[Reactie gewijzigd door djwice op 23 februari 2026 14:40]

[Jerie]

Ja, en daar zijn als het goed is duidelijke afspraken over gemaakt. In dit geval met Anthropic niet. Geen contract. Geen legal waiver.

Maar helemaal mee eens: stem eerst af met de opdrachtgever welk AI model en welke AI hosting gebruikt wordt.

Stem eerst af of je überhaupt (zelf) ML wilt gebruiken, of dat je het rapport liever door professionals zoals Fox-IT of Northwave wilt laten doen. Die kunnen intern ook best ML gebruiken, maar zij blijven dan verantwoordelijk voor het rapport. Hoe ze zaken vinden (handmatig, met tooltjes, met ML) maakt niet uit als het maar feitelijk klopt en de data niet bij derden komt.

Pen-testen heb ik niet zo'n hoge pet van op overigens, ik vind meestal in een half uur dingen die de tester over het hoofd zag. Veel is tegenwoordig standaard werk uitgevoerd door mensen die niet altijd precies weten wat ze doen en waarom.

Ik heb hier wel eens onderzoek over gelezen. Iemand had een omgeving opgezet met gaten erin, en heeft toen pentests uit laten voeren.

Wat blijkt: you pay peanuts, you get monkeys. Voor iets van 100 EUR had men een pentest die uitgevoerd was met een tooltje. Tja. De iets duurdere pentest was uitgebreider, en de duurste kostte duizenden EUR maar vond wel veel meer. Alles vinden, dat zal geen enkele pentester beweren. Je hebt hier ook diverse expertises in. Zo ken ik iemand die is kjndig met SQL injection, en als je bij het bedrijf waar hij werkt een pentest afneemt dan is hij degene die dat onderdeel van het rapport verzorgd. Men vindt ook altijd wel iets. Hoewel die tooltjes ook false positives hebben (zo ook bij die test van 100 EUR), en dat is nogal irritant gegeven bug bounties (zie curl).

Ik heb bij een organisatie gewerkt die een externe pentest (of eigenlijk: postmortem na datalek) uit lieten voeren. Uiteraard was dat rapport vertrouwelijk, en peperduur. 100k EUR. Maar dat bedrijf is m.i. dan ook overrated.

Ik zou in ieder geval aanraden een SIEM/XDR uit te rollen, zoals Wazuh. Zoiets heb je ook nodig voor o.a. ISO 27001. Ook een tip voor Odido...

[djwice]

Dit is niet een vervanging van de testen die je al doet. Dit is een toevoeging.

En zoals ik aangaf, je kunt ook een lokaal model van Cisco (geen onbekende in security land) gebruiken, als je klant dat goedkeurd.

Maar het is heel normaal dat een klant goedkeuring moet geven als je in hun omgeving bepaalde software of tools wil gebruiken. Of het nu een AI model is of wat anders.

Ik verwees in mijn reactie naar pen-testen van een gerenommeerde partij - ik.zal geen namen noemen - waar zeker geen pinda's voor werden betaald en die ook niet maar een paar dagen duurde.

[Reactie gewijzigd door djwice op 23 februari 2026 18:24]

[Jorah_Newstone]

Hmm weet niet wat ik hierover moet denken? Wat als hij bepaalde security lekken gaat hallucineren?
En wordt de code dan als training gebruikt?

[elmuerte]

En wordt de code dan als training gebruikt

Lees de voorwaarden. Als daar iets in staat over dat je input gebruikt wordt om de service te verbeteren, dan is het antwoord "ja". Verder zijn er natuurlijk altijd de "vanwege een technische fout ..." excuses die herhaaldelijk gebruikt word als men er achter komt dat iets wel degelijk gedaan is wat men zei dat niet zou gebeuren.

[lenwar]

Uiteindelijk blijft het de verantwoordelijkheid van de code-eigenaren om het te valideren, en daadwerkelijk toe te passen.

En of het als training gebruikt wordt, zal aan de voorwaarden liggen.

[barbarbar]

Je moet dit meer zien in de zin van een heel proces laten doorlopen en dan voorstellen laten doen voor verbeteringen. Stel je vraagt de AI om het login proces te doorlopen op alle manieren; dan krijg je een overzicht met alle verbeterpunten, of kwetsbaarheden. Daarin maak je zelf de keuze over wat je wel en niet implementeert of accepteert. Het hallucineren bij code is niet echt een probleem, als AI iets voorstelt wat niet werkt, dan merk je dat snel genoeg. En als die iets voorstelt waardoor de beveiliging juist minder wordt, accepteer je dat niet. Het is nog steeds aan de ontwikkelaar om alles na te lopen en te controleren. Hoewel AI best hele programma's kan opleveren inmiddels, is het nog niet op het punt dat zo'n programma dan ook logisch/gestructureerd in elkaar steekt of vrij is van bugs/fouten.

[ultimasnake]

Dan test je de kwetsbaarheid eerst zelf? als je het niet kan reproduceren zou het in theorie ook niet bestaan (vanuitgaande dat je weet hoe je het moet testen)

[Oon]

Heel leuke toepassing van Claude Code. Je kunt natuurljk ook zelf aan Claude vragen om dergelijke issues te zoeken maar dan moet je al gaan automatiseren dat dit per bestand wordt aangeroepen, dat zou hiermee dus niet nodig zijn?
Alleen jammer dat het nog in de webversie lijkt te zitten, dus niet op een lokale workspace kan draaien

[cornedor]

Ik hoop alleen niet dat dit een nog groter probleem wordt: nieuws: Curl stopt met bugbountyprogramma door 'AI-slop'

[Oon]

Mwah, dat kun je nu ook al prima automatiseren of op basis van issues doen.
Ik hoop vooral dat dit een mooie toevoeging gaat zijn bovenop een bestaande SAST pipeline

[Kees]

Het lijkt mij geen goed idee om het in een pipeline op te nemen. Als eerste omdat AI niet deterministisch is en je dus een job introduceert die soms slaagt en soms faalt. En als tweede omdat je het niet voor elke verandering wil draaien, zeker kleine commits wil je hier niet perse doorheen gooien.

Het is beter iets dat je ernaast wil draaien, een keer per dag of week.

Een development pipeline wil je snel en deterministisch hebben en alleen laten falen op fouten die je op dat moment introduceert. Daarom ben ik ook geen voorstander van bijvoorbeeld vulnerability scanning in de pipeline (maar juist ernaast; asynchroon) omdat je dan ook dingen krijgt als 'Ik heb net een 'dt'-spelfout gefixt maar ik mag niet deployen omdat trivy zegt dat er een (niet fixable) vulnerability zit in libexpat in de baseimage'

[Oon]

Daar ben ik het zeker mee eens, maar je kunt toch ook prima de ene pipeline een andere laten starten mbv pipeline triggers? Dan wordt wel voor iedere commit een pipeline gestart, het liefst alleen op code die is aangeraakt (of adhv code coverage als 'ook mogelijke impact' wordt aangemerkt), daar kun je ook prima niet-deterministische code review of zoiets als dit op toepassen.
Ook hier zijn de meningen erg over verdeeld, ik ben ook van het async draaien van pipelines en dan 1x per periode of voordat je een release gaat uitrollen nog een keer alle checks voor de hele codebase, maar als je op internet gaat zoeken naar een industriestandaard vind je meteen tientallen 'industriestandaarden'.

[Luchtbakker]

Alleen jammer dat het nog in de webversie lijkt te zitten, dus niet op een lokale workspace kan draaien

Wat ik doe (puur vanwege snelheid) is mijn github repo lokaal op mijn pc syncen met de github desktop app, vervolgens koppelen aan Claude desktop en vervolgens vragen naar kwetsbaarheden te zoeken. Deze fixt hij gewoon keurig of schrijft er een plan voor, waarna je het weer een sync pull request doet naar je repo.

Werkt echt prima.

[Oon]

Maar dat is niet hetzelfde als deze nieuwe feature. Claude Code verzuipt nogal snel in codebases van meer dan een handjevol bestanden, dan moet je 'm echt instrueren om eerst een lijst van alle bestanden te maken en dan voor ieder bestand (en evt. dependencies) een sub-agent laten opstarten.
Mijn ervaring is dat hij zelfs dan héél snel óf uit z'n context loopt óf gewoon heel veel mist

[barbarbar]

De integratie in visual studio van copilot snapt het wel als je een analyse vraagt van een bepaald proces. Laatst nog een hele flow laten nalopen van verschillende inlogmethodes, en dan volgt ie alles wat aangeroepen wordt. Overzichtje eruit met verbeteringen en aandachtspunten, die je zelf nog kunt nalopen. AI snapt bepaalde situaties toch niet zoals een mens dat wel snapt, maar het bespaard veel werk en er komen regelmatig dingen naar voren die niet zozeer échte fouten zijn, maar wel verbeterd/robuuster kunnen worden.

[Sebast1aan]

...Claude Code verzuipt nogal snel in codebases van meer dan een handjevol bestanden...

Dat klopt niet hoor. Ik werk meestal aan een repo of 6 tegelijk. Ik heb zelf een AI friendly doc standard gemaakt voor architecture, operational procedures, roadmap, etc.. Die standaard maakt automatisch een logic tree in yaml formaat van elke repo die Claude snel kan lezen. Daar een plugin van gemaakt en die zit dan weer in mijn global Claude config. Elke Claude sessie leest dat automatisch en dat scheelt heel veel tokens. Daarnaast heb ik een simple MCP server in elkaar geknutseld (ik noem die c2c, van claude 2 claude) die de verschillende Claude instances gebruiken om met elkaar te praten.

Nu, veel mensen doen zulke dingen en veel slimmer dan mij, kijk op de Claude subreddit. Daar zijn ook ton van tips en tools voor token management. Ik gebruik Claude nu zeker 10+ uur per dag en ik blijf tegenwoordig makkelijk binnen mijn token limieten.

[Reactie gewijzigd door Sebast1aan op 23 februari 2026 13:33]

[Luchtbakker]

Maar dat is niet hetzelfde als deze nieuwe feature. Claude Code verzuipt nogal snel in codebases van meer dan een handjevol bestanden,

Dat is absoluut niet mijn ervaring als je Opus gebruikt. Sonnet heeft dit wel een stuk sneller, maar Opus kan heel goed omgaan met grote hoeveelheid bestanden. Mijn grootste project bestaat inmiddels uit zo'n +500 files en ruim 4-500.000 regels code (volgens mij wel meer) en hij heeft geen enkele moeite logische verbanden te zoeken bij bugs. Je moet hem alleen wel vertellen er de tijd voor te nemen hoe hij het voor je moet bouwen.

[Reactie gewijzigd door Luchtbakker op 23 februari 2026 12:39]

[Arator]

Ik heb Claude daarstraks toch nog een opdracht gegeven om in python project van mij met 32 schermen en dialogen een dark mode te plaatsen. Nu had ik wel een gecentraliseerd thema langs waar dit kon lopen, maar alle schermen en dialogen zijn wel aangepast. Maar elk scherm en dialoog werd wel nagekeken of er geen hardcoded kleuren achterbleven.

[Morrowind3]

Anthropic erkent ook dat aanvallers dergelijke tools kunnen inzetten om kwetsbaarheden in software te vinden, maar het bedrijf zegt dat Claude Code Security 'die macht terug in handen van verdedigers moet leggen door code te beschermen tegen nieuwe vormen van AI-gedreven aanvallen', zonder duidelijk toe te lichten wat het daarmee bedoelt.

Beter lekken vinden dan hopen dat ze niet gevonden worden is geen nieuw principe, maar een indirecte manier hoe dit cybersecurity kan verzwakken is dat bedrijven uit gemakzucht Claude laten draaien en het daarbij houden. Dat zie je vaker bij AI, handig zolang je zelf maar scherp blijft, maar als een ander het meeste werk al gedaan heeft is het heel makkelijk om te zeggen "Goed genoeg" waardoor in de praktijk vaak toch de kantjes eraf gelopen worden.

[SuperGuest]

Je kunt helaas verwachten dat er vanuit andere instanties gewerkt wordt aan trainen op het ontwikkelen van exploits.

[banaj]

Nice! Dan heeft de Amerikaanse overheid een extra kanaal om bij je broncode te komen (naast github, cloudboeren etc.). En ze hoeven er niets voor te doen, de aapjes komen hun broncode vrijwillig brengen