vuln-report

脆弱性レポート

概要

確認済みのバグ1件について、開示にそのまま使用できるレポートを1件作成してください。レポートは証拠に基づき、具体的かつ簡潔にまとめてください。references/report-template.mdのセクション順と表現ルールを優先してください。

ワークフロー

1. レポートがバグ1件のみを対象としていることを確認します。
2. 問題を証明するために必要な最小限の事実を抽出します。
   • 脆弱なコンポーネントまたは動作
   • 攻撃者が制御できる入力、または欠落している検証
   • 前提条件と信頼境界
   • エクスプロイトの結果
   • 実際に生じうる影響
   • 最も確実な再現手順
   • 決定的なソースコードの箇所と、関連する修正コミット
3. 実証された事実と推論を区別します。前提がある場合は明示します。
4. references/report-template.mdで指定されているセクション順に従ってレポートを作成します。
5. 決定的なコードパスからのフェンス付きコードスニペットを、必ず1つ以上含め、各スニペットが何を証明するのか説明します。
6. リポジトリのファイル参照とパッチ参照は、必ずGitHubのMarkdownリンクに変換します。また、リンクを個別に列挙するのではなく、周囲の説明に直接埋め込むことを優先します。
7. 正確性やトリアージの価値を実質的に高める任意のセクションのみを追加します。
8. 最終レポートは、バグの重大度識別子（C1、H1、M1など）に続けて、最終レポートのタイトルを小文字のハイフン区切りにしたスラッグを付けたフォルダー内に、report.mdとして保存します。CriticalにはC、HighにはH、MediumにはMを使用し、同じ重大度のバグが複数ある場合は連番にします。例：C1-cross-site-websocket-hijacking-re-enabled-by-allow-websocket/report.md。また、バグレポートのタイトルと内部参照には、このIDを使用してください（例：[C1] クロスサイトWebSocketハイジャッキング）。Lowの重大度の指摘についてはレポートを作成せず、概要表にのみ記載します。
9. 最終化する前に、冗長な表現、曖昧な表現、裏付けのない主張を削除します。

必須セクション

必ず以下のセクションをこの順番で含めます。

1. Summary
2. Details
3. Root Cause
4. Proof of Concept (PoC)
5. Impact

リポジトリですでにTechnical Detailsの下にRoot Causeを配置する形式が使われている場合は、そのローカルな形式を維持します。そうでない場合は、Root Causeを独立したセクションとして扱います。

証拠に関するルール

• レポートには、通常はDetailsまたはRoot Causeで、フェンス付きコードスニペットを1つ以上含めます。
• バグを証明できる最小限のスニペットを使用します。
• 引用するコードの箇所は、それが重要である理由を簡潔に説明してから示します。説明なしにリンクだけを列挙してはいけません。
• リポジトリがGitHub上にあり、リンク先のURLがわかるか導出できる場合は、ソースファイル、行アンカー、コントローラー、ヘルパー、パッチコミット、影響を受ける箇所にGitHubのMarkdownリンクを追加します。
• GitHubのソースリンクを作成するときは、今後のコミット後もリンクが安定するよう、mainやmasterなどのブランチ名ではなく、最新のコミットSHA（git rev-parse HEADから取得するか、コンテキスト内で確認できる最新のコミット）を使用します。
• build_requestが検証なしに攻撃者制御の入力を読み取っています。build_requestの次のコードをご覧ください。のように、説明文にインラインMarkdownリンクを埋め込むことを優先します。
• GitHub以外の標準や仕様への引用は、通常のMarkdownリンクのままにします。

自己完結型のルール

report.md は開示可能な成果物です。読者は、関連する作業ファイル（下書き、議論の記録、レビューのメモ、内部メタデータ）を開かなくても、脆弱性、トレース、影響、再現方法を理解できなければなりません。

• See draft.md、See debate.md、See adversarial-review.md、See metadata.json、See pN-NNN for full trace、See AP-NNN、Refer to the draft for impact analysis、for the full trace see ... のような、文章による参照先の案内を書かないでください。その情報がレポートに必要な場合は、本文に直接記載してください。
• 内部フェーズ ID（pN-NNN、p10-NNN、AP-NNN）を引用しないでください。これらはパイプライン管理用の識別子であり、読者向けの参照情報ではありません。
• 関連ファイルへの参照が許可されるのは、レポートとともに提供される実行可能な証拠成果物（例：poc.<ext>、evidence/<file>）のみです。また、概念実証または影響のセクション内に限ります。ログを開くよう案内するのではなく、決定的な行を本文に引用してください。
• コミット SHA に固定されたソースコードへの GitHub リンクは外部証拠であり、後回しにする説明ではありません。これらは必須であり、禁止されていません。
• 最終確定前に、禁止されている上記の表現がないか下書きを確認し、該当箇所があれば内容を本文に直接記載する形に書き換えてください。

セクションのルール

概要

脆弱な動作、攻撃者が制御できる要素、結果を、短い段落で最初に説明してください。明確さが増す場合にのみ、コンポーネント名を記載してください。

詳細

コードパスと保護が機能しない理由を説明してください。認証モード、ステートレスモード、パーサーの動作、MIME の取り違え、トランスポートに関する前提など、関連する条件を含めてください。コードスニペットと、該当する正確なソースコード位置への GitHub Markdown リンクで説明を裏付けてください。

根本原因

設計または実装上の誤りを、焦点を絞った 1 つのサブセクションで説明してください。オリジン検証の欠如、拡張子から導出した MIME を安全であると誤信すること、特定の実行モードでしかポリシーが適用されないことなど、因果関係が明確な表現を優先してください。

概念実証（PoC）

最短で確実に再現できる方法を使用してください。番号付きの手順と、実行可能なリクエスト、コマンド、またはコードブロックを優先してください。期待される結果を明記してください。

影響

深刻度のラベルだけでなく、悪用可能性とその結果を説明してください。どの利用者が影響を受けるのか、攻撃者が何を得るのか、どの環境が最もリスクにさらされるのかを記載してください。

任意のセクション

具体的なトリアージ上の価値が増す場合に限り、任意のセクションを含めてください。

許可される任意のセクションは次のとおりです。

• 冒頭の短いレポートタイトル
• 脆弱性の種類
• CWE
• CVSS ベクトルまたは深刻度の指針
• 攻撃の前提条件または認証の実態
• 影響を受けるサーフェスまたはスコープに関する注記
• 仕様またはガイダンスへの参照
• パッチまたは修正コミットのメタデータ
• 悪用上の制約、デフォルトではない前提、またはデプロイに関する条件

ユーザーから明示的に求められない限り、Affected Components または Remediation のセクションを追加しないでください。

品質基準

• 1 つのレポートにつき、バグは 1 件にしてください。
• 深刻度の接頭辞（C1、H1、M1）を使ってバグに番号を付け、レポートのタイトルとフォルダー名の両方にこの ID を付けてください。深刻度が低い検出事項は個別に報告しません。
• バグ 1 件ごとのレポートを <ID>-<title-slug>/report.md に保存してください。
• 外部の文脈に頼らずにエクスプロイトの流れが理解できるようにし、関連する作業ファイル（draft.md、debate.md、adversarial-review.md、metadata.json）を開かなくても読めることを明示してください。「自己完結型のルール」を参照してください。
• 関連する説明ファイルや内部フェーズ ID（pN-NNN、AP-NNN）を案内する文章は書かないでください。内容を本文に直接記載してください。
• 重要な場合は、正確なファイルパス、エンドポイント、ヘッダー、オプション、モードを使用してください。
• 観測された動作と、可能性の高い影響を区別してください。
• 誇張した表現を避け、実測に基づく深刻度の表現を優先してください。
• ソース資料で使われているリポジトリ固有の用語は維持してください。
• すべてのレポートに、フェンス付きコードスニペットと GitHub Markdown リンクを含めてください。
• 最小限の修正でアドバイザリ、監査結果、メンテナーへの Issue に貼り付けられるレポートにしてください。