analyze-findings

スキル：検出結果の分析

検出結果ファイルには、1 つのルールによるすべての結果がまとめられています。各結果のコードフローを読み、まとまりを個別の脆弱性に分け、それぞれの根拠に基づいて TP／FP の判定を行います。

入力

呼び出し元から提供されます。省略された場合は既定値を使用してください。必須の入力が欠けており、適切な既定値もない場合にのみ、確認してください。

• project-root（任意）— 対象プロジェクトのルート。Opentaint はすべての分析成果物を固定の <project-root>/.opentaint/ ディレクトリ以下に保持するため、以下のすべての .opentaint/... パスはここを基準に解決されます。既定値：カレントディレクトリ
• language（必須）— このプロジェクトの対象言語と言語固有の指示
• findings（必須）— トリアージする検出結果ファイル。各 .opentaint/tracking/findings/<name>.yaml には、sarif_hashes 内に 1 つのルールの SARIF 結果がまとめられています

ワークフロー

1. 判定の前に照合する

notes が reconcile で始まる検出結果は、同じルールの他の検出結果がすでにトリアージされた後の再スキャン結果です。多くの場合、新しい脆弱性ではなく、ハッシュが変化した同じ脆弱性です。新規として判定する前に、そのルールでトリアージ済みの検出結果ファイルを読み、フロー（source → sink、実質的に同じ経路）を比較してください。一致するものがあれば、この検出結果の sarif_hashes をその検出結果に移し、このファイルを削除して、引き継いだ判定をそのまま適用します。すでにトリアージ済みのフローを再判定しないでください。トリアージ済みの検出結果に一致するものがない場合にのみ、新規として扱い、以下の手順に進みます。

2. 結果を 1 つずつ確認する — 判定前チェックリスト

まとまり内の各ハッシュについて、判定を行う前に .opentaint/results/report.sarif から生の結果を読み取ってください。

• sarif_hashes を使って、対応する SARIF 結果を見つけます。各エントリは、その結果の vulnerabilitySourceSinkHash／vulnerabilityWithTraceHash フィンガープリントの先頭 16 文字です。fingerprints／partialFingerprints と照合し、生の codeFlows[] を読み取ってください。
• source → 中継点 → sink のすべてのステップをたどり、最初から最後まで同じ汚染値であることを確認します。トレースのテキストだけでなく、アプリケーションのソースコード（ビルドされたプロジェクト独自のソースコードは .opentaint/project/sources/ 以下）および依存コードと照合してフローを確認してください。
• 各結果は個別のトレースに基づいて判定します。同じルールを共有しているという理由だけで、結果間で判定を共有しないでください。

3. まとまりを論理的な検出結果に分割する

ファイル内の結果はすべて同じルールに該当していますが、複数の異なる脆弱性が含まれている場合があります。同じ脆弱性（同じ sink、実質的に同じフロー）の結果は、1 つの検出結果としてまとめてください。明確に異なるものは、それぞれ別の検出結果ファイルに分け、新しい名前を付けて sarif_hashes を設定してください（Tracking を参照）。

4. 分類して記録する

各論理的な検出結果を、そのフローに基づいて判定してください。

• TP — source が攻撃者によって制御されており、その入力に対して sink が実際に危険で、途中でサニタイズされていない
• FP — サニタイザー／バリデーターが無害化している、source が実際には攻撃者によって制御されていない（設定値、定数、サーバー側で設定された値）、sink がこの入力に対して安全である（パラメーター化されている、エスケープされている）、または経路が実行不可能である。該当する理由を記録してください。

verdict を設定し、notes に、すでに記載されているアナライザーのレポートの下へ判定理由を追記してください（Tracking を参照）。

出力

成果物

• .opentaint/tracking/findings/<name>.yaml — verdict を設定し、理由を notes に追記した、トリアージ済みの各検出結果。分割した場合は、新しい検出結果ファイルも作成します（Tracking を参照）。

概要

• 検出結果ごとに 1 行：名前、判定、理由を示す短い句

トラッキング

このスキルが書き込むのは、各検出結果の verdict と、notes に追記する理由だけです。分割すると、新しい検出結果ファイルも作成されます。そのファイルには、新しい docker のような名前、移動した sarif_hashes、バンドルからコピーした rule_id を設定し、シードされたアナライザーのレポートを notes に引き継ぎ、poc は未設定のままにします。poc フィールドや、維持する検出結果の sarif_hashes には決して触れないでください。

.opentaint/tracking/findings/<name>.yaml — 1 つの検出結果を記録します。1 つのルールの SARIF 結果をまとめ、トリアージから PoC まで引き継ぎます。スクリプトはスキャン結果から各ファイルをシードし、sarif_hashes、rule_id、notes 内のアナライザーのレポートを設定します。トリアージでは verdict を設定し、判断理由を追記します。PoC 段階では poc を設定し、その結果を追記します。コメントで明確にしておきます

sarif_hashes: [a1b2c3d4, e5f6a7b8]
rule_id: <language>/security/sql-injection.yaml:sql-injection
verdict: TP
notes: >
  <analyzer report for these results — seeded from the scan>
  triage: the request's order field is attacker-controlled and reaches raw query construction → TP
  poc: a crafted order value produced the expected database delay → confirmed
poc: confirmed

制約

• 判定とメモは検出結果ファイルにのみ記録してください。.opentaint/vulnerabilities.md には決して書き込まないでください。オーケストレーターが判定内容から組み立てます
• 同じルールで検出されたというだけで判定を共有せず、各結果のトレースを個別に評価してください

注意点

• 一括判定は、トリアージで最もよくある誤りです。トレースを読まずに、多数の結果に共通の根拠を適用してしまいます
• 1 つのルールのバンドルが、1 つの検出結果を意味するわけではありません。別個の脆弱性は分割し、本当の重複（同じシンクとフロー）は、複数の sarif_hashes を持つ 1 つの検出結果にまとめてください