Så använder du Claude Code i sårbarhetsarbete utan att tappa mänsklig kontroll

Efter guiden kan du sätta upp ett enkelt och spårbart arbetsflöde där en kodagent hjälper till att hitta och föreslå fixar för sårbarheter utan att den får fria händer i produktion.

Målgrupp: utvecklare, AppSec-team och teknikchefer i reglerade eller säkerhetskänsliga miljöer.

Förkunskaper: du bör kunna läsa pull requests, köra tester och förstå skillnaden mellan en sårbarhetsrapport och en faktisk kodändring.

Du behöver

• Ett kodrepo där du får göra säkerhetsgranskning.
• En kodagent, till exempel Claude Code, i en kontrollerad miljö.
• Testsvit eller åtminstone ett sätt att bygga projektet lokalt.
• En människa som godkänner fynd, patchar och utrullning.

Slutkontroll

Guiden fungerar när du har ett körbart flöde där agenten granskar avgränsad kod, lämnar spårbara fynd, föreslår patchar och varje ändring granskas av en människa innan merge.

> Obs: det här är en principguide. Den bygger på Anthropics officiella Alberta-case och är inte en copy-paste-mall för alla miljöer.

Steg 1: Avgränsa vad agenten får granska

Mål: ge agenten ett tydligt scope så att den inte blandar ihop hela plattformen med ett enda uppdrag.

Gör så här: välj en tjänst, ett repo eller en modul. Skriv också ned vilka beroenden, tester och miljöer som ingår.

Uppdrag: granska endast repo X
Ingår: src/, tests/, package manifests
Ingår inte: produktion, hemligheter, kunddata, deploy-nycklar
Utdata: lista över fynd med fil, risknivå och föreslagen åtgärd

Kontrollera att det fungerar: uppdraget går att läsa på under en minut och en kollega förstår exakt vad agenten får göra.

Vanligt fel: scope skrivs för brett. Börja mindre, annars får du svepande svar i stället för användbara fynd.

Steg 2: Kör en första granskningsrunda med tydlig utdata

Mål: få en första rapport som går att följa upp i stället för en lång fri text.

Gör så här: be agenten leta efter konkreta risktyper och returnera fynd i ett fast format.

Granska koden för:
- hårdkodade hemligheter
- osäkra beroenden
- bristande inputvalidering
- riskabel fil- eller nätverksåtkomst
- felaktig behörighetskontroll

Returnera varje fynd som:
1. fil
2. rad eller funktion
3. risk
4. varför det är ett problem
5. minsta möjliga fix

Kontrollera att det fungerar: rapporten innehåller separata fynd som går att skapa tickets eller PR-kommentarer från.

Vanligt fel: agenten ombeds "säkra appen". Det ger för diffusa resultat. Fråga alltid efter fynd med struktur.

Steg 3: Låt agenten föreslå patchar men inte godkänna dem

Mål: använda agenten som snabb fixerare utan att förvandla den till ensam beslutsfattare.

Gör så här: låt agenten skriva en minimal patch för ett fynd i taget och kräva att ändringen förklaras.

Skapa en minimal patch för fynd #1.
Krav:
- ändra så lite kod som möjligt
- förklara varför patchen minskar risken
- lista vilka tester som bör köras
- gör ingen merge eller deploy

Kontrollera att det fungerar: du får en begränsad diff eller patchplan som går att granska manuellt.

Vanligt fel: flera sårbarheter fixas i samma ändring. Dela upp patcharna så att rollback och granskning blir enklare.

Steg 4: Verifiera varje patch med tester och mänsklig granskning

Mål: se att fixen faktiskt löser problemet utan att skapa nya fel.

Gör så här: kör relevanta tester, bygg projektet och låt en mänsklig granskare kontrollera både säkerhet och funktion.

Checklista före merge:
- reproducerades problemet eller riskmönstret?
- passerar testerna?
- ändrades behörighet, logik eller dataflöde oväntat?
- behöver fler skydd läggas till i pipeline eller CI?

Kontrollera att det fungerar: patchen klarar testerna och granskaren kan motivera varför ändringen är säker nog att slå ihop.

Vanligt fel: teamet nöjer sig med att agenten säger att en fix fungerar. Kör alltid egna tester eller byggsteg.

Steg 5: Bygg in återkommande agentkontroller i processen

Mål: göra granskningen repeterbar så att agenten hjälper till tidigt, inte bara efter incidenter.

Gör så här: definiera när agenten ska köras, till exempel före release, vid beroendeuppdateringar eller mot äldre system med teknisk skuld.

Kör agentgranskning när:
- ny tjänst tas över av teamet
- större refaktorering är klar
- beroenden uppdateras
- äldre system moderniseras
- inför release av säkerhetskänslig funktion

Kontrollera att det fungerar: du vet att det fungerar när teamet har en återkommande kontrollpunkt, ett standardpromptbibliotek och loggade beslut för varje större fynd.

Vanligt fel: agenten används bara ad hoc. Skriv in processen i teamets vanliga säkerhetsrutin.

Felsökning

Agenten hittar för mycket brus

Minska scope, be om färre risktyper åt gången och tvinga fram strukturerad utdata med fil och motivering.

Patchen ser rimlig ut men går inte att lita på

Kräv mindre diffar och kör tester innan någon merge. Om testsvit saknas: skapa manuell kontrollista för den aktuella modulen.

Teamet börjar övertro agentens säkerhetsbedömning

Påminn om att agenten är ett granskningsstöd. Mänsklig review, loggning och beslut om utrullning ska fortfarande ligga hos teamet.

Källa: Anthropic News – Government of Alberta uses Claude to find and fix cybersecurity vulnerabilities