vulnerability-triage-brocards

脆弱性トリアージのブロカード

より詳細な分析にリソースを投入する前に、7つの原則に基づく基準に照らして、報告された脆弱性を体系的に評価します。各ブロカードは反証可能なテストです。いずれかのブロカードに不合格となった報告は、理由を記録して却下するか、説明を求めてください。7つすべてを通過した報告は、エスカレーションしてください。

7つのブロカードは、William Woodruff の 「脆弱性トリアージのためのブロカード」 （2026）をもとにしています。

使用する場面

• 人によるレビューの前に、エージェント型の脆弱性発見パイプラインからの検出結果を絞り込む場合――主な用途です。自動実行の大半では、1つ以上のブロカードに不合格となる検出結果が生成されるため、監査担当者の時間をかけずに却下できます
• ToB 監査中に検出結果をトリアージし、どれを PoC 開発にエスカレーションするか判断する場合
• 監査中のコードベースに対して、サードパーティの CVE やアドバイザリを評価し、契約の対象範囲に影響するかどうか判断する場合
• ToB のオープンソースプロジェクトに対するバグバウンティの提出や外部からの脆弱性報告をレビューする場合
• 報告された CVE を却下するか優先度を下げるようクライアントに推奨する際、構造化された、根拠を示せる理由を提示する場合

使用しない場面

• 監査中に新たなバグを探す場合――他のスキルを使用してください
• 確認済みの検出結果の悪用可能性を証明する場合――専用の PoC／悪用可能性スキルを使用してください
• C/C++ のファザーによるクラッシュをトリアージする場合――専用のクラッシュトリアージスキルを使用してください

パイプライン内の位置

このスキルは、自動検出と人によるレビューの間にある品質ゲートです。トリアージを通過した検出結果は、PoC 開発と正式なレポート作成に進みます。

flowchart TD
    A([agentic vulnerability discovery]) -->|raw findings| B[vulnerability-triage-brocards]
    B -->|DISMISS| C([Document brocard # and reasoning])
    B -->|NEEDS-MORE-INFO| D([Request specific evidence])
    B -->|ACCEPT| E[PoC / exploitability proof]
    E --> F[vulnerability report writeup]

トリアージのワークフロー

報告された脆弱性ごとに、7つのブロカードすべてを順番に評価します。デフォルトでは、最初の「却下」判定で評価を止め、その判定を報告します。ユーザーが完全な評価を求めた場合は、途中で不合格となっても7つすべてのブロカードを評価します。各ブロカードについて、次の3つの判定のいずれかを記録します。

• 合格（PASS）――報告はこのテストを通過します
• 却下（DISMISS）――報告はこのテストに不合格です。理由を記録してください
• 追加情報が必要（NEEDS-MORE-INFO）――評価するには証拠が不足しています。不足している情報を明記してください

ブロカード 1：脅威モデルなしに脆弱性なし

一貫した脅威モデルがない報告は却下してください。報告では、（a）攻撃者は誰か、（b）攻撃者が持つ能力は何か、（c）攻撃者がその挙動をどのように悪用するか、（d）その結果どのような被害が生じるか、を明確に説明する必要があります。

コードの挙動を説明していても、それを攻撃者が到達可能な被害に結び付けていない報告は、このブロカードに不合格です。

**簡易テスト：**報告は「[能力]を持つ攻撃者が[影響]を実現するために[アクション]を実行できる」と答えられますか？答えられない場合は、却下するか説明を求めてください。

ブロカード 2：天から降ってくる攻撃なし

脆弱性を引き起こすために必要な攻撃者の能力が、脆弱性そのものの影響と同等以上である報告は却下してください。攻撃者が、エクスプロイトによって得られる権限をすでに持っていなければならないなら、その脆弱性は冗長です。

**簡易テスト：**エクスプロイトの実行には、その影響をすでに包含する能力が必要ですか？必要な場合は却下してください。

ブロカード 3：利用されない箇所に脆弱性なし

理論上は可能でも、実際のソフトウェアの使用時には発生しない挙動を説明する報告は却下してください。脆弱なコードパスに、実際の環境で到達可能かどうかを確認します。

**簡易テスト：**実際の呼び出し元が、脆弱なコードパスを実行していますか？実行していない場合は却下してください。報告がライブラリを対象としている場合は、下流での利用状況を確認すべきか尋ねてください。

ブロカード 4：標準どおりの動作による脆弱性はない

仕様に正しく準拠した実装の結果として生じる動作についての報告は却下します。脆弱性があるとすれば、それは実装ではなく標準にあります。

留意点： 実装が標準で求められる以上に厳格な対応を自発的に採用し、その厳格さが破られた場合は、標準がその動作を許容していても、実装には脆弱性があります。

簡易テスト： 仕様はこの動作を要求または許容していますか？ そうであれば、報告が対象としているのはコードではなく標準です。

ブロカード 5：文書化された動作による脆弱性はない

明示的に文書化された動作、特に文書にセキュリティ上の影響や使用上の注意が含まれている動作についての報告は却下します。

留意点： 下流での使用が文書化されたガイドラインに違反している場合、脆弱性があるのは文書化されたコンポーネントではなく、下流のプロジェクトである可能性があります。

簡易テスト： プロジェクトの文書にこの動作が記載され、誤用への警告がありますか？ そうであれば、プロジェクト自体に対する報告は却下します。

ブロカード 6：病気より悪い治療法はない

脆弱性そのものより大きな害をもたらす修正が必要となる報告は却下します。次の点を評価してください：（a）実際の脆弱性の深刻度、（b）提案された修正にかかるコストと、その修正による混乱、（c）修正の影響範囲（依存関係グラフ、エコシステムへの影響）。

簡易テスト： 修正によって、脆弱性そのものより大きな混乱が生じますか？ そうであれば、報告を却下するか、深刻度を引き下げます。

ブロカード 7：報告は必要条件でも十分条件でもない

CVE 識別子や正式な報告があっても、脆弱性の存在が証明されるわけではありません。反対に、報告がないことも安全の証明にはなりません。報告のメタデータとは切り離して、技術的な妥当性を評価してください。

簡易テスト： CVE 番号と CVSS スコアを取り除いてください。技術的な説明だけで対応が正当化されますか？ 権威ではなく、証拠に基づいて判断してください。

出力形式

7 つすべてのブロカードを評価した後、構造化されたトリアージの概要を作成してください。

## Triage Summary: [Report ID or Title]

| # | Brocard | Verdict | Rationale |
|---|---------|---------|-----------|
| 1 | Threat Model | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 2 | Exploit from the Heavens | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 3 | Outside of Usage | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 4 | Standard Behavior | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 5 | Documented Behavior | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 6 | Cure Worse Than Disease | PASS/DISMISS/NEEDS-MORE-INFO | ... |
| 7 | Report Sufficiency | PASS/DISMISS/NEEDS-MORE-INFO | ... |

**Overall Verdict:** ACCEPT / DISMISS / NEEDS-MORE-INFO
**Reasoning:** [1-3 sentence justification]
**Next Step:** [escalate to PoC development / request info / close]

却下すべき合理化

次のような、妥当な指摘を誤って却下すること、または無効な指摘を誤って受け入れることにつながる思考上の誤りに注意してください。

妥当な指摘を誤って却下するケース

• 「デバッグモードでしか到達できない」――デバッグモードが本当に本番環境で一度も有効にならないことを確認してください。多くのクライアントはデバッグフラグが有効な状態で出荷されています。
• 「攻撃者にはローカルアクセスが必要だ」――ローカルアクセスは、多くのデプロイ環境、特にコンテナ化されたサービスでは、現実的な脅威モデルです。
• 「その API を使っている人はいない」――思い込みではなく、実際の使用状況データで確認してください。クライアントの統合テストとデプロイ設定を調べてください。
• 「仕様が許容している」――実装が、仕様で求められる以上に厳格な動作を謳っていないか確認してください。

無効な指摘を誤って受け入れるケース

• 「CVE があるから、本物の脆弱性に違いない」――そのためにブロカード 7 があります。
• 「CVSS スコアが高い」――CVSS は計算式であり、判決ではありません。
• 「念には念を入れて」――ブロカード 6 に従い、修正コストを評価してください。
• 「悪用できないと証明できない」――脅威モデルを実証する責任は報告者にあります（ブロカード 1）。
• 「ほかのプロジェクトは修正した」――プロジェクトによって使用パターンが異なる場合があります（ブロカード 3）。
• 「報告を水増しするために含めるべきだ」――ToB レポートは検出件数の目標ではなく、技術的な実態を反映するものです。根拠を明記して却下した報告は、最終成果物に誤検知を含めるより価値があります。

詳細な参考資料

各ブロカードの詳しい説明、例、例外的なケースについては、references/brocards-detail.md を参照してください。