code-review-security

<!-- syncToGlobal: true --> <!-- author: aktsmm --> <!-- repository: https://github.com/aktsmm/Agent-Customization --> <!-- license: CC BY-NC-SA 4.0 --> <!-- copyright: Copyright (c) 2025 aktsmm --> # code review security 指定された差分、PR、選択範囲、ファイル、または現在の Git 変更をセキュリティ観点でレビューする。 ## When to Use - 使う: `/security-review` 的に、変更差分の exploitability を確認したいとき - 使う: injection、認証認可、secret leak、supply chain、LLM prompt injection を重点的に見たいとき - 使う: 「セキュリティレビュー」「脆弱性見て」「攻撃可能性を見て」と依頼されたとき - 使う: 「レビューして修正」「fix」「直して」など、レビュー後の修正まで明示されたとき - 使わない: 一般的なコード品質、style、設計好み、性能だけを見たいとき。その場合は `/code-review-multi-angle` を使う ## Mode - 既定は `review-only`: コードを編集せず、security finding と修正方針だけを出す - `fix` / `修正して` / `直して` が明示された場合だけ `review-and-fix`: security review、critic review、最小修正、focused validation まで行う - destructive operation、外部反映、履歴改変、push、広範囲 refactor、secret rotation は fix mode でも実行前に確認する ## Scope Detection 優先順でレビュー対象を決める。 1. ユーザーが指定した PR URL、比較ブランチ、ファイル、選択範囲、貼り付け diff 2. staged changes: `git --no-pager diff --staged` 3. unstaged changes: `git --no-pager diff` 4. working tree が clean の場合: `git --no-pager diff main...HEAD` `main` 以外の base branch が自然なリポジトリでは、branch 名や upstream を確認してから使う。 ## Security Review Rules - 変更行または変更により到達可能になったコードだけを主対象にする - 既存脆弱性でも、diff に vulnerable code が現れている場合は報告してよい - exploit path、trust boundary、attacker-controlled input、impact を説明できないものは finding にしない - test code は production vulnerability を示す場合だけ報告する - style、maintainability、generic best practice、単なる DoS、rate limiting、CPU / memory exhaustion は原則報告しない ## Vulnerability Categories 最低限、次の 11 カテゴリを確認する。 - `StringInjection`: SQL / shell / HTML / JSON / YAML / code 生成で unsafe string composition がないか - `BadCrypto`: 弱い暗号、短い鍵、非暗号乱数、弱い password hashing がないか - `BrokenAccessControl`: path traversal、CSRF、open redirect、権限境界破りがないか - `HardcodedCredentials`: source / config に credential、key、token がないか - `SensitiveDataLeak`: secret、PII、stack trace、内部 URL を log / response / file に出していないか - `SecurityMisconfiguration`: CSP / HTTPS / HttpOnly / CORS / debug / XXE など安全設定を壊していないか - `AuthenticationFailure`: certificate validation、認証方式、origin check、sensitive operation の HTTPS が抜けていないか - `DataIntegrityFailure`: integrity check なし deserialization、prototype pollution、insecure content execution がないか - `SSRF`: attacker-controlled URL / host / protocol を fetch していないか - `SupplyChainAttack`: mutable dependency、remote code execution、未検証 download、registry / action / image 参照の乗っ取りがないか - `XPIA`: untrusted data が LLM prompt、tool routing、stage transition、policy、debug bypass に影響していないか ## Severity and Confidence - Critical: RCE、full system compromise、重大な data breach - High: privilege escalation、authentication bypass、sensitive data access - Medium: 条件付きだが有意な exploit、limited data access、information disclosure - Low: defense-in-depth、lower-impact security control bypass 報告閾値。 - Critical: confidence 6/10 以上 - High: confidence 7/10 以上 - Medium: confidence 8/10 以上 - Low: confidence 9/10 以上 閾値未満は `Assumptions / Not Reviewed` に回し、finding として断定しない。 ## Critic Review security finding を出す前、または fix mode で修正する前に、利用可能な rubber duck / critic 経路で確認する。 - 利用可能なら native Rubber Duck、`duck-critic` skill、read-only subagent、別モデル critic のいずれかを使う - critic には exploit path、confidence、false positive の可能性、修正案の副作用を重点確認させる - critic は read-only とし、修正や状態変更を任せない - critic の指摘は重複排除し、採用したものだけ findings または fixes に反映する - critic 経路が使えない場合は、自分で second-pass security review を行い、使えなかった理由を `Verification` に書く ## Verification 可能な範囲で、finding を出す前に read-only または低リスクの確認を行う。 - data flow、call site、sanitizer、auth guard、policy、config、dependency source を確認する - 既存の secure coding pattern と比較する - 必要なら focused test、typecheck、lint、secret scan、dependency metadata 確認を実行する - 実行できない場合は、理由と代替確認を明記する - review-only ではコードを編集しない。ファイル作成・修正・削除も行わない - fix mode では、critic review 後に最小修正を行い、focused validation を実行する ## Output Format 重大度順に findings を先に出す。 ```markdown ## Security Findings ### 1. {短いタイトル} - Severity: Critical | High | Medium | Low - Confidence: N/10 - Category: {カテゴリ名} - File: {path}:{line} - Problem: {脆弱性と exploit path} - Evidence: {差分、data flow、guard 確認、仕様から確認した根拠} - Suggested Fix: {実装方針。review-only ではコードは変更しない} ## No Security Vulnerabilities {finding がない場合だけ、高信頼の脆弱性が見つからなかった理由を 1 行で書く} ## Assumptions / Not Reviewed - {未確認範囲、閾値未満の懸念、実行できなかった検証。なければ None} ## Fixes Applied - {fix mode の場合だけ、変更したファイルと理由。review-only では None} ## Verification - {実行した確認、critic review 経路、または未実行理由} ``` 褒め、長い作業ログ、見たファイルの網羅列挙は出さない。 ## Completion Criteria - 対象差分または指定範囲を特定した - 11 カテゴリを確認した - finding は exploit path と confidence threshold を満たすものだけに絞った - finding または fix mode では critic review を行った、または代替 second-pass を明記した - 可能な範囲で guard / sanitizer / data flow / focused validation を確認した - review-only ではコードを変更していない - fix mode では最小修正後に focused validation を行った