# Säkerhetsgranskning i Claude Code: steg-för-steg-guide och automatisering med GitHub Action 2026 > Så kontrollerar du säkerheten i ett vibe-projekt med /security-review i Claude Code. Installationssteg, en GitHub Action-mall, 6 typer av sårbarheter och ärliga begränsningar. Source: https://ailoot.ai/blog/sv/claude-code-security-review/ Canonical: https://ailoot.ai/blog/sv/claude-code-security-review/ Language: sv Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-7723ddbbf796cda045b7b804a103210bdd145cebdfa4fba775e13dde43387f1f Författaren till originalmaterialet beskriver sin erfarenhet: ”Jag körde just security-review på mitt eget vibe-projekt, och teamet hittade flera verkliga problem på 4 minuter som redan har åtgärdats.” Det här är samma arbete som tidigare tog en extern konsult en dag. Ytterligare material om hur du konfigurerar verktyg finns i [Ailoot-dokumentationen](https://ailoot.ai/docs/).
[Ailoot-guider](https://ailoot.ai/docs/)
## Vad är /security-review i Claude Code?
Det viktigaste `/security-review` är ett inbyggt Claude Code-kommando som analyserar hela projektet eller de aktuella ändringarna direkt från terminalen. Anthropic lanserade det den 20 februari 2026 som en del av Claude Code Security och gjorde det tillgängligt för alla Pro-, Max- och API Console-användare. Begäran betalas från ditt vanliga Claude API-saldo.
Kommandot fungerar i två lägen. Lokalt: kör `/security-review` i terminalen, så läser Claude kodförrådet och skapar en rapport. På serversidan: samma motor installeras som en GitHub Action och kommenterar automatiskt direkt i varje Pull Request. Till skillnad från klassiska SAST-skannrar (Snyk Code, Semgrep, SonarQube) bygger `/security-review` inte på fasta regler. Det läser kod som en aktiv ingenjör: följer dataflödet, förstår vilket ramverk du använder och var tillitsgränserna går, och hittar sårbarheter som ingen regel beskriver.

Claude Code Security läser och resonerar kring din kod som en mänsklig säkerhetsforskare skulle göra: det förstår hur komponenter samverkar, följer hur data rör sig genom applikationen och hittar komplexa sårbarheter som regelbaserade verktyg missar.

— Anthropic, https://www.anthropic.com/news/claude-code-security
Det betyder inte att `/security-review` ersätter ett externt penetrationstest eller tester i en stagingmiljö. Det kan automatisera en del av den första kodgranskningen, men artikeln mäter ingen andel av granskningstäckningen. Nedan förklarar jag hur du kör det på rätt sätt och vad Claude hittar i ditt projekt. ## Hur kör du /security-review i 5 steg?
Det viktigaste Uppdatera Claude Code till den senaste versionen, öppna projektet i en terminal, kör `/security-review`, vänta på rapporten (1 till 5 minuter för ett genomsnittligt projekt), läs allvarlighetsbedömningarna och be Claude tillämpa åtgärderna. Kommandot fungerar med alla teknikstackar: Next.js, Django, FastAPI, Rails, Go, Rust. Ingen särskild konfiguration krävs.
**Steg 1. Uppdatera Claude Code.** Kommandot fungerar från och med versionen som släpptes den 20 februari 2026. ```bash claude update ``` Om du installerade Claude Code via npm kan du också göra så här: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Kontrollera att `/security-review` har dykt upp: ```bash claude /help | grep security ``` **Steg 2. Öppna projektet och logga in i Claude Code.** ```bash cd ~/projects/my-vibe-project claude ``` **Steg 3. Kör kommandot.** Skriv helt enkelt in följande i Claude Code: ``` /security-review ``` Claude går automatiskt igenom 3 analysfaser: 1. **Research om kodförrådets kontext** - läser strukturen och identifierar teknikstacken, routes och databasfrågor. 2. **Jämförande analys** - jämför det aktuella läget med typiska sårbarhetsmönster för den här teknikstacken. 3. **Sårbarhetsbedömning** - listar varje misstanke med en konfidensnivå på en skala från 1-10. Endast fynd med konfidens ≥ 8 tas med i rapporten. **Steg 4. Läs rapporten.** Utdataformatet är en markdown-tabell. För varje problem anger Claude: - **Fil och radnummer** (till exempel `src/auth/login.ts:42`) - **Allvarlighetsgrad** (HIGH / MEDIUM / LOW) - **Kategori** (`sql_injection`, `xss`, `auth_bypass`, `insecure_storage`) - **Beskrivning** - vad som är fel - **Exploateringsscenario** - hur en angripare skulle kunna utnyttja det - **Rekommendation** - hur det kan åtgärdas **Steg 5. Be Claude tillämpa åtgärderna.** Därefter kan du arbeta med det som med en vanlig agent: > ”Tillämpa åtgärderna för fynd med allvarlighetsgraden HIGH i rapporten, ett i taget, med en PR-beskrivning.” Claude öppnar varje fil och föreslår en ändring; du bekräftar den. I ett verkligt projekt stängde jag 5 fynd på 40 minuter i stället för de planerade 3 timmarna.
[Ailoot-guider](https://ailoot.ai/docs/)
## Vilka sårbarheter hittar /security-review?
Det viktigaste Claude hittar 6 klasser: SQL-injektion och injektioner i allmänhet, XSS, problem med autentisering och behörighet, läckor av känsliga uppgifter, brister i tredjepartsberoenden och hårdkodade hemligheter i koden. Kommandot kan också hantera autentiseringslogik som är utspridd över flera filer, vilket regelbaserade skannrar inte klarar av.
Den fullständiga listan över vad som ingår i analysen som standard beskrivs i [Anthropics officiella dokumentation](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Kategori | Vad den letar efter | |----|----| | **SQL-injektion** | Direkt strängsammansättning i SQL, osäkra ORM-anrop (`raw()` utan parametrar), Prisma `$queryRawUnsafe` | | **XSS** | Rendering med `dangerouslySetInnerHTML` utan sanering, mallsystem utan automatisk escapning, `innerHTML` från användarinmatning | | **Autentiseringsbrister** | Återanvändbara token, saknade behörighetskontroller i API-routes, JWT utan utgångsdatum, sessionsfixering | | **Osäker datahantering** | Validering endast på klientsidan, svar med extra fält (överhämtning), öppen omdirigering | | **Sårbarheter i beroenden** | Sårbara versioner av npm-/pip-/cargo-paket, kontrollerade med `npm audit` och motsvarande verktyg | | **Hemligheter** | Hårdkodade API-nycklar, token i `.env.example`, lösenord i koden | Dessutom täcker kommandot kategorier som automatiserade skannrar sällan hittar: - **Kommandoinjektion** - körning av användarinmatning i ett skal (`child_process.exec(userInput)`) - **Sökvägsgenomgång** - inläsning av en fil via `../../etc/passwd` - **XXE** - XML med externa entiteter - **Mallinjektion** - SSTI i Jinja/Handlebars/EJS - **NoSQL-injektion** - operatorerna `$ne`, `$gt` i MongoDB-frågor - **Felaktig kryptografianvändning** - användning av MD5, ECB-läge, ett statiskt IV Claude anger allvarlighetsgraden för varje fynd. Skalan är enkel: - **HIGH** - fjärrexploatering utan autentisering, dataläcka som påverkar alla användare - **MEDIUM** - exploatering med ytterligare villkor (en session krävs / en viss inmatning) - **LOW** - en möjlig attackvektor, inte kritisk nu, men värd att åtgärda Bra att känna till: med standardkonfigurationen rapporterar Claude **inte** DoS, begränsning av anropsfrekvens, minnesbrist, öppna omdirigeringar utan bevisad påverkan, regexinjektion / ReDoS eller loggförfalskning. Det är avsiktligt, så att du inte överöses med brus. Om dessa klasser är viktiga kan du utöka reglerna (se avsnittet om filtrering av falska positiva längre ned). ## Hur konfigurerar du en GitHub Action för automatisk granskning?
Det viktigaste Anthropic släppte den officiella actionen `anthropics/claude-code-security-review@main`. Den kopplas in med en enda workflow-fil och kommenterar automatiskt direkt i varje Pull Request med de sårbarheter den hittar. Konfigurera `CLAUDE_API_KEY` och arbetsflödets behörigheter. Den officiella Action varnar för att den inte är härdad mot promptinjektion och bör granska betrodda PR:er; granska bidragsgivar- och arbetsflödesåtkomst innan du aktiverar den.
**Steg 1. Skaffa en API-nyckel.** Gå till [console.anthropic.com](https://console.anthropic.com/), skapa en API-nyckel och kopiera den. **Steg 2. Lägg in nyckeln bland kodförrådets hemligheter.** I GitHub: Settings → Secrets and variables → Actions → New repository secret. Ge den namnet `CLAUDE_API_KEY`; värdet är din nyckel. **Steg 3. Skapa en workflow-fil.** Spara 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 }} ``` **Steg 4. Slå samman grenen med main.** Actionen startar automatiskt vid nästa PR. **Vad actionen gör:** - Körs vid varje öppen / uppdaterad Pull Request. - Tar diffen mellan PR-grenen och main. - Kör samma motor som den lokala `/security-review`. - Publicerar kommentarer direkt på kodrader med en misstanke. - Dubbletterar hela rapporten i Job Summary. **Viktiga detaljer i `permissions`:** - `pull-requests: write` - för att publicera kommentarer direkt. - `contents: read` - för att läsa kod. Ingen `write`. Actionen ändrar inte koden själv; den rapporterar bara. Den här behörighetsuppsättningen räcker för ett privat kodförråd. För ett offentligt kodförråd kan du även ange `actions: read` om du använder återanvändbara workflows. ## Hur filtrerar du falska positiva och ändrar känsligheten?
Det viktigaste Actionen har 9 indata som du kan använda för att konfigurera dess beteende för projektet. De viktigaste är: `exclude-directories` (till exempel `tests/,fixtures/`), `false-positive-filtering-instructions` (sökväg till en md-fil med dina regler om ”det här är inte en sårbarhet eftersom...”) och `custom-security-scan-instructions` för ytterligare domänspecifika kontroller.
Fullständig tabell över GitHub Action-indata ([källa: kodförrådets README](https://github.com/anthropics/claude-code-security-review)): | Indata | Standardvärde | Vad den gör | |----|----|----| | `claude-api-key` | \- | Anthropics API-nyckel. Krävs. | | `comment-pr` | `true` | Om kommentarer ska publiceras direkt i PR:en | | `upload-results` | `true` | Om resultatet ska sparas som en artefakt i 90 dagar | | `exclude-directories` | \- | Kommaseparerat: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Vilken modell som ska användas | | `claudecode-timeout` | `20` | Tidsgräns i minuter | | `run-every-commit` | `false` | Kör vid varje push, inte bara vid PR:er | | `false-positive-filtering-instructions` | \- | Sökväg till en md-fil med dina regler | | `custom-security-scan-instructions` | \- | Sökväg till en md-fil med ytterligare kontroller | **Exempel på konfiguration av filtrering av falska positiva.** Skapa 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. ``` Koppla in den i workflow-filen: ```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 ``` **Anpassade instruktioner för säkerhetsskanning** fungerar på liknande sätt. Skapa en fil med regler som är särskilt viktiga för ditt 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. ``` Det här är inte längre en Anthropic-förinställning: du överför din kunskap om projektet till regler som Claude tillämpar varje gång. Det är själva kärnan i ”metodik framför modell”. Mer om kontextmetodik för Claude finns i guiderna [”Så konfigurerar du CLAUDE.md”](https://ailoot.ai/blog/sv/claude-md-template/) och [”Second Brain i Claude Code”](https://ailoot.ai/blog/sv/claude-code-second-brain/). ## Vad missar Claude och varför: ärliga begränsningar?
Det viktigaste En kodgranskning kör inte i sig applikationen eller verifierar dess driftsatta miljö. Den kan flagga möjliga race conditions, affärslogikfel eller konfigurationsproblem i koden, men stagingtester och granskning av faktisk driftsättning behövs för att bekräfta beteende och återstående risker.
Anthropic listar tydligt vad som är inaktiverat som standard och varför ([källa: kodförrådets README](https://github.com/anthropics/claude-code-security-review)): - **Denial of Service** - för mycket brus, nästan alltid liten påverkan. - **Problem med hastighetsbegränsning** - hanteras på infrastrukturnivå, inte i koden. - **Minnes- / CPU-utmattning** - samma sak. - **Generisk indata-validering utan bevisad påverkan** - att validera varje fält skapar en lavin av falska positiva. - **Öppen omdirigering** - ofta avsedd funktion. Vad enbart kodgranskning inte kan verifiera fullt utan belägg från körning eller driftsättning: - **Produktionsserverns konfiguration.** NGINX-headers, CORS-policyer, TLS-inställningar, portar som lyssnar. Dessa måste kontrolleras manuellt i en stagingmiljö. - **Race conditions.** Till exempel dubbel spendering vid samtidiga återbetalningsbegäranden. Statisk analys kan flagga misstänkta mönster, men samtidighetsbeteendet behöver fortfarande testas. - **Affärslogikfel i betalningar.** Om totalsumman för din order beräknas på klientsidan och skickas direkt till betalningsleverantören är det allvarlighetsgraden HIGH, men Claude ser inte alltid det här mönstret utan tydlig kontext om hur betalningen ska fungera. - **IDOR på databasnivå.** Om frågan `SELECT * FROM orders WHERE id = $1` inte kontrollerar `WHERE user_id = $session.userId` hittar Claude det ofta. Men om kontrollen görs via ORM-middleware och Claude inte kan se hela dataflödet kan den missa det. - **Motståndskraft mot social ingenjörskonst / nätfiske.** Det har inget med kod att göra. Använd `/security-review` som en första statisk granskning. Följ upp med dynamiska tester i staging, roll- och behörighetskontroller, relevanta SAST-kontroller och granskning av den faktiskt driftsatta konfigurationen. Ingen uppmätt täckningsprocent fastställs här. Avgör omfattning och tidpunkt för en extern bedömning utifrån systemets risker och förändringar. Varken ett kommando eller regelbundna externa granskningar fastställer 100% säkerhetstäckning. ## Hur författaren till originalmaterialet gjorde en säkerhetsgranskning av ett vibe-projekt
Det viktigaste Jag körde `/security-review` på mitt eget TypeScript-projekt med Next.js, Prisma, PostgreSQL och Redis. På 4 minuter genomförde kommandot en första granskning, gav flera väl underbyggda fynd av olika allvarlighetsgrad, och jag slutförde till slut de fungerande åtgärderna på en och en halv timme. Det var billigare och snabbare än alla externa penetrationstester.
Vad dök upp? En typisk bild för ett genomsnittligt vibe-projekt i stadiet ”fungerar i produktion, men har inte granskats”: flera misstankar kring autentiseringsflödet, logiken för hantering av webhooks från betalningsintegrationen, filuppladdning och ett par specifika anmärkningar om HTML-hantering vid rendering. Jag beskriver inte detaljerna offentligt; vissa rekommendationer har redan tillämpats och andra finns fortfarande i PR. I det rapporterade projektet var den första skanningen användbar och snabb; det fastställer ingen granskningstäckningsprocent eller allmän slutförandetid. Det jag avfärdade som falska positiva: - Fynd om DoS via regexar i indatavalidering - den verkliga belastningen hamnar inte på de regexarna. - Ett fynd om en hårdkodad API-nyckel - det var en testnyckel med ett uttryckligt `fake-`-prefix i fixtures. Hur lång tid tog det? Själva körningen tog 4 minuter. Det tog 25 minuter att granska rapporten. Att tillämpa åtgärder tog ungefär en timme med tester. Totalt: ungefär en och en halv timme från ”startade” till ”allt är i main”. Ett externt penetrationstest på samma yta tar en kalendervecka och kostar dussintals gånger mer. Viktigaste slutsatsen. `/security-review` ersätter inte ett externt penetrationstest. Det kan hitta användbara kodproblem, som i författarens rapporterade fyraminutersskanning. Granska och testa åtgärderna och kontrollera sedan körningsbeteende och driftsatt konfiguration separat; skanningen eliminerar inte projektets säkerhetsrisk. ## Hur integrerar du /security-review i din pre-commit-rutin?
Det viktigaste Kör `/security-review` i projektsessionen före en betydande commit, läs fynden, åtgärda bekräftade problem och kör relevanta tester igen. Det är en granskningsprocedur, inte ett tekniskt förbud mot att checka in.
Den tidigare hooken med `git_commit`, `--severity HIGH` och `--fail-on-find` är inget dokumenterat fungerande recept och ska inte användas som säkerhetsgrind. Artikeln ger ingen verifierad lokal hook som blockerar commits. Den officiella GitHub Action som visas ovan ger automatiserade PR-fynd; dra inte slutsatsen att den blockerar commits eller sammanslagningar bara för att den kommenterar en PR. En fullständig förklaring av hooks finns i guiden [”Hooks i Claude Code”](https://ailoot.ai/blog/sv/claude-code-hooks/). Ett alternativ med [rutiner](https://ailoot.ai/blog/sv/claude-code-routines/) är att skapa en `pre-deploy-check`-rutin som kör `/security-review` + `npm run build` + `npm run test` med ett enda kommando. Ytterligare material finns i Ailoot-dokumentationen. Om du använder [MCP-servrar](https://ailoot.ai/blog/sv/mcp-servers-claude-code/) kan du integrera fynd från `/security-review` med ett incidenthanteringssystem (Sentry, Linear, Notion) så att varje HIGH automatiskt blir en ticket. ## Vanliga frågor om /security-review
Det viktigaste 5 vanliga frågor: vad det kostar, hur ofta det ska köras, vilka teknikstackar det fungerar med, vad du ska göra om Claude redan har hittat den här sårbarheten och om du kan köra det bara på specifika filer. Korta svar utan utfyllnad.
**Vad kostar en körning?** Det beror på projektets storlek. På mina 30K rader använder en körning cirka \$0.30-0.50 av API-saldot. Ett stort företagskodförråd med en miljon rader kostar upp till \$5-8 per körning. Det är dussintals gånger billigare än en SaaS-skannerprenumeration. **Hur ofta bör jag köra det lokalt?** Minst före varje produktionsrelease. Överväg det också före betydande commits och PR:er. Artikeln ger ingen verifierad automatisk hook som blockerar commits. **Vilka teknikstackar fungerar det med?** Alla som Claude kan läsa. Enligt författarens observationer har följande kontrollerats: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Kvaliteten är lägre för mycket ovanliga språk (Erlang, Elixir, Clojure), men det hittar något. **Vad ska jag göra om Claude hittar samma ”sårbarhet” varje gång, trots att det egentligen inte är en sårbarhet?** Lägg till den i `false-positive-filtering-instructions` med en förklaring av ”varför detta är säkert”. Claude slutar då rapportera den vid framtida körningar. **Kan jag köra det bara på specifika filer?** Lokalt, ja: kör helt enkelt `/security-review src/lib/auth/*.ts`. I GitHub Action granskas bara den aktuella PR-diffen, vilket vanligtvis är det man menar med ”specifika filer”. ## Källor
### Källor - [Anthropic - lanseringsmeddelande om Claude Code Security](https://www.anthropic.com/news/claude-code-security) - officiellt meddelande daterat 20 februari 2026 - [Anthropic Help Center - Automatiserade säkerhetsgranskningar i Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - officiella instruktioner för att köra det - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - GitHub Action-källkod med fullständig README - [Claude Code Docs - Kodgranskning](https://code.claude.com/docs/en/code-review) - allmän Anthropic-dokumentation - [Anthropic Help Center - Använd Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - relaterade produkter - [Port - Ta in Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integrering av resultat i en intern utvecklarportal - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - kommandots versionshistorik
Ytterligare material finns i [Ailoot-dokumentationen](https://ailoot.ai/docs/).
[Ailoot-guider](https://ailoot.ai/docs/)
[Gå till Ailoot](https://ailoot.ai/)
## Frågor om den här guiden: Säkerhetsgranskning i Claude Code: steg-för-steg-guide och automatisering med GitHub Action 2026 ### Bevisar en ren security-review-rapport att applikationen är säker? Nej. Det är en första kodgranskning med möjliga falska negativa och filtrering. Verifiera åtgärder, testa roll- och samtidighetsbeteende i staging och granska faktiskt driftsatt konfiguration. ### Blockerar GitHub Action här automatiskt commits eller sammanslagningar? Det visade arbetsflödet fastställer ingen sådan garanti. Det publicerar PR-fynd. Granska dem och testa bekräftade åtgärder; artikeln ger ingen verifierad lokal hook som blockerar commits. ## Ailoot · Företaget och dess projektportfölj Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll. Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder. Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.