# Sikkerhedsgennemgang i Claude Code: trinvis guide og automatisering med GitHub Action i 2026 > Sådan tjekker du sikkerheden i et vibe-projekt med /security-review i Claude Code. Opsætningstrin, en GitHub Action-skabelon, 6 typer sårbarheder og ærlige begrænsninger. Source: https://ailoot.ai/blog/da/claude-code-security-review/ Canonical: https://ailoot.ai/blog/da/claude-code-security-review/ Language: da Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-3ed4863a13c089db03491144902ceb8d3d87ca354e31e39b782954594cdd6e3d 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](https://ailoot.ai/docs/).
[Ailoot-guides](https://ailoot.ai/docs/)
## Hvad er /security-review i Claude Code?
Det vigtigste `/security-review` er en indbygget Claude Code-kommando, der kører en sikkerhedsanalyse af hele projektet eller de aktuelle ændringer direkte fra terminalen. Anthropic lancerede den den 20. februar 2026 som en del af Claude Code Security og gjorde den tilgængelig for alle Pro-, Max- og API Console-brugere. Anmodningen betales fra din almindelige Claude API-saldo.
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.

Claude Code Security læser og ræsonnerer over din kode, som en menneskelig sikkerhedsforsker ville gøre: den forstår, hvordan komponenter interagerer, følger hvordan data bevæger sig gennem applikationen, og finder komplekse sårbarheder, som regelbaserede værktøjer overser.

— Anthropic, https://www.anthropic.com/news/claude-code-security
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?
Det vigtigste Opdater Claude Code til den nyeste version, åbn projektet i en terminal, kør `/security-review`, vent på rapporten (1 til 5 minutter for et gennemsnitligt projekt), læs alvorlighedsvurderingerne, og bed Claude anvende rettelserne. Kommandoen fungerer med enhver teknologistak: Next.js, Django, FastAPI, Rails, Go, Rust. Den kræver ingen særlig konfiguration.
**Trin 1. Opdater Claude Code.** Kommandoen fungerer fra og med udgivelsen dateret 20. februar 2026. ```bash claude update ``` Hvis du installerede Claude Code via npm, kan du også gøre dette: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Kontrollér, at `/security-review` er dukket op: ```bash claude /help | grep security ``` **Trin 2. Åbn projektet, og log ind på Claude Code.** ```bash 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.
[Ailoot-guides](https://ailoot.ai/docs/)
## Hvilke sårbarheder finder /security-review?
Det vigtigste Claude finder 6 klasser: SQL-injektion og injektioner generelt, XSS, problemer med autentificering og autorisation, læk af følsomme data, huller i tredjepartsafhængigheder og hardkodede hemmeligheder i kode. Kommandoen kan også arbejde med autentificeringslogik, der er fordelt på flere filer, hvilket regelbaserede scannere ikke kan.
Den fulde liste over, hvad der som standard indgår i analysen, er beskrevet i [Anthropics officielle dokumentation](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Kategori | Hvad den leder efter | |----|----| | **SQL-injektion** | Direkte strengsammenkædning i SQL, usikre ORM-kald (`raw()` uden parametre), Prisma `$queryRawUnsafe` | | **XSS** | Rendering med `dangerouslySetInnerHTML` uden sanitering, skabelonsystemer uden automatisk escaping, `innerHTML` fra brugerinput | | **Autentificeringsfejl** | Genbrugelige tokens, manglende tilladelseskontroller i API-routes, JWT uden udløbsdato, sessionsfiksering | | **Usikker datahåndtering** | Validering kun på klienten, svar med ekstra felter (over-fetching), åben redirect | | **Sårbarheder i afhængigheder** | Sårbare versioner af npm-/pip-/cargo-pakker, kontrolleret med `npm audit` og tilsvarende værktøjer | | **Hemmeligheder** | Hardkodede API-nøgler, tokens i `.env.example`, adgangskoder i kode | 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?
Det vigtigste Anthropic udgav den officielle action `anthropics/claude-code-security-review@main`. Den forbindes med én workflow-fil og kommenterer automatisk direkte på hver Pull Request med de sårbarheder, den finder. Konfigurér `CLAUDE_API_KEY` og workflowets tilladelser. Den officielle Action advarer om, at den ikke er hærdet mod promptinjektion og bør gennemgå betroede PR’er; gennemgå bidragyder- og workflowadgang før aktivering.
**Trin 1. Få en API-nøgle.** Gå til [console.anthropic.com](https://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`: ```yaml 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?
Det vigtigste Actionen har 9 input, som du kan bruge til at konfigurere dens adfærd for dit projekt. De vigtigste er: `exclude-directories` (for eksempel `tests/,fixtures/`), `false-positive-filtering-instructions` (sti til en md-fil med dine regler om “dette er ikke en sårbarhed, fordi...”) og `custom-security-scan-instructions` til yderligere domænespecifikke kontroller.
Fuld tabel over GitHub Action-input ([kilde: repositoryets README](https://github.com/anthropics/claude-code-security-review)): | Input | Standard | Hvad det gør | |----|----|----| | `claude-api-key` | \- | Anthropics API-nøgle. Påkrævet. | | `comment-pr` | `true` | Om der skal slås inline-kommentarer op i PR'en | | `upload-results` | `true` | Om resultatet skal gemmes som et artefakt i 90 dage | | `exclude-directories` | \- | Kommasepareret: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Hvilken model der skal bruges | | `claudecode-timeout` | `20` | Timeout i minutter | | `run-every-commit` | `false` | Kør ved hvert push, ikke kun ved PR'er | | `false-positive-filtering-instructions` | \- | Sti til en md-fil med dine regler | | `custom-security-scan-instructions` | \- | Sti til en md-fil med yderligere kontroller | **Eksempel på konfiguration af filtrering af falske positiver.** Opret filen `.claude/security/false-positives.md`: ```markdown # 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: ```yaml - 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: ```markdown # 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”](https://ailoot.ai/blog/da/claude-md-template/) og [“Second Brain i Claude Code”](https://ailoot.ai/blog/da/claude-code-second-brain/). ## Hvad fanger Claude IKKE, og hvorfor: ærlige begrænsninger?
Det vigtigste En kodegennemgang afprøver ikke i sig selv den kørende applikation eller verificerer dens udrullede miljø. Den kan påpege mulige race conditions, forretningslogikfejl eller konfigurationsproblemer i koden, men stagingtests og inspektion af den faktiske udrulning er nødvendige for at bekræfte adfærd og resterende risici.
Anthropic oplister tydeligt, hvad der er deaktiveret som standard og hvorfor ([kilde: repositoryets README](https://github.com/anthropics/claude-code-security-review)): - **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
Det vigtigste Jeg kørte `/security-review` på mit eget TypeScript-projekt med Next.js, Prisma, PostgreSQL og Redis. På 4 minutter gennemførte kommandoen en indledende audit, returnerede flere velunderbyggede fund af varierende alvorlighedsgrad, og jeg fik til sidst gennemført de fungerende rettelser på halvanden time. Det var billigere og hurtigere end enhver ekstern pentest.
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?
Det vigtigste Kør `/security-review` i projektsessionen før commit af væsentlige ændringer, læs fundene, ret bekræftede problemer, og gentag relevante tests. Det er en gennemgangsprocedure, ikke et teknisk forbud mod at committe.
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”](https://ailoot.ai/blog/da/claude-code-hooks/). Et alternativ med [rutiner](https://ailoot.ai/blog/da/claude-code-routines/) 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](https://ailoot.ai/blog/da/mcp-servers-claude-code/), 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
Det vigtigste 5 almindelige spørgsmål: hvad det koster, hvor ofte det skal køres, hvilke teknologistakke det fungerer med, hvad du skal gøre, hvis Claude allerede har fundet denne sårbarhed, og om du kan køre det kun på bestemte filer. Korte svar uden fyld.
**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
### Kilder - [Anthropic - lancering af Claude Code Security](https://www.anthropic.com/news/claude-code-security) - officiel meddelelse dateret 20. februar 2026 - [Anthropic Help Center - Automatiserede sikkerhedsgennemgange i Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - officielle instruktioner til at køre det - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - GitHub Action-kilde med den fulde README - [Claude Code Docs - Code Review](https://code.claude.com/docs/en/code-review) - generel Anthropic-dokumentation - [Anthropic Help Center - Use Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - relaterede produkter - [Port - Ingest Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integration af resultater i en intern udviklerportal - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - kommandoens udgivelseshistorik
Yderligere materiale findes i [Ailoot-dokumentationen](https://ailoot.ai/docs/).
[Ailoot-guides](https://ailoot.ai/docs/)
[Gå til Ailoot](https://ailoot.ai/)
## Spørgsmål og svar ### Beviser en sikkerhedsgennemgang uden fund, at applikationen er sikker? Nej. Det er en indledende kodegennemgang med mulige falske negativer og filtrering. Verificér rettelser, afprøv rolle- og samtidighedsadfærd i staging, og undersøg den faktiske udrullede konfiguration. ### Blokerer den viste GitHub Action automatisk commits eller sammenfletninger? Det viste workflow dokumenterer ingen sådan garanti. Det poster PR-fund. Gennemgå dem, og test bekræftede rettelser; artiklen leverer ingen verificeret lokal hook, der blokerer commits. ## Ailoot · Virksomheden og dens projektportefølje Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI. Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder. Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.