Tietoturvatarkastus Claude Codessa: vaiheittainen opas ja GitHub Action -automaatio vuonna 2026

Alkuperäisen materiaalin kirjoittaja kuvaa kokemustaan: ”Ajoin juuri security-review-komennon omassa vibe-projektissani, ja tiimi löysi 4 minuutissa useita todellisia ongelmia, jotka on jo korjattu.” Aiemmin samaan työhön kului ulkopuoliselta konsultilta päivä.

Lisämateriaalia työkalujen määrittämisestä on Ailootin dokumentaatiossa.

Mikä on Claude Coden /security-review?#

Komento toimii kahdessa tilassa. Paikallisesti: suorita /security-review päätteessä, jolloin Claude lukee repositorion ja tuottaa raportin. Palvelinpuolella: sama moottori asennetaan GitHub Actionina, joka kommentoi automaattisesti suoraan jokaiseen Pull Requestiin.

Toisin kuin perinteiset SAST-skannerit (Snyk Code, Semgrep, SonarQube), /security-review ei perustu kiinteisiin sääntöihin. Se lukee koodia kuin todellinen insinööri: seuraa tietovirtaa, ymmärtää käyttämäsi sovelluskehyksen ja luottamusrajat sekä havaitsee haavoittuvuuksia, joita mikään sääntö ei kuvaa.

Tämä ei tarkoita, että /security-review korvaisi ulkopuolisen penetraatiotestin tai staging-ympäristössä tehtävän live-testauksen. Se voi automatisoida osan alustavasta koodikatselmoinnista, mutta artikkeli ei mittaa auditoinnin kattavuuden osuutta. Alla selitän, miten se suoritetaan oikein ja mitä Claude löytää projektistasi.

Miten suoritat /security-reviewn 5 vaiheessa?#

Vaihe 1. Päivitä Claude Code. Komento toimii 20. helmikuuta 2026 julkaistusta versiosta alkaen.

claude update

Jos asensit Claude Coden npm:n kautta, voit tehdä myös näin:

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

Tarkista, että /security-review on ilmestynyt:

claude /help | grep security

Vaihe 2. Avaa projekti ja kirjaudu Claude Codeen.

cd ~/projects/my-vibe-project
claude

Vaihe 3. Suorita komento. Kirjoita Claude Coden sisällä yksinkertaisesti:

/security-review

Claude käy automaattisesti läpi 3 analyysivaihetta:

1. Repositorion kontekstin tutkiminen - lukee rakenteen ja tunnistaa teknologiapinon, reitit ja tietokantakyselyt.
2. Vertaileva analyysi - vertaa nykytilaa tämän teknologiapinon tyypillisiin haavoittuvuusmalleihin.
3. Haavoittuvuuksien arviointi - luettelee jokaisen epäilyn luottamustasolla 1–10. Raporttiin sisällytetään vain löydökset, joiden luottamustaso on ≥ 8.

Vaihe 4. Lue raportti. Tuloste on markdown-taulukko. Claude antaa jokaisesta ongelmasta seuraavat tiedot:

• Tiedosto ja rivinumero (esimerkiksi src/auth/login.ts:42)
• Vakavuus (HIGH / MEDIUM / LOW)
• Luokka (sql_injection, xss, auth_bypass, insecure_storage)
• Kuvaus - mikä on vialla
• Hyökkäysskenaario - miten hyökkääjä voisi käyttää sitä hyväkseen
• Suositus - miten ongelma korjataan

Vaihe 5. Pyydä sitä tekemään korjaukset. Sen jälkeen voit työskennellä sen kanssa kuten tavallisen agentin kanssa:

”Tee raportissa mainitut HIGH-vakavuustason korjaukset yksi kerrallaan ja liitä mukaan PR-kuvaus.”

Claude avaa jokaisen tiedoston ja ehdottaa muutosta; sinä vahvistat sen. Todellisessa projektissa suljin 5 löydöstä 40 minuutissa suunnitellun 3 tunnin sijaan.

Mitä haavoittuvuuksia /security-review löytää?#

Täydellinen luettelo oletusarvoisesti analysoitavista asioista on Anthropicin virallisessa dokumentaatiossa:

Lisäksi komento kattaa luokkia, joita automaattiset skannerit harvoin havaitsevat:

• Komentoinjektio - käyttäjän syötteen suorittaminen komentotulkissa (child_process.exec(userInput))
• Polun läpikäynti - tiedoston lataaminen polusta ../../etc/passwd
• XXE - XML, jossa on ulkoisia entiteettejä
• Malliinjektio - SSTI Jinjassa/Handlebarsissa/EJS:ssä
• NoSQL-injektio - operaattorit $ne ja $gt MongoDB-kyselyissä
• Kryptografian väärinkäyttö - MD5:n, ECB-tilan tai staattisen IV:n käyttö

Claude antaa jokaiselle löydökselle vakavuusluokituksen. Asteikko on yksinkertainen:

• HIGH - etäkäyttö ilman tunnistautumista, kaikkia käyttäjiä koskeva tietovuoto
• MEDIUM - hyödyntäminen lisäehdoilla (istunto vaaditaan / tarvitaan tietty syöte)
• LOW - mahdollinen hyökkäysvektori, ei juuri nyt kriittinen mutta korjaamisen arvoinen

Hyvä tietää: vakiomäärityksillä Claude ei raportoi DoS-ongelmia, nopeusrajoituksia, muistin loppumista, avoimia uudelleenohjauksia ilman todistettua vaikutusta, regex-injektiota / ReDoS-haavoittuvuuksia eikä lokien väärentämistä. Tämä on tarkoituksellista, jotta raportti ei täyty kohinasta. Jos nämä luokat ovat olennaisia, laajenna sääntöjä (katso jäljempänä oleva väärien positiivisten suodatusta käsittelevä osio).

Miten määrität GitHub Actionin automaattista tarkastusta varten?#

Vaihe 1. Hanki API-avain. Siirry osoitteeseen console.anthropic.com, luo API-avain ja kopioi se.

Vaihe 2. Lisää avain repositorion salaisuuksiin. GitHubissa: Settings → Secrets and variables → Actions → New repository secret. Anna nimeksi CLAUDE_API_KEY; arvoksi tulee API-avaimesi.

Vaihe 3. Luo workflow-tiedosto. Tallenna se nimellä .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 }}

Vaihe 4. Yhdistä haara main-haaraan. Action käynnistyy automaattisesti seuraavan PR:n yhteydessä.

Mitä action tekee:

• Suoritetaan jokaisessa avoimessa tai päivitetyssä Pull Requestissa.
• Ottaa diff-tiedoston PR-haaran ja main-haaran väliltä.
• Käyttää samaa moottoria kuin paikallinen /security-review.
• Julkaisee inline-kommentit suoraan koodiriveille, joilla on epäilty ongelma.
• Kopioi koko raportin Job Summary -yhteenvetoon.

Tärkeitä tietoja permissions-määrityksestä:

• pull-requests: write - inline-kommenttien julkaisemiseen.
• contents: read - koodin lukemiseen. Ei write-oikeutta. Action ei muokkaa koodia itse, vaan ainoastaan raportoi.

Tämä oikeusjoukko riittää yksityiseen repositorioon. Julkisessa repositoriossa voit lisäksi määrittää actions: read, jos käytät uudelleenkäytettäviä workflow’ita.

Miten suodatat vääriä positiivisia ja muutat herkkyyttä?#

GitHub Actionin syötekenttien täydellinen taulukko (lähde: repositoryn README):

Esimerkki väärien positiivisten suodatuksen määrittämisestä. Luo tiedosto .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.

Liitä se workflow’hun:

- 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

Mukautetut tietoturvaskannauksen ohjeet toimivat samalla tavalla. Luo tiedosto, jossa ovat projektisi kannalta erityisen tärkeät säännöt:

# 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.

Tämä ei enää ole Anthropicin oletusasetuskokonaisuus: siirrät projektia koskevan asiantuntemuksesi säännöiksi, joita Claude soveltaa joka kerta. Se on ”menetelmä ennen mallia” -ajattelun ydin.

Lue lisää Clauden kontekstimenetelmästä oppaista ”CLAUDE.md-tiedoston määrittäminen” ja ”Second Brain Claude Codessa”.

Mitä Claude EI havaitse ja miksi: rehelliset rajoitukset?#

Anthropic luettelee selkeästi, mikä on oletusarvoisesti poistettu käytöstä ja miksi (lähde: repositoryn README):

• Denial of Service - liikaa kohinaa, lähes aina vähäinen vaikutus.
• Nopeusrajoituksiin liittyvät ongelmat - niitä hallitaan infrastruktuuritasolla, ei koodissa.
• Muistin / suorittimen loppuminen - sama perustelu.
• Yleinen syötteen validointi ilman todistettua vaikutusta - jokaisen kentän validointi tuottaa väärien positiivisten vyöryn.
• Avoin uudelleenohjaus - usein tarkoituksellista toimintaa.

Mitä pelkkä koodikatselmointi ei voi täysin todentaa ilman ajonaikaista tai julkaisuympäristön näyttöä:

• Tuotantopalvelimen konfiguraatio. NGINX-otsakkeet, CORS-käytännöt, TLS-asetukset ja kuuntelevat portit. Nämä on tarkistettava manuaalisesti staging-ympäristössä.
• Race conditionit. Esimerkiksi kaksinkertainen veloitus samanaikaisissa hyvityspyynnöissä. Staattinen analyysi voi huomata epäilyttäviä rakenteita, mutta samanaikainen toiminta tarvitsee silti testausta.
• Maksujen liiketoimintalogiikan virheet. Jos tilauksen kokonaissumma lasketaan asiakkaalla ja lähetetään vain maksunvälittäjälle, ongelman vakavuus on HIGH, mutta Claude ei aina havaitse tätä mallia ilman tarkkaa kontekstia maksun odotetusta toiminnasta.
• Tietokantatason IDOR. Jos kysely SELECT * FROM orders WHERE id = $1 ei tarkista ehtoa WHERE user_id = $session.userId, Claude huomaa sen usein. Jos tarkistus kuitenkin toteutetaan ORM-väliohjelmistossa eikä Claude näe koko tietovirtaa, se saattaa jäädä huomaamatta.
• Sosiaalisen manipuloinnin / tietojenkalastelun vastustuskyky. Sillä ei ole mitään tekemistä koodin kanssa.

Käytä /security-review-komentoa alustavana staattisena katselmointina. Jatka dynaamisilla testeillä staging-ympäristössä, rooli- ja käyttöoikeustarkistuksilla, sopivilla SAST-tarkistuksilla sekä todellisen julkaistun kokoonpanon katselmoinnilla. Tässä ei vahvisteta mitattua kattavuusprosenttia.

Päätä ulkopuolisen arvioinnin laajuus ja ajankohta järjestelmäsi riskeistä ja muutoksista. Yksi komento tai määräaikainen ulkopuolinen auditointi ei kumpikaan osoita 100% turvallisuuskattavuutta.

Miten alkuperäisen materiaalin kirjoittaja teki tietoturvatarkastuksen vibe-projektille#

Mitä löytyi? Tyypillinen tilanne keskivertaisessa vibe-projektissa, joka ”toimii tuotannossa, mutta sitä ei ole tarkastettu”: useita epäilyjä tunnistautumisvirrasta, maksupalvelun webhookien käsittelylogiikasta, tiedostojen latauksen käsittelystä sekä pari erityistä huomautusta HTML:n käsittelystä renderöinnin aikana. En kuvaile yksityiskohtia julkisesti; osa suosituksista on jo toteutettu ja osa on yhä PR:ssä. Tässä raportoidussa projektissa alustava tarkistus oli hyödyllinen ja nopea. Se ei osoita auditoinnin kattavuusprosenttia tai yleistä valmistumisaikaa.

Mitä hylkäsin väärinä positiivisina:

• Syötteen validoinnin regexeihin liittyvät DoS-löydökset - todellinen kuormitus ei kohdistu näihin regexeihin.
• Yksi kovakoodattua API-avainta koskeva löydös - kyseessä oli testiavain, jonka fake--etuliite oli fixtures-tiedostoissa selvästi näkyvissä.

Kuinka kauan siihen meni? Ajo kesti 4 minuuttia. Raportin läpikäynti vei 25 minuuttia. Korjausten tekemiseen testien kanssa kului noin tunti. Yhteensä noin puolitoista tuntia siitä, kun ”aloitin”, siihen, että ”kaikki on main-haarassa”. Saman kohdealueen ulkopuolinen pentest kestää kalenteriviikon ja maksaa moninkertaisesti enemmän.

Tärkein johtopäätös. /security-review ei korvaa ulkopuolista pentestiä. Se voi tunnistaa hyödyllisiä kooditason havaintoja, kuten kirjoittajan raportoimassa neljän minuutin ajossa. Katselmoi ja testaa korjaukset ja tarkista sitten ajonaikainen toiminta sekä julkaistu kokoonpano erikseen. Tarkistus ei poista projektin turvallisuusriskiä.

Miten liität /security-reviewn pre-commit-rutiiniisi?#

Aiemmin näytetty hook, joka käytti arvoja git_commit, --severity HIGH ja --fail-on-find, ei ole dokumentoitu toimiva resepti eikä sitä pidä käyttää turvallisuusporttina. Artikkeli ei tarjoa todennettua paikallista commitin estävää hookia. Edellä esitetty virallinen GitHub Action tuottaa automaattisia PR-havaintoja. Älä päättele sen estävän committeja tai yhdistämisiä pelkästään siitä, että se kommentoi PR:ää.

Hookien täydellinen selitys on oppaassa ”Hookit Claude Codessa”.

Rutiineihin perustuva vaihtoehto on luoda pre-deploy-check-rutiini, joka suorittaa komennot /security-review + npm run build + npm run test yhdellä kertaa. Lisämateriaalia on Ailootin dokumentaatiossa.

Jos käytät MCP-palvelimia, voit yhdistää /security-review-löydökset häiriöidenhallintajärjestelmään (Sentry, Linear, Notion), jolloin jokaisesta HIGH-löydöksestä tulee automaattisesti tiketti.

/security-review-komentoa koskevat usein kysytyt kysymykset#

Paljonko yksi ajo maksaa? Se riippuu projektin koosta. Omassa 30K rivin projektissani yksi ajo käyttää API-saldoa noin $0.30-0.50. Suuri yritysrepositorion miljoonalla rivillä maksaa enintään $5-8 ajoa kohti. Se on moninkertaisesti halvempaa kuin minkään SaaS-skannerin tilaus.

Kuinka usein se pitäisi suorittaa paikallisesti? Vähintään ennen jokaista tuotantojulkaisua. Harkitse sitä myös ennen merkittäviä committeja ja PR:iä. Artikkeli ei tarjoa todennettua automaattisesti commitin estävää hookia.

Millä teknologiapinoilla se toimii? Kaikilla, joita Claude pystyy lukemaan. Kirjoittajan havaintojen mukaan näitä on testattu: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Laatu on heikompi hyvin eksoottisilla kielillä (Erlang, Elixir, Clojure), mutta se löytää jotakin.

Mitä teen, jos Claude löytää saman ”haavoittuvuuden” joka kerta, vaikka kyseessä ei oikeasti ole haavoittuvuus? Lisää se false-positive-filtering-instructions-määritykseen ja selitä, ”miksi tämä on turvallista”. Claude lakkaa ilmoittamasta siitä tulevilla kerroilla.

Voinko suorittaa sen vain tietyille tiedostoille? Paikallisesti kyllä: suorita vain /security-review src/lib/auth/*.ts. GitHub Actionissa tarkistetaan vain nykyisen PR:n diff, mikä yleensä tarkoittaa ”tiettyjä tiedostoja”.

Lähteet#

Lisämateriaalia on Ailootin dokumentaatiossa.