finding-triage

Finding Triage — 正当性を説明できる根拠に基づく、単一のFindingの判定

このリポジトリの他のスキルは、すべてFindingを生成します。このスキルは一連の対応を完結させます。単一のFindingについて、それが実在するか、あなたの状況でどの程度の深刻度に値するか、どう対処すべきかを確認します。必要なフィールドと適切な根拠がそろい、6か月後に規制当局が読んでも耐えられる監査証跡を備えた、チケットにそのまま使える記録を作成します。

判定区分は、owasp-auditのThree-Dispositionルールに準拠しています。修正済み（Fixed）、延期（Deferred）、**リスク受容（Accepted Risk）**のいずれかです。誤検知は4つ目に当たります。ただし、実在するFindingに対する判定区分ではなく、そもそもFindingが存在しないという判断です。

このスキルは、SASTの出力、DASTスキャナー、依存関係のアドバイザリー、手動監査、脅威ハンティングでの検出結果、ペネトレーションテスト報告書、ベンダーからの開示、社内レッドチームの報告書、バグバウンティへの提出など、あらゆる情報源のFindingに対応します。

相互参照：

• ここでの到達可能性評価に必要な技術的なCVEの詳細調査については、vuln-researchを参照してください
• owasp-auditのThree-Dispositionルール（このスキルが個々のFindingに対して実装するフレームワーク）
• Findingの内容をセキュリティの文脈から離れて伝える必要がある場合、判定内容を関係者に伝わる表現にするにはsecurity-commsを参照してください
• あらゆる監査スキル：このスキルでは、それらのFindingを入力として使用します

ワークフロー

エージェントはユーザーとともに、以下の手順を進めます。Findingだけではわからない状況をユーザーが把握している場合は、いったん止めて確認してください。

ステップ1 — Findingを自分の言葉で言い換える

スキャナーから報告されたFindingの場合、実際に何が主張されているのかを言い換えてください。スキャナーはノイズを出すため、言い換えることで定型文を取り除けます。

適切な言い換えでは、次の点を明確にします。

• 何が問題なのか（具体的な弱点。該当する場合はCWE）
• どこにあるのか（ファイルと行番号、エンドポイント、リソース ARN、ホスト）
• どのように悪用される可能性があるのか（前提条件、攻撃者に必要な能力）
• 悪用された場合の影響（データ損失、権限昇格、可用性への影響）

明確に言い換えられない場合は、まだ理解できていません。ユーザーに状況を確認してください。

ステップ2 — これは本当に事実ですか？

自動スキャナーのFindingは、件数で見ると半数が誤検知です。以下の手順でトリアージします。

質問	はいの場合	いいえの場合
説明どおりの脆弱なコードパスが存在しますか？	続行	誤検知 — スキャナーが存在しない問題を検出しています
そのコードパスは、攻撃者が制御できる入力から到達可能ですか？	続行	続行しますが、深刻度は下がります
悪用に必要な前提条件は、あなたの環境に当てはまりますか？	続行	深刻度が下がるか、誤検知です
公開PoCがありますか、または実環境での悪用が確認されていますか？	深刻度を維持、または引き上げます	深刻度が下がる可能性があります
既存の制御（WAF、認証、ネットワーク分離）によって悪用を防げていますか？	深刻度が下がり、制御が緩和策になります	深刻度を維持します

よくある誤検知のパターン：

• テストファイルや未使用コードに対するSASTの警告
• devDependenciesにのみ含まれるパッケージに対する依存関係スキャナーの警告 — 実行時には到達不能です（dependency-auditの到達可能性列を参照）
• 実環境では404を返すパスに対するDASTの警告。SPAのルーティングとの混同が原因です
• 古いアドバイザリー — CVEが公開される前にベンダーが修正を非公開で適用しており、使用中のバージョンにはその修正が含まれています
• 脆弱に見えるコードに対するパターンマッチ。該当コードが一度も呼び出されない関数内にあります

誤検知の判定も、実際のFindingと同じように慎重に記録してください。 将来、別のスキャナーや監査担当者が同じ問題を指摘した場合、以前の誤検知の記録によって調査の手間を省けます。

ステップ 3 — コンテキストを踏まえた重大度

スキャナーの CVSS または重大度評価は出発点であり、答えではありません。自分の環境に合わせて調整してください。

評価より重大度を高くする要因：

• 脆弱なエンドポイントが社内向けではなく、インターネットに公開されている
• CVE では「認証済み」が前提でも、アプリでは認証の前提条件を容易に満たせる（誰でも登録可能）
• 脆弱なデータが規制対象である（PII、PCI カード会員データ、PHI）— 悪用された場合、報告義務のあるインシデントとなる
• 公開 PoC が存在する、または実際の悪用が確認されている
• 脆弱なコンポーネントがクリティカルパスにある（すべてのリクエストがそのコンポーネントに触れる）
• 補完的な対策がない、または不十分である

評価より重大度を低くする要因：

• 利用環境では脆弱なコードパスに到達できない（パッチを読み、関数を grep してください — vuln-research を参照）
• 強力な補完的対策がある（WAF がペイロードのパターンをブロックする、ネットワークのセグメンテーションにより到達を防ぐ）
• 悪用には環境に存在しない前提条件が必要である（特定の OS バージョン、特定の設定）
• アプリでは認証の前提条件を満たすのが困難である（登録が制限されている、MFA、従業員のみ）
• コンポーネントが開発専用またはビルド専用であり、実行時に到達できない

重大度の尺度（組織で使っているものを使用してください。以下は一般的な例です）：

レベル	定義
Critical	認証前に悪用可能、またはごく簡単に悪用可能。直ちにデータ損失、RCE、または乗っ取りにつながる。24～72 時間以内にパッチを適用
High	認証が必要だが最小限の権限で足りる。または認証後の経路から重大な影響が生じる。1～2 週間以内にパッチを適用
Medium	相応の権限または複数の脆弱性の連鎖が必要。現実的だが簡単ではない。30 日以内にパッチを適用
Low	多層防御に関する問題。連鎖させるのが困難。90 日以内にパッチを適用
Info	強化または衛生管理に関する事項。動作は文書化済み。都合のよいときにパッチを適用

ステップ 4 — 処置を選択する

処置	選択する場合	必須項目
今すぐ修正（同義語：修正済み）	重大度に応じた SLA 以内にパッチまたは緩和策をデプロイできる	修正内容、デプロイ計画、検証方法
延期	重大度から対応が必要だが、運用上の制約により直ちに修正できない	延期の理由、新しい期限、担当者、期限前に状況が変わった場合のアラート
リスクを受容	現在の設定では修正を予定していない	（1）修正が適用されない理由、（2）補完的な対策、（3）再評価のトリガー
誤検知	実際には脆弱性ではない	判断の根拠、抑制するスキャナールール ID（慎重に扱うこと）

延期について： 延期を決めたからといって、重大度が変わるわけではありません。「重大度 High、Q3 まで延期」と記録するのは誠実な対応です。Q3 が遠いからといって High を Medium に格下げするのは、リスクの隠蔽です。

リスクの受容について： 3 つの項目すべてが必須です。3 つすべてが揃っていない「受容済みリスク」は、実際に存在する指摘を黙って放置している状態です。再評価のトリガーは最も記入漏れが多い項目です。具体的な条件を挙げてください（プランのアップグレード、依存関係の更新、トラフィックパターンの変化、監査の記念日）。

ステップ 5 — 処置を記録する

チケットにそのまま使える記述を作成します。処置に応じて、以下のテンプレートのいずれかを使用してください。

テンプレート：修正

## Finding: [Title]
**Source:** [scanner / audit / advisory]
**Severity:** [contextual] (Scanner reported: [original])
**CWE / CVE:** [if applicable]
**Location:** [file:line / endpoint / resource]

### What
[Plain-English description — what the issue is]

### Why this severity
[Contextual reasoning — what the scanner missed, what your environment adds]

### Fix
[Specific change — code diff, config update, dependency upgrade]

### Verification
[Concrete test — adversarial input + observed result that proves the fix holds]
- Run [command / test case]
- Observe [response / behavior]

### Owner: [name]
### Target deploy: [date]

テンプレート：延期

## Finding: [Title] — DEFERRED
**Severity:** [unchanged]
**Original target:** [original SLA date]
**New target:** [date]

### Why deferred
[Operational constraint — release freeze, dependency on third party, etc.]

### Risk during deferral window
[What's the exposure? What controls reduce it?]

### Alerting / conditions that would escalate
[What would force action sooner than the new target?]

### Owner: [name]
### Re-evaluation: [date — usually before new target]

テンプレート：リスクを受容

## Finding: [Title] — ACCEPTED RISK
**Severity:** [contextual]
**Approver:** [name + role]
**Date accepted:** [date]

### Why fix doesn't apply
[Cost tier, dependency version constraint, deployment topology, vendor limitation, etc. — be specific]

### Compensating controls
- [Control 1 — what it is, why it reduces impact / likelihood]
- [Control 2]
- ...

### Re-evaluation trigger
[Specific condition — plan upgrade, dependency bump, traffic pattern change, calendar anniversary]
- Trigger: [what would change this decision]
- Calendar review: [date — at minimum, annually]

### Approvals
- [ ] Engineering owner: [name, date]
- [ ] Security: [name, date]
- [ ] (if required) Compliance / Legal: [name, date]

テンプレート：誤検知

## Finding: [Title] — FALSE POSITIVE
**Scanner:** [name + rule ID]
**Original severity:** [as reported]

### What the scanner claimed
[Restate the claim]

### Why it's not real
[Specific evidence — code path not reachable, version contains the fix, etc.]

### Suppression decision
- [ ] Suppress this exact finding (location + rule ID)
- [ ] Add allow-list rule (with care — broad suppression breeds blind spots)
- [ ] No suppression — re-evaluate if it returns

### Determination by: [name, date]
### Reviewed by: [name, date — for non-trivial suppressions]

ステップ 6 — 記述を検証する

提出前に、以下を確認してください。

• 12 か月後に自分（または監査担当者）が読んでも、追加のコンテキストなしで判断を理解できますか？
• 検証手順は、作成者以外の人でも実行できるほど具体的ですか？
• リスクを受容する場合、必須の 3 項目すべてに、決まり文句ではなく具体的な内容が記入されていますか（「標準的な対策を実施済み」は補完的な対策ではありません）？
• 重大度は自分の環境を反映していますか。それともスキャナーの既定値をそのまま使っていますか？

エスカレーションするタイミング

単独のエンジニアが独断でトリアージすべきではない検出事項：

• クリティカルなもの
• 認証前に悪用可能なもの
• 規制対象データ（PII／PCI／PHI）に影響するもの
• 公開された PoC があるもの、または現在悪用されているもの
• 対応方針としてリスク受容が提案されており、重大度が高以上のもの

これらは、2人目のレビュー担当者（Tier 3／セキュリティチーム／ポリシーで指定された承認者）による確認が必要です。

出力形式

主な出力は、対応方針を記載した文書そのものです（上記のテンプレート）。複数の検出事項を扱うトリアージセッションや一括インポートの場合は、次のように要約します。

# Finding Triage Session
## Source: [scanner / audit / report]
## Date: [date]
## Triaged by: [name]

### Summary
| Finding | Original severity | Contextual severity | Disposition |
|---------|-------------------|---------------------|-------------|

### Detail
[Per-finding writeup using the appropriate template]

### Escalations
[Findings that need senior review or approval]

制限事項

• このスキルは、ユーザーがトリアージと対応方針の決定を行う権限を持つ検出事項を対象とします
• 重大度の決定とリスク受容の対応方針は、組織のリスク態勢に影響します。重大度が高以上の検出事項では、記載された承認者が実際に承認していることを確認してください。承認を捏造してはいけません
• 誤検知の判定は、証拠に基づいて行ってください。「修正したくない」ことを言い換えたものにしてはいけません。ユーザーが実際の検出事項を誤検知として扱おうとする場合は、異議を唱えてください
• 開示義務や監査義務を避けるために重大度を引き下げることには協力しないでください
• 検出事項によって進行中のインシデントが判明した場合は、incident-triage に引き継いでください。対応方針のトリアージは平常時の検出事項を対象とし、緊急事態には対応しません

参考資料

• CVSS v4.0 仕様 — first.org/cvss
• EPSS — Exploit Prediction Scoring System（FIRST.org）
• NIST SP 800-30（リスクアセスメント実施ガイド）
• 「FAIR」（Factor Analysis of Information Risk）— 金額ベースの判断が必要な場合に使う定量的リスクフレームワーク
• ISO 27005 — リスク管理
• 「Measuring and Managing Information Risk」— Jack Freund、Jack Jones（FAIR の書籍）
• OWASP リスク評価手法