security-review について
security-reviewは、アプリケーションのセキュリティを確認するコードレビュー用スキルです。ファイル間のデータフローを追跡し、依存関係とシークレットを監査して、検出結果を再確認します。パッチ案は提示しますが、適用は人が判断します。
主な機能
- 01ファイル間の入力から危険な処理への追跡
- 02依存関係とシークレットの監査
- 03重大度と確信度の評価
- 04検出結果の再検証
- 05人の確認を前提としたパッチ案
活用シーン
- 01リポジトリの脆弱性レビュー
- 02ユーザー入力から危険な処理までの追跡
- 03既知のCVEがある依存関係の確認
- 04認証とアクセス制御の監査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ github/ awesome-copilot --skill security-reviewインストール後、Claude Code で/security-reviewを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/language-patterns.mdreport-format.mdsecret-patterns.mdvuln-categories.mdvulnerable-packages.md詳細
セキュリティレビュー
人間のセキュリティ研究者のようにコードベースを分析する、AI を活用したセキュリティスキャナーです。データフローを追跡し、コンポーネント間のやり取りを理解して、パターンマッチング型のツールでは見逃す脆弱性を検出します。
このスキルを使う場面
次のような依頼には、このスキルを使います。
- コードベースまたはファイルのセキュリティ脆弱性をスキャンする
- セキュリティレビューまたは脆弱性チェックを実行する
- SQL インジェクション、XSS、コマンドインジェクション、その他のインジェクションの欠陥を確認する
- コード内で公開されている API キー、ハードコードされたシークレット、認証情報を探す
- 既知の CVE がないか依存関係を監査する
- 認証、認可、アクセス制御のロジックをレビューする
- 安全でない暗号化または弱い乱数を検出する
- ユーザー入力から危険なシンクまでを追跡するデータフロー分析を実施する
- 「自分のコードは安全ですか?」「このファイルをスキャンして」「リポジトリに脆弱性がないか確認して」などの依頼
/security-reviewまたは/security-review <path>を実行する
このスキルの仕組み
パターンに一致するかを調べる従来の静的解析ツールとは異なり、このスキルは次のように動作します。
- セキュリティ研究者のようにコードを読みます — コンテキスト、意図、データフローを理解します
- 複数のファイルをまたいで追跡します — ユーザー入力がアプリケーション内をどのように移動するかをたどります
- 検出結果を自ら検証します — 各結果を再確認し、誤検出を除外します
- 深刻度を評価します — CRITICAL / HIGH / MEDIUM / LOW / INFO
- 的を絞ったパッチを提案します — すべての検出結果に具体的な修正方法が含まれます
- 人間の承認を必須とします — 自動適用は行わず、必ず最初に確認していただきます
実行ワークフロー
毎回、次の手順を順番どおりに実施してください。
Step 1 — 対象範囲の決定
スキャン対象を決定します。
- パスが指定されている場合(
/security-review src/auth/)、その範囲のみをスキャンします - パスが指定されていない場合、ルートからプロジェクト全体をスキャンします
- 使用されている言語とフレームワークを特定します(package.json、requirements.txt、 go.mod、Cargo.toml、pom.xml、Gemfile、composer.json などを確認します)
- 言語固有の脆弱性パターンを読み込むため、
references/language-patterns.mdを読みます
Step 2 — 依存関係の監査
ソースコードをスキャンする前に、まず依存関係を監査します(手早く成果を得られます)。
- Node.js:既知の脆弱なパッケージがないか、
package.jsonとpackage-lock.jsonを確認します - Python:
requirements.txt/pyproject.toml/Pipfileを確認します - Java:
pom.xml/build.gradleを確認します - Ruby:
Gemfile.lockを確認します - Rust:
Cargo.tomlを確認します - Go:
go.sumを確認します - 既知の CVE があるパッケージ、非推奨の暗号化ライブラリ、不審なほど古いバージョンに固定されたパッケージにフラグを立てます
- 厳選された監視対象リストとして、
references/vulnerable-packages.mdを読みます
Step 3 — シークレットと露出のスキャン
すべてのファイル(設定、env、CI/CD、Dockerfile、IaC を含む)をスキャンし、次を探します。
- ハードコードされた API キー、トークン、パスワード、秘密鍵
- 誤ってコミットされた
.envファイル - コメントやデバッグログ内のシークレット
- クラウド認証情報(AWS、GCP、Azure、Stripe、Twilio など)
- 認証情報が埋め込まれたデータベース接続文字列
- 適用する正規表現パターンとエントロピーのヒューリスティックについて、
references/secret-patterns.mdを読みます
Step 4 — 脆弱性の詳細スキャン
これが中核となるスキャンです。コードについて推論し、単にパターンに照合するだけにしないでください。
各カテゴリの詳細については、references/vuln-categories.md を読んでください。
インジェクションの欠陥
- SQL インジェクション:文字列補間を使った生のクエリ、ORM の誤用、二次 SQLi
- XSS:エスケープされていない出力、dangerouslySetInnerHTML、innerHTML、テンプレートインジェクション
- コマンドインジェクション:ユーザー入力を使った exec/spawn/system
- LDAP、XPath、ヘッダー、ログへのインジェクション
認証とアクセス制御
- 機密性の高いエンドポイントに認証がない
- オブジェクトレベルの認可の不備(BOLA/IDOR)
- JWT の弱点(alg:none、弱いシークレット、有効期限の検証がない)
- セッション固定、CSRF 対策の欠如
- 権限昇格につながる経路
- マスアサインメント/パラメーター汚染
データの取り扱い
- ログ、エラーメッセージ、API レスポンスに含まれる機密データ
- 保存時または転送時の暗号化の欠如
- 安全でないデシリアライズ
- パストラバーサル/ディレクトリトラバーサル
- XXE(XML 外部実体)の処理
- SSRF(サーバーサイドリクエストフォージェリ)
暗号化
- セキュリティ目的での MD5、SHA1、DES の使用
- IV またはソルトのハードコード
- 弱い乱数生成(トークンに Math.random() を使用)
- TLS 証明書の検証の欠如
ビジネスロジック
- 競合状態(TOCTOU)
- 金融計算での整数オーバーフロー
- 機密性の高いエンドポイントでのレート制限の欠如
- 予測可能なリソース識別子
Step 5 — ファイル横断のデータフロー分析
ファイルごとのスキャン後に、全体的なレビューを実施します。
- エントリーポイント(HTTP パラメーター、ヘッダー、本文、ファイルアップロード)からシンク(DB クエリ、exec 呼び出し、HTML 出力、ファイル書き込み)まで、ユーザーが制御できる入力を追跡します
- 複数のファイルをまとめて確認した場合にのみ現れる脆弱性を特定します
- サービス間またはモジュール間の信頼境界が安全か確認します
Step 6 — 自己検証
各検出事項について、次の手順を実施します。
- 関連コードを新たな視点で読み直します
- 「これは実際に悪用可能か、それとも見落としたサニタイズ処理があるか」と確認します
- フレームワークやミドルウェアが上流ですでに処理していないか確認します
- 実際の脆弱性ではない検出事項は、深刻度を下げるか除外します
- 最終的な深刻度を割り当てます:CRITICAL / HIGH / MEDIUM / LOW / INFO
Step 7 — セキュリティレポートの作成
references/report-format.md で定義された形式で、レポート全体を出力します。
Step 8 — パッチの提案
CRITICAL および HIGH の検出事項すべてについて、具体的なパッチを作成します。
- 脆弱なコード(修正前)を示します
- 修正後のコードを示します
- 変更内容とその理由を説明します
- 元のコードスタイル、変数名、構造を維持します
- 修正内容を説明するコメントを該当箇所に追加します
**「適用する前に、各パッチを確認してください。まだ何も変更されていません。」**と明記します。
深刻度のガイド
| 深刻度 | 意味 | 例 |
|---|---|---|
| 🔴 CRITICAL | 直ちに悪用されるリスクがあり、データ侵害の可能性が高い | SQLi、RCE、認証バイパス |
| 🟠 HIGH | 重大な脆弱性があり、悪用経路が存在する | XSS、IDOR、ハードコードされたシークレット |
| 🟡 MEDIUM | 条件付き、または他の脆弱性との連鎖により悪用可能 | CSRF、オープンリダイレクト、弱い暗号 |
| 🔵 LOW | ベストプラクティス違反で、直接的なリスクは低い | 詳細すぎるエラー、ヘッダーの欠如 |
| ⚪ INFO | 注意に値する所見だが、脆弱性ではない | 古い依存関係(CVE なし) |
出力ルール
- 必ず最初に、深刻度別の件数を示す検出事項の概要表を出力します
- 決してパッチを自動適用せず、人によるレビュー用にのみ提示します
- 必ず各検出事項に信頼度(High / Medium / Low)を記載します
- 検出事項はファイル別ではなく、カテゴリ別にまとめます
- 具体的に記載します。ファイルパス、行番号、脆弱なコードの正確なスニペットを含めます
- リスクを平易な英語で説明します。攻撃者がこれを使って何を実行できるかを示します
- コードベースに問題がない場合は、スキャンした内容とともに「脆弱性は見つかりませんでした」と明確に記載します
参照ファイル
詳細な検出ガイダンスについては、必要に応じて以下の参照ファイルを読み込んでください:
references/vuln-categories.md— 検出シグナル、安全なパターン、エスカレーションチェッカーを備えた、すべての脆弱性カテゴリの詳細リファレンス- 検索パターン:
SQL injection、XSS、command injection、SSRF、BOLA、IDOR、JWT、CSRF、secrets、cryptography、race condition、path traversal
- 検索パターン:
references/secret-patterns.md— 正規表現パターン、エントロピーベースの検出、CI/CD のシークレットリスク- 検索パターン:
API key、token、private key、connection string、entropy、.env、GitHub Actions、Docker、Terraform
- 検索パターン:
references/language-patterns.md— JavaScript、Python、Java、PHP、Go、Ruby、Rust 向けのフレームワーク固有の脆弱性パターン- 検索パターン:
Express、React、Next.js、Django、Flask、FastAPI、Spring Boot、PHP、Go、Rails、Rust
- 検索パターン:
references/vulnerable-packages.md— npm、pip、Maven、Rubygems、Cargo、Go モジュール向けの厳選された CVE ウォッチリスト- 検索パターン:
lodash、axios、jsonwebtoken、Pillow、log4j、nokogiri、CVE
- 検索パターン:
references/report-format.md— ファインディングカード、依存関係監査、シークレットスキャン、パッチ提案のフォーマットを備えた、セキュリティレポート用の構造化出力テンプレート- 検索パターン:
report、format、template、finding、patch、summary、confidence
- 検索パターン: