Sikkerhetsgjennomgang i Claude Code: trinnvis veiledning og automatisering med GitHub Action i 2026

Forfatteren av originalmaterialet beskriver sin erfaring: «Jeg kjørte nettopp security-review på mitt eget vibe-prosjekt, og teamet fant flere reelle problemer på 4 minutter som allerede er rettet.» Dette er det samme arbeidet som tidligere tok en ekstern konsulent en dag.

Mer materiale om konfigurering av verktøy finnes i Ailoot-dokumentasjonen.

Hva er /security-review i Claude Code?#

Kommandoen fungerer i to moduser. Lokalt: kjør /security-review i terminalen, så leser Claude repositoriet og lager en rapport. På serversiden: den samme motoren installeres som en GitHub Action og legger automatisk inn kommentarer direkte i hver Pull Request.

I motsetning til klassiske SAST-skannere (Snyk Code, Semgrep, SonarQube) fungerer ikke /security-review ut fra faste regler. Den leser kode som en erfaren utvikler: følger dataflyten, forstår hvilket rammeverk du bruker og hvor tillitsgrensene går, og oppdager sårbarheter som ikke er beskrevet av en regel.

Det betyr ikke at /security-review erstatter en ekstern penetrasjonstest eller live-testing i et stagingmiljø. Den kan automatisere deler av den innledende kodegjennomgangen, men artikkelen måler ingen andel av revisjonsdekningen. Nedenfor forklarer jeg hvordan du kjører den riktig, og hva Claude vil finne i prosjektet ditt.

Hvordan kjører du /security-review i 5 trinn?#

Trinn 1. Oppdater Claude Code. Kommandoen fungerer fra og med utgivelsen datert 20. februar 2026.

claude update

Hvis du installerte Claude Code via npm, kan du også gjøre dette:

npm install -g @anthropic-ai/claude-code@latest

Kontroller at /security-review har dukket opp:

claude /help | grep security

Trinn 2. Åpne prosjektet og logg inn i Claude Code.

cd ~/projects/my-vibe-project
claude

Trinn 3. Kjør kommandoen. Skriv ganske enkelt inn dette i Claude Code:

/security-review

Claude går automatisk gjennom 3 analysefaser:

1. Undersøkelse av repository-kontekst - leser strukturen og identifiserer teknologistakken, rutene og databasespørringene.
2. Sammenlignende analyse - sammenligner den gjeldende tilstanden med typiske sårbarhetsmønstre for denne teknologistakken.
3. Vurdering av sårbarheter - lister opp hver mistanke med et konfidensnivå på en skala fra 1-10. Bare funn med konfidens ≥ 8 tas med i rapporten.

Trinn 4. Les rapporten. Utdataene er en Markdown-tabell. For hvert problem oppgir Claude:

• Fil og linjenummer (for eksempel src/auth/login.ts:42)
• Alvorlighetsgrad (HIGH / MEDIUM / LOW)
• Kategori (sql_injection, xss, auth_bypass, insecure_storage)
• Beskrivelse - hva som er galt
• Utnyttelsesscenario - hvordan en angriper kan utnytte det
• Anbefaling - hvordan det kan løses

Trinn 5. Be om at rettelsene brukes. Deretter kan du jobbe med den som med en vanlig agent:

«Bruk rettelsene med alvorlighetsgrad HIGH fra rapporten, én om gangen, med en PR-beskrivelse.»

Claude åpner hver fil og foreslår en endring; du bekrefter den. I et reelt prosjekt lukket jeg 5 funn på 40 minutter i stedet for de planlagte 3 timene.

Hvilke sårbarheter finner /security-review?#

Den fullstendige listen over hva som inngår i analysen som standard, er beskrevet i Anthropics offisielle dokumentasjon:

I tillegg dekker kommandoen kategorier som automatiserte skannere sjelden dekker:

• Kommandoinjeksjon - kjøring av brukerinndata i et shell (child_process.exec(userInput))
• Stikryssing - lasting av en fil via ../../etc/passwd
• XXE - XML med eksterne entiteter
• Malinjeksjon - SSTI i Jinja/Handlebars/EJS
• NoSQL-injeksjon - $ne- og $gt-operatorer i MongoDB-spørringer
• Feil bruk av kryptografi - bruk av MD5, ECB-modus eller en statisk IV

Claude gir hvert funn en alvorlighetsgrad. Skalaen er enkel:

• HIGH - fjernutnyttelse uten autentisering, datalekkasje som påvirker alle brukere
• MEDIUM - utnyttelse med tilleggsvilkår (en sesjon kreves / spesifikke inndata)
• LOW - en mulig angrepsvektor, ikke kritisk nå, men verdt å rette

Nyttig å vite: I standardkonfigurasjonen rapporterer ikke Claude DoS, hastighetsbegrensning, minneuttømming, åpne videresendinger uten påvist effekt, regex-injeksjon / ReDoS eller forfalskning av logger. Dette er tilsiktet, slik at du ikke oversvømmes av støy. Hvis disse kategoriene er viktige, kan du utvide reglene (se avsnittet om filtrering av falske positiver nedenfor).

Hvordan setter du opp en GitHub Action for automatisk gjennomgang?#

Trinn 1. Skaff en API-nøkkel. Gå til console.anthropic.com, opprett en API-nøkkel og kopier den.

Trinn 2. Legg nøkkelen i repository-hemmelighetene. I GitHub: Settings → Secrets and variables → Actions → New repository secret. Gi den navnet CLAUDE_API_KEY; verdien er nøkkelen din.

Trinn 3. Opprett en workflow-fil. Lagre den som .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Trinn 4. Slå sammen branchen med main. Actionen starter automatisk ved neste PR.

Dette gjør actionen:

• Kjører på hver åpen eller synkronisert Pull Request.
• Henter diffen mellom PR-branchen og main.
• Kjører samme motor som lokal /security-review.
• Legger inn kommentarer direkte på kodelinjene der det finnes mistanker.
• Kopierer hele rapporten til Job Summary.

Viktige detaljer i permissions:

• pull-requests: write - for å legge inn kommentarer direkte i koden.
• contents: read - for å lese kode. Ingen write. Actionen endrer ikke koden selv; den rapporterer bare.

Dette tillatelsessettet er tilstrekkelig for et privat repository. For et offentlig repository kan du også angi actions: read hvis du bruker gjenbrukbare workflows.

Hvordan filtrerer du falske positiver og endrer følsomheten?#

Fullstendig tabell over inndata for GitHub Action (kilde: repository-README):

Eksempel på konfigurering av filtrering av falske positiver. Opprett filen .claude/security/false-positives.md:

# Regler for filtrering av falske positiver i prosjektet vårt

- All `dangerouslySetInnerHTML` i `src/lib/email/layout.ts` er trygg -
  HTML-en settes sammen fra betrodde maler og går gjennom `sanitize-html`
  når den skrives til databasen, ikke når den gjengis.
- Ikke rapporter hardkodede test-API-nøkler i `__tests__/fixtures/*.ts`.
  Alle nøklene begynner med `sk-test-fake-`.
- Sammenkjeding av SQL i `src/lib/admin/migrations.ts` er akseptabel - filen kjøres
  bare som root, og inndataene kommer fra miljøvariabler.

Koble den til i workflowen:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

Tilpassede instruksjoner for sikkerhetsskanning er tilsvarende. Opprett en fil med regler som er spesielt viktige for prosjektet ditt:

# Ekstra kontroller for prosjektet vårt

- Alle endepunkter under `/api/admin/*` må kontrollere administratorrollen
  gjennom en delt wrapper. Uten denne wrapperen er alvorlighetsgraden HIGH.
- Alle YooKassa / CloudPayments-webhooks må kontrollere signaturen før
  brødteksten analyseres. Uten dette er alvorlighetsgraden HIGH.
- Magic-link-tokener må bare kunne brukes én gang (markeres som brukt etter
  den første gyldige forespørselen). Gjenbrukbare tokener har alvorlighetsgrad MEDIUM.

Dette er ikke lenger en Anthropic-forhåndsinnstilling: Du overfører ekspertisen din om prosjektet til regler som Claude bruker hver gang. Det er essensen av «metodikk over modell».

Hvis du vil vite mer om kontekstmetodikk for Claude, kan du lese veiledningene «Slik konfigurerer du CLAUDE.md» og «Second Brain i Claude Code».

Hva oppdager Claude IKKE, og hvorfor: ærlige begrensninger?#

Anthropic lister tydelig opp hva som er deaktivert som standard, og hvorfor (kilde: repository-README):

• Tjenestenektangrep (DoS) - for mye støy, nesten alltid liten påvirkning.
• Bekymringer rundt hastighetsbegrensning - håndteres på infrastrukturnivå, ikke i kode.
• Uttømming av minne / CPU - det samme.
• Generell validering av inndata uten påvist effekt - validering av hvert felt skaper et skred av falske positiver.
• Åpen videresending - ofte tilsiktet oppførsel.

Dette kan kodegjennomgang alene ikke fullt ut verifisere uten kjøretids- eller utrullingsbelegg:

• Konfigurasjon av produksjonsserveren. NGINX-headere, CORS-policyer, TLS-innstillinger, lytteporter. Disse må kontrolleres manuelt i et stagingmiljø.
• Kappløpsforhold. For eksempel dobbeltforbruk ved samtidige refusjonsforespørsler. Statisk analyse kan flagge mistenkelige mønstre, men samtidig atferd må fortsatt testes.
• Feil i betalingsforretningslogikk. Hvis ordrebeløpet beregnes på klientsiden og bare sendes videre til betalingsleverandøren, er det alvorlighetsgrad HIGH, men Claude oppdager ikke alltid dette mønsteret uten eksplisitt kontekst om hvordan betalingen skal fungere.
• IDOR på databasenivå. Hvis spørringen SELECT * FROM orders WHERE id = $1 ikke kontrollerer WHERE user_id = $session.userId, oppdager Claude det ofte. Men hvis kontrollen er implementert gjennom ORM-mellomvare og Claude ikke kan se hele dataflyten, kan den overse det.
• Motstandsdyktighet mot sosial manipulering / phishing. Dette har ingenting med kode å gjøre.

Bruk /security-review som innledende statisk gjennomgang. Følg opp med dynamiske tester i staging, rolle- og tillatelseskontroller, relevante SAST-kontroller og gjennomgang av faktisk utrullet konfigurasjon. Ingen målt dekningsprosent fastslås her.

Avgjør omfang og tidspunkt for ekstern vurdering ut fra systemets risikoer og endringer. Verken én kommando eller periodisk ekstern revisjon fastslår 100 % sikkerhetsdekning.

Hvordan forfatteren av originalmaterialet gjennomførte en sikkerhetsgjennomgang av et vibe-prosjekt#

Hva dukket opp? Et typisk bilde av et gjennomsnittlig vibe-prosjekt på stadiet «fungerer i produksjon, men er ikke gjennomgått»: flere mistanker om autentiseringsflyten, logikken for behandling av webhooks fra betalingsintegrasjonen, filopplasting og et par konkrete merknader om HTML-håndtering ved gjengivelse. Jeg beskriver ikke detaljene offentlig; noen anbefalinger er allerede fulgt, mens andre fortsatt ligger i en PR. I det rapporterte prosjektet var den innledende skanningen nyttig og rask. Det fastslår ingen revisjonsdekningsprosent eller generell fullføringstid.

Dette avviste jeg som falske positiver:

• Funn om DoS via regexer i validering av inndata - den faktiske belastningen treffer ikke disse regexene.
• Ett funn om en hardkodet API-nøkkel - det var en testnøkkel med et tydelig fake--prefiks i fixtures.

Hvor lang tid tok det? Selve kjøringen tok 4 minutter. Det tok 25 minutter å gå gjennom rapporten. Det tok omtrent en time å bruke rettelsene og kjøre testene. Totalt: omtrent halvannen time fra «startet» til «alt i main». En ekstern penetrasjonstest av samme område tar en kalenderuke og koster flere titalls ganger mer.

Viktigste poeng. /security-review erstatter ikke en ekstern penetrasjonstest. Den kan identifisere nyttige kodefunn, slik den gjorde i forfatterens rapporterte fireminutters skanning. Gjennomgå og test rettelsene, og kontroller deretter kjøretidsatferd og utrullet konfigurasjon separat. Skanningen fjerner ikke prosjektets sikkerhetsrisiko.

Hvordan integrerer du /security-review i pre-commit-rutinen?#

Den tidligere viste hooken med git_commit, --severity HIGH og --fail-on-find er ingen dokumentert fungerende oppskrift og må ikke brukes som sikkerhetsport. Artikkelen gir ingen verifisert lokal hook som blokkerer commits. Den offisielle GitHub Actionen ovenfor gir automatiserte PR-funn. Ikke utled at den blokkerer commits eller sammenslåing bare fordi den kommenterer en PR.

En fullstendig forklaring av hooks finnes i veiledningen «Hooks i Claude Code».

Et alternativ med rutiner er å opprette en pre-deploy-check-rutine som kjører /security-review + npm run build + npm run test med én kommando. Mer materiale finnes i Ailoot-dokumentasjonen.

Hvis du bruker MCP-servere, kan du integrere funn fra /security-review med et hendelsessystem (Sentry, Linear, Notion), slik at hvert funn med alvorlighetsgrad HIGH automatisk blir en sak.

Vanlige spørsmål om /security-review#

Hva koster én kjøring? Det avhenger av prosjektstørrelsen. På mine 30K linjer bruker én kjøring omtrent $0.30-0.50 av API-saldoen. Et stort bedriftsrepository med en million linjer koster opptil $5-8 per kjøring. Det er flere titalls ganger billigere enn et abonnement på en SaaS-skanner.

Hvor ofte bør jeg kjøre det lokalt? Minst før hver produksjonsutgivelse. Vurder den også før vesentlige commits og PR-er. Artikkelen gir ingen verifisert hook som automatisk blokkerer commits.

Hvilke teknologistakker fungerer det med? Alle som Claude kan lese. Ifølge forfatterens observasjoner er disse kontrollert: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Kvaliteten er lavere for svært eksotiske språk (Erlang, Elixir, Clojure), men den finner noe.

Hva skal jeg gjøre hvis Claude finner den samme «sårbarheten» hver gang, selv om den egentlig ikke er en sårbarhet? Legg den til i false-positive-filtering-instructions med en forklaring på «hvorfor dette er trygt». Claude vil slutte å rapportere den i senere kjøringer.

Kan jeg kjøre det bare på bestemte filer? Lokalt, ja: kjør ganske enkelt /security-review src/lib/auth/*.ts. I GitHub Action kontrolleres bare diffen for den gjeldende PR-en, noe som vanligvis er det som menes med «bestemte filer».

Kilder#

Mer materiale finnes i Ailoot-dokumentasjonen.