security-audit

セキュリティ監査スキル

目的

コードベースに対して、脅威モデルを最優先した徹底的なセキュリティ監査を実施します。影響度 × 悪用可能性 × 露出度に基づいてランク付けし、CWE および OWASP のカテゴリに対応付けた、構造化されたレポートを作成します。また、重大度が高またはクリティカルの指摘については、具体的な悪用シナリオを提示します。レポートは、ユーザーが選択した形式（下記の「レポート形式」を参照）で、プロジェクトルートに自己完結したファイルとして出力します。形式は、references/report-template-html.md に従った HTML、または references/report-template.md に従った Markdown です。

このスキルはセキュリティに特化しています。並行処理、デッドコード、アンチパターン、パフォーマンス、正確性、エラー処理、テストなど、一般的なコード品質の監査には、同じプラグイン内の関連スキルである code-audit を使用してください。この2つのスキルは、同じコードベースに対して独立して実行することも、順番に実行することもできます。この監査中にセキュリティ以外のコード品質上の問題に気付いた場合は、簡単に記録し、ここで詳しく分析するのではなく、code-audit スキルの実行を推奨してください。

作業レベル

対象範囲内のコードをすべて、1行も残さず確認してください。ざっと目を通す、サンプルを抽出する、ヒューリスティックに基づいてファイルを読み飛ばす、といったことはしないでください。この監査を特徴づける手法は、ソースからシンクへのデータフロー追跡です。すべてのエントリーポイントからの信頼できない入力を、コールグラフをたどってすべての危険なシンクまで追跡し、各段階で検証、エンコーディング、認可、信頼に関する前提を評価してください。パターンマッチングだけでは実際の脆弱性を見逃しますが、データフローを追跡すれば発見できます。一度の作業で範囲全体を確認するには大きすぎる場合は、並列サブエージェントに分担させてください（分割方法についてはフェーズ5を参照）。

心構え

ペネトレーションテスターのようにコードを監査してください。信頼できない入力はすべて敵対的だと想定し、すべてのチェックは有効性が証明されない限り回避される可能性があると考え、検証されない限りすべての境界は越えられると想定してください。多層防御が重要です。1つの層が機能しなかった場合、次の層は何でしょうか。すでにあるもの（誤ったチェック）だけでなく、欠けているもの（本来あるべきチェック）も探してください。現実の侵害の多くは、巧妙なエクスプロイトではなく、制御の欠如、マスアサインメント型の過剰なパラメーター受け入れ、オブジェクトレベル認可の不備、ユーザーが制御するフィールドへの信頼によって発生します。

レポート形式

監査では、プロジェクトのルートに自己完結型のファイルを生成します。形式によってファイル拡張子とフェーズ 6 で使用するテンプレートが決まります。デフォルトは HTML です。インライン SVG による信頼境界図やデータフロー図、重要度／CWE／OWASP タグのスタイル設定、サービスごとに折りたたみ可能なソース／シンクマップの項目、関連する検出結果間のアンカー参照を利用できるためです。これらの機能は、長いセキュリティレポートの有用性を大きく高めますが、Markdown では表現できません。

**スコープを確定する前に、形式を決めてください。** これは必須のゲートです。この実行で形式が確定するまで、スコープの確定、脅威モデリング、意図の特定、ソース／シンクのマッピング、分析、その他の作業を開始しないでください。

まず、ユーザーの起動メッセージを確認し、明示的な形式の指定がないか調べます。次のいずれかがあれば、それに従ってください。

• HTML を示す語句：HTML、html、「ウェブページとして」、「ブラウザーで表示可能」、「レンダリングされたレポート」。
• Markdown を示す語句：MD、md、Markdown、markdown、「プレーンテキストのレポート」、「Markdown 形式で」。

起動メッセージに明確な形式の指定が含まれている場合は、それをゲートの回答として受け入れて作業を進めてください。儀礼的な確認を改めて求めないでください。スコープを確定したことを伝える際に、選択した形式を簡潔に明記してください。

起動メッセージに形式の指定がない場合は、次の質問（または同等の質問）だけをして、ユーザーの回答を待ってください。

レポート形式はどちらにしますか？ HTML（デフォルト。信頼境界図、CWE／OWASP タグ、重要度バッジをインラインで含む自己完結型ファイル）または MD（プレーンな Markdown）？

この質問を他の出力と一緒に提示しないでください。確認せずにデフォルトを選ばないでください。このスキルを実行するたびに、必ずこのゲートを適用してください。

形式が選択されたら、実行中は一貫してその形式を使用してください。

形式	テンプレート	ファイル名
HTML	references/report-template-html.md	SECURITY-AUDIT-REPORT-YYYY-MM-DD.html
MD	references/report-template.md	SECURITY-AUDIT-REPORT-YYYY-MM-DD.md

HTML レポートを生成する場合は、references/report-template-html.md に記載されている HTML 固有の機能を、情報を補足できる場合に活用してください。Markdown の内容を HTML タグで囲むだけで、それらの機能を使わないのであれば、HTML を選ぶ意味がありません。

ワークフロー

ワークフローには 6 つのフェーズがあります。フェーズ 1 は他のすべてに先行する必要があります。フェーズ 2 と 3 はデータ上の依存関係がないため、並行して実行できます。フェーズ 4 はフェーズ 2 に依存し、フェーズ 5 と 6 はそれ以前のすべてのフェーズに依存します。有用な場合はフェーズ内の並列処理を推奨します。フェーズ 3 では必ずサブエージェントを使用し、スキャナーごとに 1 つ割り当てます。大規模なスコープを分割する場合は、フェーズ 5 でサブエージェントを使用します。

フェーズ 1 — 対象範囲の確定

ユーザーのプロンプトから監査対象範囲を特定します。ユーザーは次のように指定する場合があります。

• リポジトリまたは作業ディレクトリ全体。
• 1 つ以上のディレクトリ（例：src/、services/api/）。
• 特定のファイルの一覧。
• 自然言語で説明された機能領域（例：「認証フロー」、「ファイルアップロードエンドポイント」）。
• ファイル内の特定の関数、クラス、またはコード領域。そのコードと直接の依存関係に分析を限定します。

生成ファイル（ロックファイル、コンパイル済み出力、ベンダー依存関係、圧縮済みバンドル）は、デフォルトで対象外です。ソースコードとしてコミットされた生成コード（protobuf スタブ、OpenAPI クライアント、ORM モデル）については、変更マーカーを確認します。手書きの追加コードが含まれている場合、または「DO NOT EDIT」ヘッダーが削除されている場合は、対象に含めます。フェーズ 5 フェーズ B（信頼境界をまたぐデータフロー）では、期待される検証が行われているかを判断するため、対象外のコードへのフローも引き続き追跡します。

ユーザーが指定したパスが存在しない場合は、存在しないパスについて警告し、残りの対象で作業を進めます。指定されたパスがすべて存在しない場合は、停止して確認を求めます。

プロンプトに対象範囲を特定するための十分な情報がない場合は、作業を進める前に確認の質問を 1 つだけします。境界が不明確な監査では、信頼性の低い結果が生じます。

ユーザーが再監査を依頼した場合は、プロジェクトのルートで SECURITY-AUDIT-REPORT-*.md と SECURITY-AUDIT-REPORT-*.html を検索します。複数のレポートがある場合は、形式にかかわらず、ファイルの更新日時が最も新しいものを使用します。デフォルトでは、前回の監査と同じ対象範囲にします。前回のレポートがある場合は、前回の指摘事項のうち解決済みのものと残っているものを新しいレポートに記載し、ユーザーが差分を確認できるようにします。新しいレポートの形式は今回の実行におけるゲート判定に従い、前回のレポートと同じ形式である必要はありません。

確定した対象範囲をユーザーに伝え、直ちに作業を進めます。対象範囲が本当に曖昧な場合にのみ、確認のために停止します。

フェーズ 2 — アプリケーションの脅威モデルを作成する

コードを詳しく読む前に、以降の監査を導く脅威モデル概要を作成します。この手順を省くと、監査は対象を区別しないチェックリストの確認になってしまいます。実施すれば、このアプリケーションに実際に当てはまる脅威を優先できます。

脅威モデル概要では、次の項目を明らかにします。

• アプリケーションの種類 — Web API、サーバーサイドレンダリングの Web アプリ、シングルページアプリ、CLI、ライブラリ、モバイルバックエンド、デスクトップアプリ、組み込み、IoT、ブラウザー拡張機能。
• 公開範囲 — インターネットに公開（匿名トラフィックあり）、認証済みユーザー向けに公開、内部限定（社内ネットワーク）、localhost 限定、シングルテナント、マルチテナント（相互に信頼するか、互いに敵対するか）。
• 機密データの分類 — PII、決済データ、認証情報、セッショントークン、健康記録、財務記録、知的財産／ソースコード、顧客がアップロードしたファイル。
• 信頼境界 — 信頼できないデータが入る箇所、権限が移行する箇所（匿名から認証済み、ユーザーから管理者、テナント間）、プロセスやサービスをまたいでデータが移動する箇所。
• 認証モデル — フォームログイン＋セッションクッキー、JWT ベアラー、OAuth/OIDC、mTLS、API キー、署名付き URL、なし。references/checklists/auth-and-session.md のどのセクションが該当するかを判断します。
• 認可モデル — RBAC、ABAC、所有権ベース、テナントスコープ、なし。監査で検証すべき認可チェックを判断します。
• 外部依存関係と連携 — データベース、キャッシュ、キュー、サードパーティ API、決済プロセッサー、ID プロバイダー。それぞれについて、信頼に関する前提を記載します。
• デプロイコンテキスト — コンテナー、サーバーレス、VM、オンプレミス、クラウドプロバイダー、CI/CD プラットフォーム。IaC と CI/CD のチェックリストを決める際に使用します。
• 該当するチェックリスト — 上記の情報から判断した、フェーズ 5 で読み込む references/checklists/*.md のサブセットです（たとえば、CLI ツールでは XSS/CSRF を省略し、公開 API では API セキュリティを含めます）。
• 深刻度の調整に関する注記 — デフォルトの深刻度を引き上げたり引き下げたりする、アプリケーション固有の要因（たとえば、PHI の取り扱い、敵対するマルチテナント、WAF の背後で実施される緩和策）。

README、package.json／pyproject.toml／go.mod、Dockerfile、docker-compose.yml、フレームワークのシグナル（Django の設定、Express のミドルウェア、Spring のアノテーション、Rails のルート）、エントリーポイントのファイル、ディレクトリ構成からこれらを判断します。コードからアプリケーションの種類または公開範囲が本当に判別できない場合に限り、確認の質問を一つだけします。それ以外の場合は推論して記録し、レポートの利用者が修正できるようにします。

脅威モデル概要は、簡潔な構造化ドキュメントです（単一サービスの場合、通常 200〜400 語）。複数の異なるサービスやアプリケーションの種類を含むモノレポでは、サービスごとに概要を作成するか、それぞれの種類に固有の脅威を明記した統合概要を作成します。サービスごとの形式のほうが規模を拡張しやすくなります。概要は監査の実行ごとに再生成し、実行をまたいで保存してはいけません。

テンプレート、推論のヒューリスティック、一般的なアプリケーションの種類に関する具体例については、references/threat-modeling.md を参照してください。

フェーズ 3 — セキュリティ上の意図を把握する

分析を始める前に、文書化されたセキュリティ上の判断、脅威モデル、認識されている制限事項を調査します。意図的なトレードオフと実際の問題を区別することで、誤検出を減らします。

3 つのサブエージェントを並行して実行します。

• ドキュメントスキャナー — プロジェクト全体のドキュメントを読み込み、セキュリティ関連のファイル（SECURITY.md、THREAT_MODEL.md、.well-known/security.txt、docs/security/、ADR、コンプライアンス文書、ペンテストレポート）を特に重視します。ファイルの検出対象一覧は references/intent-discovery.md に記載されています。
• コード意図スキャナー — 対象範囲内のソースコードを検索し、セキュリティ関連の抑制マーカー（SAST ツール、シークレットスキャナー、言語リンター全般）と、セキュリティ関連のキーワードを含む根拠コメントを探します。マーカーとキーワードの一覧は references/intent-discovery.md に記載されています。
• 履歴スキャナー — git 履歴から意図を示す情報を抽出します。セキュリティ関連のキーワード（CVE、脆弱性、認証、権限昇格、開示、強化、バイパス、悪用、ペンテストなど）をコミットメッセージに含むコミットと、セキュリティ上重要なファイルに変更を加えたコミットを優先します。キーワード一覧とパターンの指針は references/intent-discovery.md に記載されています。

このステップは、コードベースの規模にかかわらず必ず実行します。出力はテーマ別に整理されたセキュリティ意図の概要です（文書化された脅威モデル、認識されているリスクとトレードオフ、セキュリティ規約、抑制された検出結果とその根拠、過去のセキュリティ修正）。項目数は 100 件以下を目標とします。

意図の調査で項目が見つからなかった場合、概要は空になります。その場合も分析は通常どおり続行し、レポートの「文書化されたセキュリティ態勢」セクションに、文書化された意図を示す情報が特定されなかったことを記載します。

サブエージェントへの詳細なプロンプトと概要のテンプレートについては、references/intent-discovery.md を参照してください。

フェーズ 4 — ソース／シンクのマップを作成する

脆弱性を指摘する前に、アプリケーションの信頼できない入力元と危険なシンクを列挙します。このマップが監査の後続工程を導きます。High／Critical のインジェクション系の検出結果はすべて、文書化されたソースとシンクにたどり着く必要があります。

ソースには、HTTP のエントリーポイント（本文、クエリ、パス、ヘッダー、Cookie、マルチパートファイル）、入力として扱われる認証情報（デコード後の JWT／OAuth／SSO クレーム）、CLI 入力（argv、stdin、env）、メッセージ／イベント入力（キューのコンシューマー、Webhook の受信処理、スケジュールされたジョブのペイロード）、信頼できるものとして扱われる外部呼び出しのレスポンス、以前は信頼されていなかったデータのストレージからの読み取り（二次ソース）が含まれます。

シンクには、データベースクエリの構築、シェルおよびプロセスの実行、コード実行（eval／Function／動的な import）、デシリアライズ、ファイルシステム操作、HTTP の外向き通信（SSRF の攻撃対象領域）、テンプレートのレンダリング、HTTP レスポンスの書き込み（HTML／リダイレクト／Set-Cookie／カスタムヘッダー）、ログ出力（機密データの漏えいとログインジェクション）、暗号処理、認証／認可の判断箇所が含まれます。

マップは網羅的な文章にする必要はありません。入力の形式と処理内容を添えた source@file:line および sink@file:line の一覧で十分です。モノレポでは、サービスごとにマップを作成します。

ソースのクラスとシンクのカテゴリの全一覧、フレームワーク固有のパターン（Express、Flask、FastAPI、Django、Rails、Spring、Gin、ASP.NET など）、マップ作成のヒューリスティック、具体例については、references/source-sink-mapping.md を参照してください。

フェーズ 5 — 体系的な分析

大規模コードベースの分割

対象が50ファイルまたは10,000行のコードを超える場合（どちらか一方のしきい値を超えれば該当します）、表面的な分析を避けるため、並列サブエージェントを使用します。これらのしきい値は、意図的に論理和として設定されています。

• モノレポでは、まずサービスごとに分割します。サービス内では、アーキテクチャ層の境界（データアクセス、ビジネスロジック、API ハンドラー、認証ミドルウェア）に沿って分割することを優先します。
• 各サブエージェントには、Threat Model Brief、Security Intent Brief、Source/Sink Map、および担当範囲に適用されるチェックリストを渡します。
• 各サブエージェントは、同じチェックリストに従い、担当範囲について Phase A（ファイルレベル分析）を個別に実施します。
• すべてのサブエージェントが完了したら、統合した範囲を対象に Phase B（信頼境界をまたぐデータフロー）を実施します。特に、分割範囲の境界を越えるデータに注意してください。見落とされた認可チェックや、汚染データの注入がよく潜んでいる箇所です。
• 重複して発見された問題を整理し、最も高い重大度に統合して、すべての該当箇所を列挙します。

サブエージェントを利用できない場合や対象範囲が小さい場合は、すべてのフェーズを順に実施します。分割してもすべての行を確認できない場合は、エントリーポイント、認証・認可コード、Phase 4で特定したシンク、シークレットの取り扱い、およびSecurity Intent Briefの「Suppressed Findings」セクションで参照されているコードを優先します。

Phase A — ファイルレベル分析

対象範囲内のすべてのファイルを確認します。各ファイルについて、次の手順を実施します。

• ファイル全体を読みます。
• references/checklists/ の該当するチェックリストをすべて確認します。Threat Model Briefの「Applicable checklists」項目に、読み込むチェックリストが記載されています。例：認証コードには authn/authz/sessions、シンクに隣接するコードには injection、暗号化 API を呼び出すコードには crypto、アップロード／ダウンロードのエンドポイントには file handling、全般には error/logging などです。アプリケーションの種類に当てはまらないチェックリスト（例：CLI ツールの XSS/CSRF）は省略します。
• 担当範囲に含まれる各言語について、言語固有の落とし穴に関するリファレンス（references/language-footguns/<lang>.md）を読み込みます。ドメイン別チェックリストと並行して、言語固有のチェックも適用します。
• 候補となる指摘事項をSecurity Intent Briefと照合します。概要が、該当箇所における該当パターンを明示的に扱っている場合は省略します。概要に一般的な背景情報はあるものの、個別の事例への言及がない場合は重大度を1段階下げ、意図の出典を記載します。
• 各指摘事項について、ファイルパス、行番号、ドメインカテゴリ、CWE ID、OWASP マッピング（Top 10 および／または API Top 10）、暫定的な重大度、弱点、影響、および具体的な推奨事項を記録します。ファイルをまたぐフローに関わる指摘事項には、Phase Bでの追跡確認が必要であることを明記します。

共有ユーティリティ関数が原因で多数のファイルに現れる場合、同じ論理的な問題を重複して記録しないでください。根本原因の箇所で1件として記録し、影響を受けるすべての箇所を列挙します。

フェーズ B — 信頼境界をまたぐデータフロー

ファイル単位の分析後、フェーズ 4 のマップにあるすべてのソースとシンクの組み合わせをたどります。

• 各ソースについて、バリデーター、サニタイザー、エンコーダー、ORM レイヤー、フレームワークの抽象化、および中間関数を経由して、到達可能なすべてのシンクまでデータフローを追跡します。経路が長い場合は、推測せずに呼び出しグラフをたどってください。
• 各ステップで、次の点を評価します。データの型、長さ、形式、範囲は検証されていますか？最終的なシンクに適したサニタイズは行われていますか（HTML エンコード、SQL パラメーター化、シェル用の引用符処理、パスの正規化など）？適切な境界で認可チェックが行われていますか（通常は状態変更の後ではなく前）？信頼の移行は明示的ですか（例：sanitize、escape、parameterize という名前の関数を使用）、それとも暗黙的ですか（想定に依存）？
• 二次的な汚染に特に注意してください。データベースから読み込まれたデータが、もともとユーザーの制御下にあった場合に発生する問題です（保存型 XSS、二次 SQL インジェクション、保存コンテンツによるログインジェクションなど）。
• 信頼のロンダリングに特に注意してください。ソース値に対するチェックがある一方で、派生値がチェックを回避して使用されるケースです（例：正規化してからチェックする場合と、チェックしてから正規化する場合の違い、ヘッダー解析の不整合など）。
• 正規のエンドポイントだけでなく、保護対象のすべての操作で認可が行われていることを確認します。関連するエンドポイント、一括処理のエンドポイント、GraphQL のフィールドリゾルバー、管理者向けツールでは、同じチェックが見落とされていることがよくあります。
• ビジネスロジックのチェックを適用します（references/checklists/business-logic.md を参照）。状態機械の回避、認可に関する競合状態、二重支払い、金融処理における原子性の不足などを確認してください。
• 多層防御の欠落を確認します。重要な操作を保護するチェックが 1 つだけで、そのチェックが失敗した場合の第二の防御層がないケースです。

新たな検出事項を記録し、ファイル単位で見つかった問題について、ファイル間の文脈を踏まえて影響が変わる場合は重大度を更新します。

エクスプロイトシナリオの作成

暫定評価で High または Critical となった検出事項については、具体的なエクスプロイトシナリオを作成できるか試し、攻撃者の開始時点（攻撃者は誰か）、アクション（具体的にどのようなリクエスト、入力、または一連の操作を行うか）、経路（ソースから結果までのファイル名と行番号の手順）、結果（アクセスされる具体的なデータ、実行されるコマンド、得られる権限）に答えてください。

シナリオを作成できる場合は、「Exploit Scenario」の下に記載します。根本的な弱点は明らかであってもシナリオを作成できない場合（多層防御の欠落、第二層の緩和策、曖昧な信頼境界、監査担当者が捏造できない前提条件の欠落など）は、評価した重大度を維持し、「Exploit Scenario — Not Confirmed」の形式を使用してください。シナリオを作成するのが難しいという理由だけで、High または Critical の重大度を黙って引き下げたり、検出事項を削除したりしないでください。Medium と Low の検出事項では、エクスプロイトシナリオの記載は任意です。

4 つの質問に関するルール、弱点の種類ごとのシナリオテンプレート、「Not Confirmed」テンプレート、および避けるべきアンチパターンの詳細は、references/exploit-scenarios.md を参照してください。

重複の排除

レポートを生成する前に、次の処理を行います。

• 複数の場所で同じ根本原因が現れている検出事項は、影響を受けるすべての場所を記載した 1 つの検出事項にまとめます。
• フェーズ B で判明した誤検知を削除します（例：あるファイルでは入力が未検証に見えたものの、後から見つかったミドルウェアで検証されている場合。該当するルートにそのミドルウェアが実際に適用されることを確認してください）。
• Security Intent Brief に記載された同じトレードオフに由来する検出事項は、意図に関する該当項目を参照する 1 つの検出事項にまとめます。
• 重大度の評価が食い違う場合は、現実的に想定される最悪の「影響 × 悪用可能性 × 露出度」を考慮して調整します。スコアリングマトリクス、脅威モデルの補正要素、および具体例については、references/severity-guide.md を参照してください。

フェーズ 6 — レポートの生成

Format Gate で選択した形式に合うテンプレートに従って最終レポートを生成します。HTML 出力には references/report-template-html.md、Markdown 出力には references/report-template.md を使用します。以下の内容ルールは両方の形式に適用されます。構造上のレンダリング方法は各テンプレートで定義されています。

• レポートの日付を現在の日付に設定します。
• サマリーテーブルに、スコープ、アプリケーションの種類と公開範囲（Threat Model Brief から取得）、監査対象ドメイン、重大度別の検出件数を記載します。
• フェーズ 2 およびフェーズ 3 の出力を要約した「Threat Model」と「Documented Security Posture」のセクションを含めます。
• 読者が分析対象を確認できるよう、フェーズ 4 の列挙結果を要約した「Source/Sink Map」付録を含めます。
• SEC-001 から始まる連番の SEC-NNN 識別子を割り当てます。検出事項は、重大度（Critical を最初に）、次に下記の Reference Index に記載された順のドメインカテゴリ、最後に同じ重大度とカテゴリ内でファイルパスの順に並べます。
• 各検出事項には、識別子、短いタイトル、ドメインカテゴリ、CWE ID、OWASP Top 10 / API Top 10 の対応関係、場所（file:line）、重大度（影響度／悪用可能性／公開範囲の内訳を含む）、説明、影響、悪用シナリオ（または High／Critical の場合は「Not Confirmed」とする説明）、推奨事項を記載します。CWE／OWASP の参照には references/owasp-cwe-mapping.md を使用し、該当する中で最も具体的な CWE を選択します。
• 選択したテンプレートのファイル名規則（HTML の場合は SECURITY-AUDIT-REPORT-YYYY-MM-DD.html、Markdown の場合は SECURITY-AUDIT-REPORT-YYYY-MM-DD.md）に従い、プロジェクトルートにレポートを保存します。ファイルがすでに存在する場合は、数値のサフィックスを増やします。

選択した形式が HTML の場合は、さらに次の条件を満たします。

• references/report-template-html.md の構造上の契約に厳密に従います。必須の ID、クラス、data-* 属性は省略できません。このひな形がレポートの解析可能性と再監査時の差分確認を可能にします。
• 情報を補足できる場合は、HTML 固有の表現手段を使用します。複数のサービスまたはマルチテナントアプリケーションでは Threat Model セクションにインライン SVG の信頼境界図を、パスが多数のファイルにまたがる High／Critical のインジェクション検出事項では SVG のソースからシンクへのデータフロー図を使用します。Security Intent Brief のテーマは折りたたみ可能にし、関連する検出事項間にはアンカーによる相互参照を設定します（根本原因の共有、連鎖的な悪用に必要な前提条件など）。本文ですでに関係が明確に伝わる場合は、これらを省略します。

保存後、ファイルパスと結果の簡単な概要をユーザーに伝えます。概要には、Critical の検出件数（該当する場合）、スコアリングに使用したアプリケーションの種類と公開範囲、悪用可能性が確認されていない High の検出事項を含めます。

リファレンス一覧

該当するフェーズが有効になったら、これらのリファレンスを読み込んでください。SKILL.md の本文では、意図的にこれらの内容を重複して記載していません。

ワークフローのリファレンス（該当するフェーズに入ったときに読み込みます）：

• references/threat-modeling.md — フェーズ 2 のブリーフテンプレートと推論ヒューリスティック。
• references/intent-discovery.md — フェーズ 3 のサブエージェント用プロンプトとブリーフテンプレート。
• references/source-sink-mapping.md — フェーズ 4 の列挙ヒューリスティック。
• references/exploit-scenarios.md — フェーズ 5 のエクスプロイトシナリオの構築。
• references/severity-guide.md — 影響度 x エクスプロイト可能性 x 曝露度のスコアリング。
• references/owasp-cwe-mapping.md — OWASP および CWE タグのクイックリファレンス。
• references/report-template.md — ユーザーが Markdown を選択した場合のフェーズ 6 のレポート形式。
• references/report-template-html.md — ユーザーが HTML を選択した場合のフェーズ 6 のレポート形式（デフォルト）。

ドメイン別チェックリスト（脅威モデルブリーフで該当するとされたもののみ読み込みます）。レポートの標準的なドメインカテゴリの並べ替え順に沿って選択しやすいよう、グループ化しています。

アイデンティティとアクセス：

• references/checklists/auth-and-session.md
• references/checklists/authorization.md
• references/checklists/secrets-and-keys.md

入力処理とインジェクション：

• references/checklists/injection.md
• references/checklists/xss-csrf-frontend.md
• references/checklists/ssrf-redirect-url.md
• references/checklists/deserialization.md
• references/checklists/file-handling.md

横断的な懸念事項：

• references/checklists/crypto.md
• references/checklists/error-and-logging.md
• references/checklists/business-logic.md
• references/checklists/api-security.md

インフラストラクチャとサプライチェーン：

• references/checklists/dependencies.md
• references/checklists/containers-iac.md
• references/checklists/cicd.md

言語固有の注意点（対象範囲で検出された言語ごとに 1 つ読み込みます）：

• references/language-footguns/python.md
• references/language-footguns/javascript-typescript.md
• references/language-footguns/java-kotlin.md
• references/language-footguns/go.md
• references/language-footguns/ruby.md
• references/language-footguns/php.md
• references/language-footguns/csharp-dotnet.md
• references/language-footguns/rust.md
• references/language-footguns/c-cpp.md