Semakan keselamatan dalam Claude Code: panduan langkah demi langkah dan automasi GitHub Action pada 2026

Penulis bahan asal menceritakan pengalamannya: “Saya baru sahaja menjalankan security-review pada projek vibe saya sendiri, dan pasukan itu menemui beberapa isu sebenar dalam masa 4 minit yang semuanya sudah dibaiki.” Kerja yang sama sebelum ini mengambil masa sehari bagi perunding luar.

Bahan tambahan tentang konfigurasi alat tersedia dalam dokumentasi Ailoot.

Apakah /security-review dalam Claude Code?#

Arahan ini berfungsi dalam dua mod. Setempat: jalankan /security-review dalam terminal, kemudian Claude membaca repositori dan menghasilkan laporan. Pada bahagian pelayan: enjin yang sama dipasang sebagai GitHub Action dan secara automatik mengulas sebaris pada setiap Pull Request.

Tidak seperti pengimbas SAST klasik (Snyk Code, Semgrep, SonarQube), /security-review tidak bergantung pada peraturan tetap. Ia membaca kod seperti jurutera sebenar: menjejaki aliran data, memahami framework yang anda gunakan dan lokasi sempadan kepercayaan, serta mengesan kelemahan yang tidak diterangkan oleh sesuatu peraturan.

Ini tidak bermakna /security-review menggantikan pentest luaran atau ujian langsung dalam persekitaran staging. Ia boleh mengautomasikan sebahagian semakan kod awal, tetapi artikel ini tidak mengukur pecahan liputan audit. Di bawah, saya akan menerangkan cara menjalankannya dengan betul dan perkara yang akan ditemukan oleh Claude dalam projek anda.

Bagaimanakah cara menjalankan /security-review dalam 5 langkah?#

Langkah 1. Kemas kini Claude Code. Arahan ini berfungsi mulai keluaran bertarikh 20 Februari 2026.

claude update

Jika anda memasang Claude Code melalui npm, anda juga boleh melakukan perkara berikut:

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

Semak sama ada /security-review sudah tersedia:

claude /help | grep security

Langkah 2. Buka projek dan log masuk ke Claude Code.

cd ~/projects/my-vibe-project
claude

Langkah 3. Jalankan arahan. Dalam Claude Code, masukkan sahaja:

/security-review

Claude secara automatik menjalankan 3 fasa analisis:

1. Penyelidikan konteks repositori - membaca struktur dan mengenal pasti stack, laluan dan pertanyaan pangkalan data.
2. Analisis perbandingan - membandingkan keadaan semasa dengan corak kelemahan lazim untuk stack ini.
3. Penilaian kelemahan - menyenaraikan setiap syak wasangka bersama tahap keyakinan pada skala 1 hingga 10. Hanya dapatan dengan tahap keyakinan ≥ 8 dimasukkan dalam laporan.

Langkah 4. Baca laporan. Format output ialah jadual markdown. Bagi setiap isu, Claude memberikan:

• Fail dan nombor baris (contohnya, src/auth/login.ts:42)
• Tahap keterukan (HIGH / MEDIUM / LOW)
• Kategori (sql_injection, xss, auth_bypass, insecure_storage)
• Penerangan - perkara yang salah
• Senario eksploitasi - cara penyerang boleh menggunakannya
• Syor - cara membaikinya

Langkah 5. Minta Claude menerapkan pembaikan. Selepas itu, anda boleh menggunakannya seperti ejen biasa:

“Terapkan pembaikan dengan tahap keterukan HIGH daripada laporan, satu demi satu, berserta penerangan PR.”

Claude akan membuka setiap fail dan mencadangkan perubahan; anda mengesahkannya. Dalam projek sebenar, saya menyelesaikan 5 dapatan dalam 40 minit, bukannya 3 jam seperti yang dirancang.

Apakah kelemahan yang ditemukan oleh /security-review?#

Senarai penuh perkara yang disertakan dalam analisis secara lalai diterangkan dalam dokumentasi rasmi Anthropic:

Selain itu, arahan ini meliputi kategori yang jarang diperiksa oleh pengimbas automatik:

• Command injection - menjalankan input pengguna dalam shell (child_process.exec(userInput))
• Path traversal - memuatkan fail melalui ../../etc/passwd
• XXE - XML dengan entiti luaran
• Template injection - SSTI dalam Jinja/Handlebars/EJS
• NoSQL injection - operator $ne, $gt dalam pertanyaan MongoDB
• Penyalahgunaan kriptografi - menggunakan MD5, mod ECB atau IV statik

Claude memberikan tahap keterukan kepada setiap dapatan. Skalanya mudah:

• HIGH - eksploitasi jauh tanpa pengesahan, kebocoran data yang menjejaskan semua pengguna
• MEDIUM - eksploitasi dengan syarat tambahan (sesi diperlukan / input khusus)
• LOW - vektor berpotensi yang belum kritikal sekarang tetapi wajar dibaiki

Perkara yang berguna untuk diketahui: dalam konfigurasi standard, Claude tidak melaporkan DoS, had kadar, kehabisan memori, open redirect tanpa kesan yang terbukti, regex injection / ReDoS atau pemalsuan log. Ini disengajakan supaya anda tidak dibanjiri hingar. Jika kelas ini penting, lanjutkan peraturannya (lihat bahagian penapisan positif palsu di bawah).

Bagaimanakah cara menyediakan GitHub Action untuk semakan automatik?#

Langkah 1. Dapatkan kunci API. Pergi ke console.anthropic.com, cipta kunci API dan salinnya.

Langkah 2. Simpan kunci dalam rahsia repositori. Dalam GitHub: Settings → Secrets and variables → Actions → New repository secret. Namakannya CLAUDE_API_KEY; nilainya ialah kunci anda.

Langkah 3. Cipta fail workflow. Simpan sebagai .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 }}

Langkah 4. Gabungkan branch ke dalam main. Action akan bermula secara automatik dengan PR seterusnya.

Perkara yang dilakukan oleh action:

• Berjalan pada setiap Pull Request yang dibuka / disegerakkan.
• Mengambil perbezaan antara branch PR dengan main.
• Menjalankan enjin yang sama seperti /security-review setempat.
• Menyiarkan ulasan sebaris terus pada baris kod yang mempunyai syak wasangka.
• Menyalin laporan penuh dalam Job Summary.

Butiran penting dalam permissions:

• pull-requests: write - untuk menyiarkan ulasan sebaris.
• contents: read - untuk membaca kod. Tiada write. Action ini tidak mengubah kod sendiri; ia hanya melaporkan.

Set kebenaran ini mencukupi untuk repositori persendirian. Untuk repositori awam, anda juga boleh menyatakan actions: read jika menggunakan workflow boleh guna semula.

Bagaimanakah cara menapis positif palsu dan mengubah sensitiviti?#

Jadual penuh input GitHub Action (sumber: README repositori):

Contoh konfigurasi penapisan positif palsu. Cipta fail .claude/security/false-positives.md:

# Peraturan penapisan positif palsu untuk projek kami

- Sebarang `dangerouslySetInnerHTML` dalam `src/lib/email/layout.ts` adalah selamat -
  HTML dibina daripada templat dipercayai dan melalui `sanitize-html`
  ketika ditulis ke pangkalan data, bukannya ketika dipaparkan.
- Jangan laporkan kunci API ujian yang dikodkan terus dalam `__tests__/fixtures/*.ts`.
  Semua kunci bermula dengan awalan `sk-test-fake-`.
- Penggabungan SQL dalam `src/lib/admin/migrations.ts` boleh diterima - fail ini hanya dijalankan
  sebagai root, dan data input datang daripada pemboleh ubah persekitaran.

Sambungkannya dalam workflow:

- 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

Arahan imbasan keselamatan tersuai berfungsi dengan cara yang sama. Cipta fail dengan peraturan yang khusus penting untuk projek anda:

# Semakan tambahan untuk projek kami

- Setiap endpoint di bawah `/api/admin/*` mesti menyemak peranan pentadbir
  melalui wrapper kongsi. Tanpa wrapper ini, tahap keterukannya ialah HIGH.
- Semua webhook YooKassa / CloudPayments mesti mengesahkan tandatangan sebelum
  menghuraikan badan permintaan. Tanpa pengesahan ini, tahap keterukannya ialah HIGH.
- Token pautan ajaib mesti digunakan sekali sahaja (ditandakan sebagai telah digunakan selepas
  permintaan sah yang pertama). Token yang boleh digunakan semula mempunyai tahap keterukan MEDIUM.

Ini bukan lagi pratetap Anthropic: anda memindahkan kepakaran tentang projek ke dalam peraturan yang digunakan Claude setiap kali. Itulah intipati “metodologi mengatasi model”.

Untuk mengetahui lebih lanjut tentang metodologi konteks bagi Claude, lihat panduan “Cara mengkonfigurasi CLAUDE.md” dan “Second Brain dalam Claude Code”.

Apakah yang TIDAK dapat dikesan oleh Claude dan mengapa: batasan yang jujur?#

Anthropic menyenaraikan dengan jelas perkara yang dilumpuhkan secara lalai dan sebabnya (sumber: README repositori):

• Denial of Service - terlalu banyak hingar, hampir selalu berimpak rendah.
• Isu had kadar - dikendalikan pada peringkat infrastruktur, bukan dalam kod.
• Kehabisan memori / CPU - sama.
• Pengesahan input umum tanpa kesan yang terbukti - mengesahkan setiap medan menghasilkan lambakan positif palsu.
• Open redirect - selalunya tingkah laku yang disengajakan.

Perkara yang tidak boleh disahkan sepenuhnya melalui semakan kod sahaja tanpa bukti masa jalan atau penggunaan:

• Konfigurasi pelayan produksi. Pengepala NGINX, dasar CORS, tetapan TLS, port yang mendengar. Semua ini perlu disemak secara manual dalam persekitaran staging.
• Keadaan perlumbaan. Contohnya, perbelanjaan berganda semasa permintaan bayaran balik serentak. Analisis statik boleh menandai corak mencurigakan, tetapi tingkah laku serentak masih perlu diuji.
• Kecacatan logik perniagaan pembayaran. Jika jumlah pesanan dikira pada klien lalu dihantar begitu sahaja kepada penyedia pembayaran, tahap keterukannya HIGH, tetapi Claude tidak semestinya melihat corak ini tanpa konteks jelas tentang cara pembayaran sepatutnya berfungsi.
• IDOR peringkat pangkalan data. Jika pertanyaan SELECT * FROM orders WHERE id = $1 tidak menyemak WHERE user_id = $session.userId, Claude selalunya dapat mengesannya. Tetapi jika semakan dilaksanakan melalui middleware ORM dan Claude tidak dapat melihat keseluruhan aliran data, ia mungkin terlepas pandang.
• Ketahanan terhadap kejuruteraan sosial / pancingan data. Perkara ini tiada kaitan dengan kod.

Gunakan /security-review sebagai semakan statik awal. Susuli dengan ujian dinamik dalam staging, pemeriksaan peranan serta kebenaran, pemeriksaan SAST berkaitan dan semakan konfigurasi sebenar yang digunakan. Tiada peratus liputan diukur dibuktikan di sini.

Tentukan skop dan masa penilaian luaran berdasarkan risiko serta perubahan sistem. Satu arahan mahupun audit luaran berkala tidak membuktikan liputan keselamatan 100%.

Cara penulis bahan asal menjalankan semakan keselamatan pada projek vibe#

Perkara yang muncul. Gambaran biasa bagi projek vibe purata pada tahap “berfungsi dalam produksi, tetapi belum disemak”: beberapa syak wasangka tentang aliran pengesahan, logik pemprosesan webhook daripada integrasi pembayaran, pengendalian muat naik fail dan beberapa catatan khusus tentang pengendalian HTML semasa paparan. Saya tidak menghuraikan butirannya secara terbuka; beberapa syor sudah dilaksanakan dan yang lain masih dalam PR. Dalam projek dilaporkan ini, imbasan awal berguna dan pantas; ia tidak membuktikan peratus liputan audit atau tempoh penyiapan umum.

Perkara yang saya tolak sebagai positif palsu:

• Dapatan tentang DoS melalui regex dalam pengesahan input - beban sebenar tidak tertumpu pada regex tersebut.
• Satu dapatan tentang kunci API yang dikodkan terus - itu ialah kunci ujian dengan awalan fake- yang jelas dalam fixtures.

Tempoh yang diambil. Proses itu sendiri mengambil masa 4 minit. Menyemak laporan mengambil masa 25 minit. Menerapkan pembaikan bersama ujian mengambil masa kira-kira sejam. Jumlahnya: kira-kira satu setengah jam dari “mula” sehingga “semuanya dalam main”. Pentest luaran dengan skop yang sama mengambil masa seminggu kalendar dan kosnya berkali-kali ganda lebih tinggi.

Kesimpulan utama. /security-review tidak menggantikan pentest luaran. Ia boleh mengenal pasti dapatan peringkat kod yang berguna, seperti dalam imbasan empat minit yang dilaporkan penulis. Semak dan uji pembaikan, kemudian periksa tingkah laku masa jalan serta konfigurasi digunakan secara berasingan; imbasan tidak menghapuskan risiko keselamatan projek.

Bagaimanakah cara mengintegrasikan /security-review dalam rutin sebelum commit?#

Hook yang ditunjukkan sebelum ini menggunakan git_commit, --severity HIGH dan --fail-on-find bukan resipi berfungsi yang didokumenkan dan tidak boleh digunakan sebagai gerbang keselamatan. Artikel ini tidak membekalkan hook setempat penyekat commit yang disahkan. GitHub Action rasmi di atas menyediakan dapatan PR automatik; jangan simpulkan ia menyekat commit atau merge hanya kerana mengulas PR.

Penerangan penuh tentang hook terdapat dalam panduan “Hook dalam Claude Code”.

Alternatif menggunakan routines ialah mencipta rutin pre-deploy-check yang menjalankan /security-review + npm run build + npm run test dengan satu arahan. Bahan tambahan tersedia dalam dokumentasi Ailoot.

Jika anda menggunakan pelayan MCP, anda boleh mengintegrasikan dapatan daripada /security-review dengan sistem insiden (Sentry, Linear, Notion) supaya setiap dapatan HIGH menjadi tiket secara automatik.

Soalan lazim tentang /security-review#

Berapakah kos satu pelaksanaan? Bergantung pada saiz projek. Bagi 30K baris kod saya, satu pelaksanaan menggunakan kira-kira $0.30-0.50 daripada baki API. Repositori perusahaan besar dengan sejuta baris kod menelan kos sehingga $5-8 bagi setiap pelaksanaan. Kos ini berpuluh-puluh kali lebih rendah daripada langganan mana-mana pengimbas SaaS.

Berapa kerap saya patut menjalankannya secara setempat? Sekurang-kurangnya, sebelum setiap keluaran produksi. Pertimbangkan juga sebelum commit dan PR penting. Artikel ini tidak menyediakan hook automatik penyekat commit yang disahkan.

Stack apa yang disokong? Apa-apa stack yang boleh dibaca oleh Claude. Menurut pemerhatian penulis, stack ini telah diuji: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Kualitinya lebih rendah untuk bahasa yang sangat eksotik (Erlang, Elixir, Clojure), tetapi ia tetap akan menemukan sesuatu.

Apa yang perlu saya lakukan jika Claude menemukan “kelemahan” yang sama setiap kali walaupun ia bukan kelemahan sebenar? Tambahkannya pada false-positive-filtering-instructions dengan penerangan tentang “sebab perkara ini selamat”. Claude akan berhenti melaporkannya dalam pelaksanaan seterusnya.

Bolehkah saya menjalankannya pada fail tertentu sahaja? Secara setempat, ya: jalankan sahaja /security-review src/lib/auth/*.ts. Dalam GitHub Action, hanya perbezaan PR semasa yang disemak, dan itulah yang biasanya dimaksudkan dengan “fail tertentu”.

Sumber#

Bahan tambahan tersedia dalam dokumentasi Ailoot.