Sikkerhedsgennemgang i Claude Code: trinvis guide og automatisering med GitHub Action i 2026

Forfatteren til det oprindelige materiale beskriver sin erfaring: “Jeg kørte lige security-review på mit eget vibe-projekt, og teamet fandt flere reelle problemer på 4 minutter, som allerede er blevet rettet.” Det er det samme arbejde, der tidligere tog en ekstern konsulent en dag.

Yderligere materiale om konfiguration af værktøjer findes i Ailoot-dokumentationen.

Hvad er /security-review i Claude Code?#

Kommandoen fungerer i to tilstande. Lokalt: kør /security-review i terminalen, så læser Claude repositoryet og udarbejder en rapport. På serversiden: den samme motor installeres som en GitHub Action og kommenterer automatisk direkte på hver Pull Request.

I modsætning til klassiske SAST-scannere (Snyk Code, Semgrep, SonarQube) arbejder /security-review ikke ud fra faste regler. Den læser kode som en levende ingeniør: følger dataflowet, forstår hvilket framework du bruger, og hvor tillidsgrænserne går, og finder sårbarheder, som en regel ikke beskriver.

Det betyder ikke, at /security-review erstatter en ekstern pentest eller live-test i et stagingmiljø. Det kan automatisere en del af den indledende kodegennemgang, men artiklen måler ikke nogen andel af auditdækningen. Nedenfor forklarer jeg, hvordan du kører den korrekt, og hvad Claude finder i dit projekt.

Hvordan kører du /security-review i 5 trin?#

Trin 1. Opdater Claude Code. Kommandoen fungerer fra og med udgivelsen dateret 20. februar 2026.

claude update

Hvis du installerede Claude Code via npm, kan du også gøre dette:

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

Kontrollér, at /security-review er dukket op:

claude /help | grep security

Trin 2. Åbn projektet, og log ind på Claude Code.

cd ~/projects/my-vibe-project
claude

Trin 3. Kør kommandoen. Skriv blot følgende i Claude Code:

/security-review

Claude gennemgår automatisk 3 analysefaser:

1. Undersøgelse af repositoryets kontekst - læser strukturen og identificerer teknologistakken, routes og databaseforespørgsler.
2. Sammenlignende analyse - sammenligner den aktuelle tilstand med typiske sårbarhedsmønstre for denne teknologistak.
3. Sårbarhedsvurdering - oplister hver mistanke med et konfidensniveau på en skala fra 1-10. Kun fund med konfidens ≥ 8 medtages i rapporten.

Trin 4. Læs rapporten. Outputformatet er en markdown-tabel. For hvert problem angiver Claude:

• Fil og linjenummer (for eksempel src/auth/login.ts:42)
• Alvorlighedsgrad (HIGH / MEDIUM / LOW)
• Kategori (sql_injection, xss, auth_bypass, insecure_storage)
• Beskrivelse - hvad der er galt
• Udnyttelsesscenarie - hvordan en angriber kunne udnytte det
• Anbefaling - hvordan det kan løses

Trin 5. Bed den anvende rettelserne. Derefter kan du arbejde med den som med en almindelig agent:

“Anvend rettelserne med alvorlighedsgraden HIGH fra rapporten, én ad gangen, med en PR-beskrivelse.”

Claude åbner hver fil og foreslår en ændring; du bekræfter den. I et rigtigt projekt lukkede jeg 5 fund på 40 minutter i stedet for de planlagte 3 timer.

Hvilke sårbarheder finder /security-review?#

Den fulde liste over, hvad der som standard indgår i analysen, er beskrevet i Anthropics officielle dokumentation:

Derudover dækker kommandoen kategorier, som automatiserede scannere sjældent dækker:

• Kommandoinjektion - udførelse af brugerinput i en shell (child_process.exec(userInput))
• Stigennemgang - indlæsning af en fil via ../../etc/passwd
• XXE - XML med eksterne entiteter
• Skabeloninjektion - SSTI i Jinja/Handlebars/EJS
• NoSQL-injektion - operatorerne $ne, $gt i MongoDB-forespørgsler
• Forkert brug af kryptografi - brug af MD5, ECB-tilstand, en statisk IV

Claude angiver en alvorlighedsgrad for hvert fund. Skalaen er enkel:

• HIGH - fjernudnyttelse uden autentificering, datalæk, der påvirker alle brugere
• MEDIUM - udnyttelse med yderligere betingelser (en session er påkrævet / et specifikt input)
• LOW - en potentiel angrebsvektor, ikke kritisk nu, men værd at rette

Godt at vide: I standardkonfigurationen rapporterer Claude ikke DoS, rate limiting, hukommelsesudtømning, åbne redirects uden dokumenteret påvirkning, regex-injektion / ReDoS eller logforfalskning. Det er tilsigtet, så du ikke bliver oversvømmet med støj. Hvis disse klasser er vigtige, kan du udvide reglerne (se afsnittet om filtrering af falske positiver nedenfor).

Hvordan opsætter du en GitHub Action til automatisk gennemgang?#

Trin 1. Få en API-nøgle. Gå til console.anthropic.com, opret en API-nøgle, og kopiér den.

Trin 2. Læg nøglen i repositoryets secrets. I GitHub: Settings → Secrets and variables → Actions → New repository secret. Kald den CLAUDE_API_KEY; værdien er din nøgle.

Trin 3. Opret en workflow-fil. Gem 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 }}

Trin 4. Flet branchen sammen med main. Actionen starter automatisk med den næste PR.

Hvad actionen gør:

• Kører på hver åben / synkroniseret Pull Request.
• Tager diffen mellem PR-branchen og main.
• Kører den samme motor som lokal /security-review.
• Slår inline-kommentarer op direkte på kodelinjer med en mistanke.
• Gentager hele rapporten i Job Summary.

Vigtige detaljer i permissions:

• pull-requests: write - til at slå inline-kommentarer op.
• contents: read - til at læse kode. Ingen write. Actionen ændrer ikke selv kode; den rapporterer kun.

Dette rettighedssæt er tilstrækkeligt til et privat repository. For et offentligt repository kan du også angive actions: read, hvis du bruger genanvendelige workflows.

Hvordan filtrerer du falske positiver og ændrer følsomheden?#

Fuld tabel over GitHub Action-input (kilde: repositoryets README):

Eksempel på konfiguration af filtrering af falske positiver. Opret filen .claude/security/false-positives.md:

# False positive filtering rules for our project

- Any `dangerouslySetInnerHTML` inside `src/lib/email/layout.ts` is safe -
  the HTML is assembled from trusted templates and passes through `sanitize-html`
  at database write time, not at render time.
- Do not report hardcoded test API keys in `__tests__/fixtures/*.ts`.
  All keys start with `sk-test-fake-`.
- SQL concatenation in `src/lib/admin/migrations.ts` is acceptable - the file runs
  only as root, and input data comes from environment variables.

Forbind den 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 instruktioner til sikkerhedsscanning fungerer på samme måde. Opret en fil med regler, der er særligt vigtige for dit projekt:

# Additional checks for our project

- Any endpoint under `/api/admin/*` must check the administrator role
  through a shared wrapper. Without this wrapper, it is HIGH severity.
- All YooKassa / CloudPayments webhooks must verify the signature before
  parsing the body. Without this, it is HIGH severity.
- Magic-link tokens must be single-use (marked as used after
  the first valid request). Reusable tokens are MEDIUM severity.

Dette er ikke længere en Anthropic-forudindstilling: du overfører din viden om projektet til regler, som Claude anvender hver gang. Det er essensen af “metode frem for model”.

Læs mere om kontekstmetodik for Claude i vejledningerne “Sådan konfigurerer du CLAUDE.md” og “Second Brain i Claude Code”.

Hvad fanger Claude IKKE, og hvorfor: ærlige begrænsninger?#

Anthropic oplister tydeligt, hvad der er deaktiveret som standard og hvorfor (kilde: repositoryets README):

• Denial of Service - for meget støj, næsten altid lav påvirkning.
• Bekymringer om rate limiting - håndteres på infrastrukturniveau, ikke i kode.
• Hukommelses- / CPU-udtømning - samme begrundelse.
• Generisk inputvalidering uden dokumenteret påvirkning - validering af hvert felt skaber en lavine af falske positiver.
• Åben redirect - ofte tilsigtet adfærd.

Hvad kodegennemgang alene ikke fuldt kan verificere uden runtime- eller udrulningsevidens:

• Produktionsserverens konfiguration. NGINX-headere, CORS-politikker, TLS-indstillinger, lyttende porte. Disse skal kontrolleres manuelt i et stagingmiljø.
• Race conditions. For eksempel dobbeltforbrug ved samtidige anmodninger om tilbagebetaling. Statisk analyse kan påpege mistænkelige mønstre, men samtidig adfærd kræver stadig test.
• Fejl i betalingsforretningslogik. Hvis ordrebeløbet beregnes på klienten og blot sendes til betalingsudbyderen, er det alvorlighedsgrad HIGH, men Claude ser ikke altid dette mønster uden tydelig kontekst om, hvordan betalingen skal fungere.
• IDOR på databaseniveau. Hvis forespørgslen SELECT * FROM orders WHERE id = $1 ikke kontrollerer WHERE user_id = $session.userId, opdager Claude det ofte. Men hvis kontrollen udføres via ORM-middleware, og Claude ikke kan se hele dataflowet, kan den overse det.
• Modstandsdygtighed over for social engineering / phishing. Det har intet med kode at gøre.

Brug /security-review som en indledende statisk gennemgang. Følg op med dynamiske tests i staging, rolle- og tilladelseskontroller, relevante SAST-kontroller og gennemgang af den faktiske udrullede konfiguration. Ingen målt dækningsprocent dokumenteres her.

Fastlæg omfang og tidspunkt for en ekstern vurdering efter systemets risici og ændringer. Hverken én kommando eller en periodisk ekstern audit dokumenterer 100% sikkerhedsdækning.

Hvordan forfatteren til det oprindelige materiale kørte en sikkerhedsgennemgang af et vibe-projekt#

Hvad dukkede op? Et typisk billede af et gennemsnitligt vibe-projekt på stadiet “fungerer i produktion, men er ikke blevet gennemgået”: flere mistanker omkring auth-flowet, logikken til behandling af webhooks fra betalingsintegrationen, håndtering af filupload og et par specifikke bemærkninger om HTML-håndtering ved rendering. Jeg beskriver ikke detaljerne offentligt; nogle anbefalinger er allerede blevet implementeret, og andre er stadig i PR. I dette rapporterede projekt var den indledende scanning nyttig og hurtig; den dokumenterer ikke en auditdækningsprocent eller en generel gennemførelsestid.

Det, jeg afviste som falske positiver:

• Fund om DoS via regexer i inputvalidering - den reelle belastning falder ikke på disse regexer.
• Ét fund om en hardkodet API-nøgle - det var en testnøgle med et eksplicit fake--præfiks i fixtures.

Hvor lang tid tog det? Selve kørslen tog 4 minutter. Gennemgangen af rapporten tog 25 minutter. Det tog omkring en time at anvende rettelserne med tests. I alt: omkring halvanden time fra “startede” til “alt er i main”. En ekstern pentest af samme overflade tager en kalenderuge og koster mange gange mere.

Vigtigste pointe. /security-review erstatter ikke en ekstern pentest. Den kan identificere nyttige kodefund, som i forfatterens rapporterede scanning på fire minutter. Gennemgå og test rettelserne, og kontrollér derefter runtimeadfærd og udrullet konfiguration særskilt; scanningen fjerner ikke projektets sikkerhedsrisiko.

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

Den tidligere viste hook med git_commit, --severity HIGH og --fail-on-find er ikke en dokumenteret fungerende opskrift og må ikke bruges som sikkerhedsgate. Artiklen leverer ingen verificeret lokal hook, der blokerer commits. Den officielle GitHub Action ovenfor giver automatiske PR-fund; udled ikke, at den blokerer commits eller sammenfletninger, blot fordi den kommenterer på en PR.

En fuld forklaring af hooks findes i vejledningen “Hooks i Claude Code”.

Et alternativ med rutiner er at oprette en pre-deploy-check-rutine, der kører /security-review + npm run build + npm run test med én kommando. Yderligere materiale findes i Ailoot-dokumentationen.

Hvis du bruger MCP-servere, kan du integrere fund fra /security-review med et hændelsessystem (Sentry, Linear, Notion), så hvert HIGH automatisk bliver til en ticket.

FAQ om /security-review#

Hvad koster én kørsel? Det afhænger af projektets størrelse. På mine 30K linjer bruger én kørsel omkring $0.30-0.50 af API-saldoen. Et stort enterprise-repository med en million linjer koster op til $5-8 pr. kørsel. Det er mange gange billigere end et abonnement på en SaaS-scanner.

Hvor ofte bør jeg køre det lokalt? Som minimum før hver produktionsrelease. Overvej den også før væsentlige commits og PR’er. Artiklen leverer ingen verificeret automatisk hook, der blokerer commits.

Hvilke teknologistakke fungerer det med? Alle, som Claude kan læse. Ifølge forfatterens observationer er følgende blevet kontrolleret: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Kvaliteten er lavere med meget eksotiske sprog (Erlang, Elixir, Clojure), men den finder noget.

Hvad skal jeg gøre, hvis Claude finder den samme “sårbarhed” hver gang, selvom det faktisk ikke er en sårbarhed? Føj den til false-positive-filtering-instructions med en forklaring af “hvorfor dette er sikkert”. Claude holder op med at rapportere den i fremtidige kørsler.

Kan jeg køre det kun på bestemte filer? Lokalt, ja: kør blot /security-review src/lib/auth/*.ts. I GitHub Action kontrolleres kun den aktuelle PR-diff, hvilket som regel er det, “bestemte filer” betyder.

Kilder#

Yderligere materiale findes i Ailoot-dokumentationen.