security-audit

セキュリティレビュー

人間のセキュリティ研究者のようにコードベースについて推論する、AI 搭載のセキュリティスキャナーです。データフローを追跡し、コンポーネント間の相互作用を理解して、パターンマッチングツールでは見逃す脆弱性を検出します。

このスキルを使う場面

次のような依頼には、このスキルを使います。

• コードベースまたはファイルのセキュリティ脆弱性をスキャンする
• セキュリティレビューまたは脆弱性チェックを実行する
• コミットやデプロイの前に変更コードを確認する。特に認証、API、データベース、依存関係、設定の変更がある場合
• SQL インジェクション、XSS、コマンドインジェクション、その他のインジェクションの欠陥を確認する
• コード内に露出した API キー、ハードコードされたシークレット、認証情報がないか探す
• 既知の CVE がないか依存関係を監査する
• 認証、認可、アクセス制御のロジックをレビューする
• 安全でない暗号化や弱い乱数生成を検出する
• ユーザー入力から危険なシンクまで追跡するデータフロー分析を行う
• 「コードは安全ですか？」「このファイルをスキャンして」「リポジトリに脆弱性がないか確認して」のような依頼
• /security-review または /security-review <path> を実行する

このスキルの仕組み

パターンに照合する従来の静的解析ツールとは異なり、このスキルは次のように動作します。

1. セキュリティ研究者のようにコードを読みます — コンテキスト、意図、データフローを理解します
2. ファイルをまたいで追跡します — ユーザー入力がアプリケーション内をどのように移動するかをたどります
3. 検出結果を自己検証します — 各結果を再確認し、誤検知を除外します
4. 重大度を評価します — CRITICAL / HIGH / MEDIUM / LOW / INFO
5. 対象を絞ったパッチを提案します — 各検出結果に具体的な修正方法が含まれます
6. 人間の承認を必要とします — 自動適用は行わず、必ず先にレビューできます

実行ワークフロー

毎回、次の手順を順番どおりに実行してください。

ステップ 1 — 対象範囲の決定

スキャン対象を決めます。

• パスが指定されている場合（/security-review src/auth/）、その範囲のみをスキャンします
• 依頼が変更に関するもの（diff、ステージ済みファイル、コミット前またはデプロイ前のチェック）の場合、変更されたファイル（git diff、git diff --staged）を対象にします。変更したコードが呼び出すコード、または変更したコードを呼び出すコードなど、周辺のコードも読みます。変更はコンテキストによって初めて悪用可能になることがよくあります。依存関係マニフェストまたはロックファイルが変更された場合にのみ、ステップ 2 を実行します
• パスが指定されていない場合、ルートからプロジェクト全体をスキャンします
• 使用されている言語とフレームワークを特定します（package.json、requirements.txt、go.mod、Cargo.toml、pom.xml、Gemfile、composer.json などを確認します）
• 言語固有の脆弱性パターンを読み込むため、references/language-patterns.md を読みます

ステップ 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 を確認します
• 利用可能な場合は、そのエコシステムの監査ツール（npm audit、pip-audit など）を実行します。最新のアドバイザリが反映されます。これらのツールはパッケージレジストリへのネットワークアクセスを必要とします。利用できない場合は、以下のウォッチリストを代わりに使い、監査がオフラインだったことを伝えます
• 既知の CVE があるパッケージ、非推奨の暗号化ライブラリ、不審なほど古いバージョンに固定されたパッケージにフラグを立てます
• 厳選されたウォッチリストとして、references/vulnerable-packages.md を読みます

ステップ 3 — シークレットと露出のスキャン

対象範囲内のすべてのファイル（設定、環境変数、CI/CD、Dockerfile、IaC を含む）をスキャンし、次の項目を確認します。

• ハードコードされた API キー、トークン、パスワード、秘密鍵
• 誤ってコミットされた .env ファイル
• コメントやデバッグログ内のシークレット
• クラウド認証情報（AWS、GCP、Azure、Stripe、Twilio など）
• 認証情報が埋め込まれたデータベース接続文字列
• 適用する正規表現パターンとエントロピーのヒューリスティクスについては、references/secret-patterns.md を読みます

ステップ 4 — 脆弱性の詳細スキャン

これはスキャンの中核です。コードについて推論してください。パターン照合だけで済ませないでください。 各カテゴリの詳細は references/vuln-categories.md を読んでください。

インジェクションの欠陥

• SQL インジェクション：文字列補間を使った生のクエリ、ORM の誤用、二次 SQLi
• XSS：エスケープされていない出力、dangerouslySetInnerHTML、innerHTML、テンプレートインジェクション
• コマンドインジェクション：ユーザー入力を使った exec/spawn/system
• LDAP、XPath、ヘッダー、ログへのインジェクション

認証とアクセス制御

• 機密性の高いエンドポイントに認証がない
• オブジェクトレベル認可の不備（BOLA/IDOR）
• JWT の弱点（alg:none、弱いシークレット、有効期限の検証なし）
• セッション固定化、CSRF 対策の欠如
• Secure / HttpOnly / SameSite が設定されていないセッションクッキー
• パスワードが平文または高速ハッシュで保存されている。パスワードポリシーが弱い。特権アカウントに MFA がない
• 権限昇格につながる経路
• マスアサインメント / パラメーターポリューション

データの取り扱い

• ログ、エラーメッセージ、API レスポンスに機密データが含まれている
• 保存時または転送時の暗号化がない
• 安全でないデシリアライズ
• パストラバーサル / ディレクトリトラバーサル
• XXE（XML 外部エンティティ）の処理
• SSRF（サーバーサイドリクエストフォージェリ）

暗号技術

• セキュリティ目的で MD5、SHA1、DES を使用している
• IV またはソルトがハードコードされている
• 乱数生成が弱い（トークンに Math.random() を使用）
• TLS 証明書の検証がない

セキュリティ設定の不備とロギング

• CORS の許可範囲が広すぎる、本番環境でデバッグモードが有効、セキュリティヘッダーがない （フレームワーク固有の詳細は references/language-patterns.md を参照）
• セキュリティイベント（ログイン失敗、アクセス制御の拒否、権限の変更）が記録されておらず、 攻撃を検知できない

ビジネスロジック

• 競合状態（TOCTOU）
• 金融計算での整数オーバーフロー
• 機密性の高いエンドポイントにレート制限がない
• 予測可能なリソース識別子

ステップ 5 — ファイル横断のデータフロー分析

ファイルごとのスキャン後に、全体的なレビューを実施します。

• ユーザーが制御できる入力（HTTP パラメーター、ヘッダー、本文、ファイルアップロード）を入口からシンク（DB クエリ、exec 呼び出し、HTML 出力、ファイル書き込み）まで追跡する
• 複数ファイルをまとめて確認した場合にのみ見つかる脆弱性を特定する
• サービス間またはモジュール間の信頼境界が安全か確認する

ステップ 6 — 自己検証パス

各検出結果について、以下を行います。

1. 関連するコードを新たな視点で読み直す
2. 「これは実際に悪用可能か、それとも見落としたサニタイズ処理があるか」と確認する
3. フレームワークまたはミドルウェアが上流ですでに処理していないか確認する
4. 実際の脆弱性ではない検出結果は、重大度を下げるか破棄する
5. 最終的な重大度を割り当てる：CRITICAL / HIGH / MEDIUM / LOW / INFO

ステップ 7 — セキュリティレポートの生成

references/report-format.md で定義された形式で、レポート全体を出力します。 スニペットまたは差分の範囲を対象とする場合は、該当しないセクション（例：マニフェストに変更がない場合の依存関係監査）は、 ゼロで埋めずに省略してください。

ステップ 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

各検出結果の「参照」行に記載する外部リファレンス： OWASP トップ 10、CWE トップ 25