vuln-scan

/vuln-scan

ソースツリーを静的に確認し、脆弱性をレビューします。VULN-FINDINGS.json （および人間が読みやすい形式の .md）を生成し、/triage が直接取り込みます。

このスキルはコードを実行しません。 ソースを読み、内容を分析します。 実行によって検証された検出結果（ASAN クラッシュ、PoC の再現）を得るには、 ユーザーに vuln-pipeline run <target> を案内してください。README のステップ 2 を参照してください。

ツールのフォールバック。 専用の Glob ツールと Grep ツールを優先してください。一部のセッションではこれらが 用意されていません。allowed-tools は権限フィルターであり、ローダーではないため、 ここに列挙しても利用可能にはなりません。Glob/Grep が使えない場合は、上記で許可されている読み取り専用の Bash コマンドに切り替えてください。 ファイルの列挙には rg --files <scope> / ls -R、検索には rg -n / grep -rn、 内容の確認には wc / head / file を使います。これらだけが許可されている Bash コマンドです。補助スクリプトを作成したり、対象の内容をシェルインタープリターに パイプしたりしないでください。

引数

• <target-dir>（必須）— スキャンするディレクトリ。相対パスまたは絶対パスを指定します。
• --focus <area> — 指定した注目領域のみをスキャンします（複数指定可）。偵察を省略します。
• --single — サブエージェントへの並列委譲を行わず、1 回の逐次パスで処理します。小規模な対象や プロンプトのデバッグ時に使用します。
• --extra <file> — <file> の内容をレビュー概要に追加します （カテゴリ一覧の後に追加）。組織固有の脆弱性クラス、コンプライアンスチェック、 またはスタック固有のパターンを追加する場合に使用します。プレーンテキストで、以下のカテゴリブロックと 同じ形式にしてください。
• --no-score — ステップ 3b の信頼度評価を省略します（サブエージェントの作業を 1 回分節約します）。検出結果には スキャナーが自己申告した信頼度のみが残ります。

ステップ 1 — 範囲の決定

1. <target-dir> を解決します。存在しない場合、またはソースファイルがない場合は、エラーで停止します。
2. <target-dir>/THREAT_MODEL.md を探します。存在する場合は、セクション 3「Entry points & trust boundaries」の表とセクション 4「Threats」の表を解析し、注目領域と脅威クラスを特定します。これを優先的な範囲指定の入力とします。
3. THREAT_MODEL.md がなく、--focus も指定されていない場合は、簡易偵察を行います。ソースツリーを一覧表示し、 エントリーポイントとディスパッチコードを読み、次の形式で 3〜10 個の注目領域を提案します。 <subsystem> (<function/file>) — <key operations>。 harness/prompts/recon_prompt.py と同じ形式です。
4. --focus が指定されている場合は、その内容をそのまま使用します。

並列処理に移る前に、スキャンする注目領域とソースファイル数をユーザーに伝えてください。

ステップ 2 — 並列処理

--single が指定されていない限り、注目領域ごとに Task サブエージェントを 1 つずつ並列で起動します。 同時実行数は最大 10 です。各サブエージェントには、注目領域を記入した以下のレビュー概要を渡します。対象が小規模（ソースファイル 15 個未満）の場合は、自動的に --single に切り替えます。

レビュー概要（サブエージェントごと）

You are conducting authorized static security review of source code. Your
focus area: **{focus_area}**. Other agents cover other areas; duplication
is wasted effort.

TARGET: {target_dir}
TRUST BOUNDARY: {from THREAT_MODEL.md section 3, or "untrusted input → process memory"}

TASK: read the source in your focus area and identify candidate
vulnerabilities. This is static review — do NOT build, run, or probe
anything. Reason from the code.

REPORTING BAR: report anything with a plausible exploit path. Skip style
concerns, best-practice gaps, and purely theoretical issues with no attack
story at all — but if you're unsure whether something is real, REPORT IT
with a low confidence score rather than dropping it. A downstream triage
step does the rigorous verification; your job is to not miss things.

WHAT TO LOOK FOR:

  MEMORY SAFETY (C/C++ and unsafe/FFI blocks) — HIGH VALUE:
  - heap-buffer-overflow / stack-buffer-overflow / global-buffer-overflow
  - heap-use-after-free / double-free
  - integer overflow feeding an allocation or index
  - format-string bugs
  - unbounded recursion or allocation driven by untrusted size fields

  INJECTION & CODE EXECUTION — HIGH VALUE:
  - SQL / command / LDAP / XPath / NoSQL / template injection
  - path traversal in file operations
  - unsafe deserialization (pickle, YAML, native), eval injection
  - XSS (reflected, stored, DOM-based) — but see React/Angular note below

  AUTH, CRYPTO, DATA — HIGH VALUE:
  - authentication or authorization bypass, privilege escalation
  - TOCTOU on a security check
  - hardcoded secrets, weak crypto, broken cert validation
  - sensitive data (secrets, PII) in logs or error responses

  LOW VALUE — note briefly, keep looking:
  - null-pointer deref at small fixed offsets with no attacker control
  - assertion failures / clean error returns (correct handling, not a bug)

DO NOT REPORT (common false positives — skip even if technically present):
  - volumetric DoS / rate-limiting / resource-exhaustion — BUT unbounded
    recursion, algorithmic-complexity blowup, or ReDoS driven by untrusted
    input ARE reportable
  - memory-safety findings in memory-safe languages outside unsafe/FFI
  - XSS in React/Angular/Vue unless via dangerouslySetInnerHTML,
    bypassSecurityTrustHtml, v-html, or equivalent raw-HTML escape hatch
  - findings in test files, fixtures, build scripts, docs, or .ipynb
  - missing hardening / best-practice gaps with no concrete exploit
  - env vars and CLI flags as the attack vector (operator-controlled)
  - regex injection, log spoofing, open redirect, missing audit logs
  - outdated third-party dependency versions

{if --extra <file> was given: append its contents here verbatim}

For each finding you DO report, trace: where does the untrusted input
enter, what path reaches the sink, and what condition triggers it.

OUTPUT — one block per finding, nothing else:

<finding>
<id>F-{focus_idx:02d}-{n:02d}</id>
<file>{relative/path}</file>
<line>{line_number}</line>
<category>{heap-buffer-overflow | use-after-free | integer-overflow | sql-injection | command-injection | path-traversal | deserialization | xss | auth-bypass | hardcoded-secret | ...}</category>
<severity>{HIGH | MEDIUM | LOW}</severity>
<confidence>{0.0-1.0}</confidence>
<title>{one line}</title>
<description>{root cause, attacker control, trigger condition, data flow from entry to sink. Cite line numbers.}</description>
<exploit_scenario>{concrete attack: what input, from where, causing what outcome}</exploit_scenario>
<recommendation>{specific fix: parameterize the query, bounds-check before memcpy, etc.}</recommendation>
</finding>

SEVERITY: HIGH = directly exploitable → RCE, data breach, auth bypass.
MEDIUM = significant impact under specific conditions. LOW = defense-in-
depth.

If you find nothing reportable in your area after a thorough read, emit a
single <finding> with category=none and a one-line note of what you covered.

ステップ 3 — 集約

1. すべてのサブエージェントから <finding> ブロックを収集します。category=none のプレースホルダーは除外します。
2. 簡易重複排除 — 2 つの検出結果が同じ file:line と同じカテゴリを示している場合は、説明が長い方を残し、重複した ID を記録します。（重複排除の本格的な処理は /triage の役割です。ここでは複雑にしすぎないでください。）
3. 安定した ID を、（重大度の降順、ファイル、行）の順に F-001、F-002、... と割り当てます。

ステップ 3b — 信頼度の評価（--no-score の場合は省略）

シグナル品質に基づいて検出結果を順位付けする、手軽なセカンドオピニオンレビューです。 検出結果は削除しません。 この工程では confidence を調整し、人間と /triage がシグナルの強い検出結果を優先して確認できるようにします。以下の概要を使って、 検出結果ごとに Task サブエージェントを 1 つずつ並列で起動します。浅い確認にとどめ、到達可能性の完全な追跡ではなく、再読して評価します。

評価概要（検出結果ごと）

You are giving ONE candidate security finding an independent confidence
score. You are NOT deciding whether to keep it — every finding is kept.
You are deciding how likely it is to survive rigorous triage.

FINDING:
{the full <finding> block}

TARGET: {target_dir} (you may Read/Grep inside it; do NOT execute)

STEP 1 — Re-read the cited code. Open {file} around line {line}. Does the
code actually do what the description claims?

STEP 2 — Check against common false-positive patterns (volumetric DoS,
memory-safe language, test/fixture/doc file, framework auto-escape, env-var
vector, missing-hardening-only, regex/log injection, outdated dep). A match
lowers confidence sharply but does not auto-zero it.

STEP 3 — Score 1-10 that this is a real, actionable vulnerability:
  1-3  likely false positive or noise
  4-5  plausible but speculative
  6-7  credible, needs investigation
  8-10 high confidence, clear pattern

OUTPUT (exactly this, nothing else):
  CONFIDENCE: <1-10>
  REASON: <one line>

解決方法： 各検出結果の confidence を評価スコア（0.0〜1.0 に正規化）で上書きし、 confidence_reason を付加します。検出結果を（confidence の降順、severity の降順、file、line）で 並べ替え、その順に ID を F-001.. と再割り当てします。概要行に記載する low_confidence_count として、confidence < 0.4 の検出結果数を算出します。

Step 4 — 出力を書き込む

以下の両方のファイルを <target-dir>/ に書き込みます。

VULN-FINDINGS.json — /triage の取り込み形式：

{
  "target": "<target-dir>",
  "scanned_at": "<iso8601>",
  "focus_areas": ["..."],
  "findings": [
    {
      "id": "F-001",
      "file": "relative/path.c",
      "line": 123,
      "category": "heap-buffer-overflow",
      "severity": "HIGH",
      "confidence": 0.9,
      "title": "...",
      "description": "...",
      "exploit_scenario": "...",
      "recommendation": "...",
      "confidence_reason": "..."
    }
  ],
  "summary": {"total": 0, "high": 0, "medium": 0, "low": 0, "low_confidence": 0}
}

検出結果は confidence の降順（次に severity、file、line）で並べ替えられるため、ファイルの先頭に最も有力な情報が記載されます。

VULN-FINDINGS.md — 人が読みやすい形式：要約テーブル（id | severity | category | file:line | title）に続いて、各検出結果について説明全文を含む ### F-NNN セクションを記載します。

Step 5 — 結果を返す

ユーザーに以下を伝えます。

1. 件数：検出結果 N 件（H/M/L の内訳、確信度が低いもの X 件）、対象となった重点領域 K 件、ソースファイル M 件。
2. 確信度上位 3 件を、それぞれ 1 行で記載します。
3. 次のステップ：> /triage <target-dir>/VULN-FINDINGS.json --repo <target-dir>
4. これらは静的解析による候補であり、検証済みではないことを念押しします。実行によって検証されたクラッシュについては、vuln-pipeline run <target> を使用します（README の Step 2）。

制約

• 対象コードを実行しないでください。 Bash、ビルド、docker、ネットワークは使用しません。 ユーザーから「再現」や「PoC で確認」を求められた場合は断り、vuln-pipeline を案内します。
• 行番号を捏造しないでください。 出力するすべての file:line は、Read または Grep で確認したものに限ります。正確な行番号が不明な場合は、関数を引用し、説明の中でその旨を伝えます。
• <target-dir> 内にとどまってください。 シンボリックリンクをたどったり、.. を使って範囲外に移動したりしないでください。
• 検出結果は /triage に渡す候補であり、最終的な判定ではありません。このスキルでは検出結果を除外しません。Step 3b では順位付けのみを行います。厳密な N 票による検証を行い、誤検出を実際に除外するのは /triage です。

出典

重点領域の調査パターンとメモリ安全性の品質ティアは、このリポジトリ独自の harness/prompts/find_prompt.py と harness/prompts/recon_prompt.py を参考にしています。自律型パイプラインで使用されるのと同じロジックを、静的に適用しています。より広範なカテゴリ一覧、報告禁止の除外項目、検出結果ごとの確信度評価、および exploit_scenario／recommendation 出力フィールドは、anthropics/claude-code-security-review の /security-review コマンドを参考にしています。