solana-audit

Solana スマートコントラクト監査

トリガー

ユーザーが以下を依頼した場合、このスキルを有効にします。

• Solana プログラムのセキュリティ脆弱性を監査、レビュー、分析する
• Solana スマートコントラクトにバグやエクスプロイトがないか確認する
• solana_program、anchor_lang、pinocchio、#[program]、または #[derive(Accounts)] を含むコードのセキュリティ分析を行う

ワークフロー

フェーズ 0：セットアップと設定

スキャンを開始する前に、監査範囲を定め、既存データを確認します。

ステップ 1 — ユーザーに設定について 3 つ質問する（ユーザーが「そのまま監査して」などと答えた場合は省略します）。

1. 範囲： どのプログラムを監査しますか？（デフォルト：リポジトリ内のすべての Solana プログラム）
   • 回答例：「すべて」、「vault プログラムだけ」、「programs/staking と programs/rewards」
2. 深度： Standard と Deep のどちらにしますか？Standard ではスキャナーエージェントを 4 つ並列実行します。Deep では相互検証用の敵対的エージェントが 1 つ追加されます。（デフォルト：standard）
3. 既知の制約： 許容済みのリスクや信頼に関する前提はありますか？（デフォルト：なし）
   • 回答例：「admin は 3/5 マルチシグです」、「アップグレード権限のリスクは許容します」、「今回は token-2022 を無視してください」

ステップ 2 — 設定を保存する：

${CLAUDE_PLUGIN_DATA} が利用可能な場合：

1. ${CLAUDE_SKILL_DIR}/references/templates/config-template.json を読み、スキーマを確認します。
2. ユーザーの回答を ${CLAUDE_PLUGIN_DATA}/config.json に書き込みます。
3. 以前の監査データを確認します。
   • ${CLAUDE_PLUGIN_DATA}/audit-log.jsonl が存在し、同じプログラムの記録がある場合は、ユーザーに「以前の監査（[date]）が見つかりました。[N] 件の指摘事項が報告されています。」と伝えます。
   • ${CLAUDE_PLUGIN_DATA}/accepted-risks.json が存在する場合は、読み込んだ許容済みリスクをフェーズ 3 で照合します。

${CLAUDE_PLUGIN_DATA} が利用できない場合は、データを永続化せずに続行します。エラーや警告は表示せず、そのまま省略してください。

デフォルト（ユーザーが設定を省略した場合）：scope=all programs、depth=standard、既知の制約なし。

フェーズ 1：調査

references/agents/explorer.md を読み、Agent ツールを使って explorer エージェントを起動します。

エージェント呼び出しの組み立て方：

1. ${CLAUDE_SKILL_DIR}/references/agents/explorer.md を読みます。エージェントのプロンプトは、## Agent Prompt セクションにある 3 連バッククォートの囲みの内側のテキストです。
2. プロンプト内の [Insert: repository path or "full codebase scan"] を、実際の対象パス（フェーズ 0 で指定した範囲、またはリポジトリのルート）に置き換えます。
3. エージェントを起動します。

   Agent(subagent_type="Explore", prompt="<the filled-in prompt>")
   

返される内容：プログラムマップ、命令一覧、アカウント構造、PDA マップ、CPI グラフ、プロトコル種別の分類、LOC 数、脅威モデル。

続行する前に、必ずこのエージェントを起動し、その出力を待ってください。explorer の出力は、共有コンテキストとしてすべてのスキャナーエージェントに渡されます。

適応的な規模判定

explorer エージェントの応答後、プログラムの規模を判定し、スキャン戦略を選択します。

規模	基準	スキャン戦略
小規模	<500 LOC AND <5 instructions	すべてのカテゴリ（A から R）を網羅する単一の統合スキャンエージェントを実行します。CHEATSHEET にあるすべての脆弱性チェックを含むプロンプトをインラインで作成します。個別のエージェントファイルは必要ありません。
中規模	500–2000 LOC	標準の 4 エージェント並列スキャン（以下のフェーズ 2）
大規模	>2000 LOC	標準の 4 エージェント並列スキャン。ユーザーに「大規模なプログラムです。敵対的な相互検証のため、depth: deep での実行をご検討ください。」と伝えます。

小規模プログラムの場合は、以下を含む単一のエージェントプロンプトを作成します。

• explorer の出力をコンテキストとして含める
• スコアリングルールについて ${CLAUDE_SKILL_DIR}/references/scoring.md を参照する
• 30 種類すべての脆弱性について ${CLAUDE_SKILL_DIR}/references/CHEATSHEET.md を参照する
• すべてのカテゴリ（A-1 から R-3）を一度の実行でスキャンするよう指示する
• 個別のスキャナーエージェントと同じ出力形式を使用する
• その後、フェーズ 3 に進み、単一エージェントの出力を使用する

中規模および大規模プログラムの場合は、フェーズ 2 に進みます。

フェーズ 2：並列スキャン

事前スキャン：構文スキャン

スキャナーエージェントを起動する前に、統合構文スキャンを実行します。

1. ${CLAUDE_SKILL_DIR}/references/scripts/scan-commands.md を読みます
2. 対象プログラムのディレクトリに対して grep コマンドを実行します
3. 結果をカテゴリ（A、S、C、M、L、T、R）ごとに整理します
4. カテゴリごとにヒット数を数えます

次の注記をコンテキストの先頭に付けて、構文スキャンの結果をすべてのスキャナーエージェントに渡します。

オーケストレーターによるパス 1（構文スキャン）が完了しました。以下に結果を示します。パス 2 — セマンティックレビューに直接進んでください。

［構文スキャンの結果をカテゴリごとに整理してここに貼り付けます］

これにより、4 つのエージェント間で grep 作業が重複するのを防げます。

スキャナーエージェントの起動

信頼度スコアリングのルールと誤検知ゲートについて、references/scoring.md を読んでください。次に、4 つすべてのエージェントプロンプトファイルを読み、Agent ツールを 4 回同時に呼び出して並列で起動します。

各エージェントの呼び出しを構成する方法：

1. エージェントプロンプトファイル（例：${CLAUDE_SKILL_DIR}/references/agents/auth-state-scanner.md）を読みます。プロンプトは、## Agent Prompt セクション内の三重バッククォートで囲まれた部分です。
2. [INSERT EXPLORER OUTPUT HERE — the full codebase analysis from the explorer agent] を、エクスプローラーエージェントの出力全文に置き換えます。
3. 角括弧で囲まれた参照パス（例：[references/scoring.md]）を、${CLAUDE_SKILL_DIR} を基点とする絶対ファイルパス（例：${CLAUDE_SKILL_DIR}/references/scoring.md）に置き換え、エージェントが直接 Read できるようにします。ファイルの内容をインラインで貼り付けてはいけません。
4. ロジック・エコノミックスキャナーには、エクスプローラーの分類に基づいたプロトコルの種類を指定して、適切なプロトコルリファレンスを読み込めるようにします。
5. 事前スキャンの手順で得られた構文スキャンの結果を、各エージェントのコンテキストの先頭に付けます。

認証スキャナー（references/agents/auth-state-scanner.md）

• カテゴリ A-1～A-5 + S-1～S-8 — 脆弱性タイプ 13 種

CPI スキャナー（references/agents/cpi-math-scanner.md）

• カテゴリ C-1～C-3 + M-1～M-4 — 脆弱性タイプ 7 種

ロジックスキャナー（references/agents/logic-economic-scanner.md）

• カテゴリ L-1～L-4 + T-1～T-3 — 脆弱性タイプ 7 種
• エクスプローラーの分類に基づいて、プロトコル固有のリファレンスを読み込みます

フレームワークスキャナー（references/agents/framework-scanner.md）

• フレームワーク固有のチェック（Anchor／Native／Pinocchio）+ R-1～R-3

4 つすべてを 1 回の応答で起動します。

Agent(prompt="<auth-state-scanner prompt with explorer output + syntactic scan results inserted>")
Agent(prompt="<cpi-math-scanner prompt with explorer output + syntactic scan results inserted>")
Agent(prompt="<logic-economic-scanner prompt with explorer output + syntactic scan results inserted>")
Agent(prompt="<framework-scanner prompt with explorer output + syntactic scan results inserted>")

各エージェントは、分類 ID、ファイルと行番号、根拠、攻撃経路、信頼度スコア、誤検知ゲートの結果を含む候補を返します。

DEEP モード（ユーザーが詳細／ディープ監査を依頼した場合、または設定の depth=deep の場合）：4 つのスキャナーが完了した後、references/agents/adversarial-scanner.md に従って、5 つ目の敵対的エージェントも起動します。相互検証のために、エクスプローラーの出力と統合したスキャナーの検出結果を渡します。

Phase 3: 検証と反証

1. すべてのエージェント候補リストを統合します
2. 根本原因ごとに重複を排除します。2つのエージェントが同じ根本原因を指摘した場合は、信頼度の高い方を残します。同じ場所を異なる分類 ID で指摘している場合は、両方を残します。
3. 信頼度スコアの高い順に並べ替えます。連番を振り直します（VULN-001、VULN-002、...）。
4. 承認済みリスクを確認します。Phase 0 で accepted-risks.json を読み込んでいる場合、各指摘を taxonomy_id + file で照合します。一致する指摘には、保存されている理由とともに「Previously Accepted」のマークを付けます。レポートには引き続き含めますが、新規の指摘としては数えません。
5. 反証します。各エージェントはすでに FP Gate（具体的なパス、到達可能なエントリ、緩和策がないこと）を適用済みです。残りの候補について、次の2つの追加防御策を確認します。
   • 悪用にかかるコストが、攻撃者の得られる利益を上回りますか？（経済的に実行不可能）
   • 攻撃ベクトルを阻止するオフチェーンコンポーネント（keeper、multisig、timelock）はありますか？ いずれかの防御策が有効な場合は、該当する指摘を削除するか、それに応じて信頼度を下げます。
6. references/exploit-case-studies.md と照合します。既知の悪用パターンに一致しますか？
7. 確認された各指摘の分類 ID に対応する個別の参照ファイル（例：references/missing-signer-check.md）を参照し、詳細な修正ガイダンスを確認します
8. references/audit-checklist.md §Severity Calibration の調整表を使用して深刻度を評価します

Anchor プログラムの場合は、フレームワーク固有の注意点について references/anchor-specific.md も参照してください。

Phase 4: レポート

最終監査レポートを作成します。すべての指摘に、references/vulnerability-taxonomy.md の分類 ID と信頼度スコアを必ず含めてください。

指摘が1件以上ある場合は、標準レポートテンプレートを使用します。

# Security Audit Report: [Program Name]

## Executive Summary
- Audit date, scope (files, instructions, LOC)
- Framework: Native / Anchor / Pinocchio
- Protocol type: [from explorer classification]
- Methods: Parallel agent scan (4 agents + adversarial), confidence-scored validation
- Finding counts by severity: X Critical, Y High, Z Medium, W Low, V Informational
- Confidence threshold: 75/100

## Methodology
- Phase 0: Scope configuration and prior audit check
- Phase 1: Codebase exploration (program map, CPI graph, threat model)
- Phase 2: Pre-scan syntactic analysis + parallel scan — 4 agents across 30 vulnerability types across 7 categories
- Phase 3: Merge, deduplicate by root cause, accepted risk check, devil's advocate falsification
- Phase 4: Confidence-scored report
- Reference: vulnerability taxonomy based on Wormhole, Cashio, Mango, Neodyme, Crema exploits

## Findings

### [CRITICAL] VULN-001: Title (Confidence: 95/100)
**File:** path/to/file.rs:line
**Category:** A-1 (Missing Signer Check)
**Description:** ...
**Attack Path:** caller → instruction → state change → impact
**Impact:** ...
**Recommendation:** ...
**Fix:**
```rust
// Remediation code (framework-specific)
```

### [HIGH] VULN-002: Title (Confidence: 80/100)
**File:** path/to/file.rs:line
**Category:** S-7 (Reinitialization)
...

---
### Below Confidence Threshold
---

### [MEDIUM] VULN-003: Title (Confidence: 60/100)
**File:** path/to/file.rs:line
**Category:** M-2 (Division Precision Loss)
**Description:** ...
**Impact:** ...
*(No fix recommendation — below confidence threshold)*

## Summary Table
| ID | Title | Severity | Category | Confidence | File | Status |
|---|---|---|---|---|---|---|
| VULN-001 | Missing Signer Check | Critical | A-1 | 95 | lib.rs:16 | Open |
| VULN-002 | Reinitialization | High | S-7 | 80 | lib.rs:11 | Open |
| --- | Below Confidence Threshold | --- | --- | <75 | --- | --- |
| VULN-003 | Division Precision Loss | Medium | M-2 | 60 | math.rs:45 | Open |

## Appendix
- Complete file listing reviewed
- Vulnerability taxonomy reference
- Explorer output (program map, CPI graph, threat model)

指摘が0件の場合（問題のない監査）は、次の代替テンプレートを使用します。

# Security Audit Report: [Program Name]

## Executive Summary
- **Result: No vulnerabilities identified**
- Audit date, scope (files, instructions, LOC)
- Framework: Native / Anchor / Pinocchio
- Protocol type: [from explorer classification]
- Methods: Parallel agent scan (4 agents), confidence-scored validation
- Finding counts: 0 Critical, 0 High, 0 Medium, 0 Low, 0 Informational

## Methodology
- Phase 0: Scope configuration and prior audit check
- Phase 1: Codebase exploration (program map, CPI graph, threat model)
- Phase 2: Pre-scan syntactic analysis + parallel scan — 4 agents across 30 vulnerability types across 7 categories
- Phase 3: Merge, deduplicate, devil's advocate falsification
- Phase 4: Confidence-scored report

## Categories Reviewed

All 7 categories (30 vulnerability types) were scanned:

| Category | IDs | Types Checked | Findings |
|----------|-----|---------------|----------|
| A: Authentication & Authorization | A-1..A-5 | 5 | 0 |
| S: Account & State Management | S-1..S-8 | 8 | 0 |
| C: Cross-Program Invocation | C-1..C-3 | 3 | 0 |
| M: Arithmetic & Math | M-1..M-4 | 4 | 0 |
| L: Logic & Economic | L-1..L-4 | 4 | 0 |
| T: Token-Specific | T-1..T-3 | 3 | 0 |
| R: Runtime & Deployment | R-1..R-3 | 3 | 0 |

## Scope
- Files reviewed: [list]
- Instructions analyzed: [count]
- Lines of code: [LOC]

## Disclaimer

A clean audit report does not guarantee the absence of vulnerabilities. This audit covers the 30 vulnerability types in the solana-audit taxonomy and is limited to static analysis of the on-chain program source code. It does not cover:
- Off-chain components (frontends, keepers, bots)
- Economic modeling or game-theoretic analysis beyond basic checks
- Deployment configuration (actual on-chain upgrade authority, program data account state)
- Vulnerabilities outside the taxonomy scope
- Bugs introduced after the audit date

## Appendix
- Complete file listing reviewed
- Vulnerability taxonomy reference
- Explorer output (program map, CPI graph, threat model)

レポートのルール：

• すべての指摘に、分類 ID（例：A-1、S-7、C-1）を記載した **Category:** 行を必ず含めてください
• すべての指摘に **Confidence:** スコアを必ず含めてください
• 信頼度が75以上の指摘には、フレームワーク固有の修正コードを必ず含めてください
• 信頼度が75未満の指摘は、修正コードなしで Below Confidence Threshold の区切りより下に記載してください
• 各深刻度グループ内で、信頼度の高い順に並べてください
• Summary Table に Category 列と Confidence 列を必ず含めてください
• Recommendations にはフレームワーク固有の修正策（例：Signer<'info>、Account<'info, T>、close = destination）を必ず含めてください

監査結果の保存

レポートの生成後、${CLAUDE_PLUGIN_DATA} が利用可能な場合は結果を保存します。

1. スキーマを確認するため、${CLAUDE_SKILL_DIR}/references/templates/audit-log-schema.md を読み込みます
2. 次の情報を含む JSONL 行を1行、${CLAUDE_PLUGIN_DATA}/audit-log.jsonl に追記します。タイムスタンプ、プログラム名、パス、フレームワーク、プロトコル種別、LOC、命令数、深度、深刻度別の指摘数、指摘 ID、分類 ID
3. ユーザーに次のように伝えます。「監査結果を保存しました。今後の監査に備えて、指摘を承認済みリスクとしてマークできます。」

${CLAUDE_PLUGIN_DATA} が利用できない場合は、何もせずにスキップします。

フォローアップ：形式検証

算術の安全性（M-1、M-2、M-3、M-4）、状態の不変条件（S-1 から S-8）、または認可ロジック（A-1 から A-5）に関わる CRITICAL または HIGH の指摘については、/kani-proof を使用した形式検証を提案します。

形式検証を利用できます： [function_name()] の指摘 VULN-NNN（[taxonomy_id]：[title]）は、/kani-proof を使用して修正の正しさと脆弱性が再発しないことを証明する形式検証が可能です。

例：「calculate_reward() の指摘 VULN-001（M-1：整数オーバーフロー）は、/kani-proof を使用して、有界な入力のもとですべての算術演算が安全であることを形式検証できます。」

これは簡易的な提案にすぎません。これを理由にレポートの作成を妨げないでください。

リファレンス

references/ ディレクトリには、以下のファイルがあります。

コアリファレンス：

• CHEATSHEET.md — grep で検索できるキーワードを含む、30 種類すべての脆弱性タイプの簡潔なクイックリファレンス（最初に読み込んでください）
• scoring.md — 偽陽性ゲートと信頼度スコアリングのルール（すべてのエージェントが読み込みます）
• vulnerability-taxonomy.md — 個別の脆弱性リファレンスファイルへのリンクをまとめた完全なインデックス
• audit-checklist.md — 命令ごとの検証チェックリストと構文 grep コマンド
• anchor-specific.md — Anchor フレームワーク固有の注意点
• exploit-case-studies.md — Solana の実際のエクスプロイトパターン（損失額は $500M 以上）

スキャンの自動化：

• scripts/scan-commands.md — スキャン前フェーズで使用する、構文スキャンコマンドの統合版

永続化テンプレート：

• templates/config-template.json — 監査設定のスキーマ
• templates/audit-log-schema.md — 監査ログと許容済みリスクのスキーマ

個別の脆弱性ファイル 20 件 — それぞれに前提条件、脆弱なパターン、検出ヒューリスティック、偽陽性、修正方法が記載されています

エージェントのプロンプト（references/agents/）：

• explorer.md — フェーズ 1 の調査
• auth-state-scanner.md — 認証スキャナー（カテゴリ A + S）
• cpi-math-scanner.md — CPI スキャナー（カテゴリ C + M）
• logic-economic-scanner.md — ロジックスキャナー（カテゴリ L + T）
• framework-scanner.md — フレームワークスキャナー（Framework + R）
• adversarial-scanner.md — DEEP モードの脅威モデリング

プロトコル固有のリファレンス（references/protocols/）— explorer による分類に基づいて、必要に応じて読み込みます：

• lending-protocol.md — 担保、清算、金利のパターン
• dex-amm-protocol.md — スワップ、LP トークン、AMM カーブのパターン
• staking-protocol.md — 報酬分配、エポック、委任のパターン
• bridge-protocol.md — メッセージ検証、リプレイ、ガーディアンのパターン