solidity-security-audit

Solidity セキュリティ監査スキル

目的

世界有数の Web3 セキュリティ企業が確立した手法に従って、プロフェッショナル品質のスマートコントラクトセキュリティ監査を実施します。修正方法のガイダンスを含む、深刻度別に分類された実行可能な指摘事項を作成します。

コンテキストの収集 — スコープなしでコードが届いた場合

**トリガー：**ユーザーが追加のコンテキストなしに Solidity コード（1 つの関数、1 つのファイル、またはリポジトリへのリンク）を貼り付けた場合 — チェーン、Solidity のバージョン、明示されたスコープ、過去の監査情報がない場合。

すぐに監査を始めないでください。コンテキストが不足していると、深刻度の誤った評価、無関係な指摘（例：メインネット専用のコードに L2 の問題を指摘する）、労力の浪費につながります。作業を始める前に、以下の質問を1 つのメッセージで尋ねてください。

必須コンテキスト（回答があるまで保留）

短い番号付きリストで質問してください。フォームや表は使わないでください。

Before I start the audit, I need a few details:

1. **Scope** — Is this the full codebase, a single contract, or a specific function?
   (Full codebase = I'll check cross-contract interactions; single function = focused review)

2. **Solidity version** — What compiler version are you targeting?
   (Affects: overflow behavior, PUSH0 compatibility, transfer()/send() deprecation in 0.9.0)

3. **Target chain(s)** — Where will this deploy?
   (Mainnet, L2 like Arbitrum/Base/zkSync, multi-chain, or unknown)

4. **Previous audits** — Has this code been audited before? Any known issues or recent changes?
   (If yes → Re-audit mode; if no → Full Audit)

5. **Protocol type** — What does this protocol do?
   (e.g., lending, AMM, vault, bridge, governance — determines which checklist to load)

ユーザーが回答できない場合のデフォルト

ユーザーが「とにかく確認して」と言うか、回答を提供しない場合は、以下の安全なデフォルトを仮定し、監査の開始時に明示してください。

質問	デフォルト	リスク
スコープ	提供された単一のコントラクト／関数	コントラクト間の問題を見落とす可能性があります
Solidity のバージョン	最新の安定版（^0.8.x）	バージョン固有のバグを見落とす可能性があります
対象チェーン	Ethereum メインネット	L2 固有の問題を見落とす可能性があります
過去の監査	なし — 初回レビュー	フル監査モード
プロトコルの種類	一般的な DeFi	defi-checklist.md の汎用 DeFi チェックを使用

迅速な対応 — 単一関数の貼り付け

ユーザーが単独の関数（30 行以下で、コントラクトの状態変数やコンストラクターが見えないもの）を貼り付けた場合は、コンテキストに関する質問を省略し、直接クイックスキャンを実施します。次のように述べてください。

「この関数を単独でレビューしています。状態変数、アクセス制御、コントラクト間のやり取りを含む完全な監査には、コントラクト全体を共有してください。」

その後、深刻度タグ付きの箇条書きを出力します（指摘がなければ中程度も含め、通常は致命的／高のみ）。

---

監査モードの選択

開始前に、監査モードを特定してください。

モード	使用する状況	エントリーポイント
フル監査	コードベースの初回レビュー	以下のフェーズ 1～5
再監査／差分	過去の監査があり、チームが修正を適用したか、機能を追加した場合	references/diff-audit.md
統合レビュー	コントラクトが Uniswap、Chainlink、Aave、Curve などと統合する場合	references/defi-integrations.md ＋ フェーズ 3
クイックスキャン	時間が限られた迅速な評価	references/quick-reference.md — フェーズ 0 を短縮（最大 5 分）し、フェーズ 1～2 のみ実施。フェーズ 3 では quick-reference.md にある致命的／高リスクのパターンに重点を置きます。**出力：**致命的／高リスクの指摘のみを箇条書きで示します。各項目には、深刻度タグ、場所（File.sol#L）、1 行の説明、修正方法への案内を含めます。レポート全体の構成は不要です。
コンテスト	Code4rena、Sherlock、Immunefi、Cantina、CodeHawks への提出	プラットフォーム固有の出力形式、戦略、有効性のルールについては、以下のコンテストモードのセクションを参照してください

深刻度の分類については、必要に応じて references/severity-decision-tree.md を参照してください。

---

コンテストモード

ユーザーが「Code4rena」、「C4」、「Sherlock」、「Immunefi」、「Cantina」、 「CodeHawks」、「Cyfrin」、「warden submission」、「Watson submission」、「bug bounty submission」、 「audit contest」、「audit competition」、「contest finding」、「submit to contest」のいずれかに言及した場合に有効化します。

ステップ 0 — プラットフォームを特定する

プラットフォーム	モデル	報酬構造	使用する重大度
Code4rena	競争型	H/M の分割プール。Low = QA プール。Gas = Gas プール	H / M / Low / NC / Gas
Sherlock	競争型	H/M の分割。Low = 報酬なし	H / M のみ（報酬対象）
Immunefi	バグ報奨金	重大度ごとに定められた固定報酬	Critical / High / Medium / Low
Cantina	競争型	H/M/Low の報酬ティア	Critical / H / M / Low / Info
CodeHawks / Cyfrin	競争型	C4 と同様	H / M / Low / Info / Gas

特定したら、references/report-template.md → Contest Submission Format に記載された正確な提出形式を使用します。

ステップ 1 — スコープの確認

レビューを始める前に：

• コンテストのリポジトリにある README、scope.txt、既知の問題の一覧を読みます
• スコープ外のコントラクトをすべて特定します。そこに関する指摘は即座に無効となります
• 「Admin is trusted」など、バグの分類全体を対象外とするプロトコル上の前提を確認します
• ボット競合レポートが提出されているか確認します（C4 のボットは floating pragma、ゼロチェックの欠如、戻り値の未チェックを報告します。これらは避けてください）

ステップ 2 — 優先順位（コンテストの ROI）

コンテストでは、独自性があり影響の大きい指摘が評価されます。それに応じてレビュー時間を配分します。

最も ROI が高い → 時間の 70% を投入：

• 再入可能性（あらゆる種類、特にクロスファンクションと読み取り専用）
• オラクル操作（スポット価格、TWAP の回避、古いフィード）
• 特権関数のアクセス制御の欠陥
• ビジネスロジックのエラー（手数料計算の誤り、ステートマシン違反、オフバイワン）
• 経済的攻撃（フラッシュローン攻撃ベクトル、スリッページ、MEV）

ROI が中程度 → 25% を投入：

• 整数精度／丸め方向
• 入力検証の欠如（ゼロアドレス、範囲制限 — 悪用可能な場合のみ。ボット向けの指摘は除く）
• DoS 攻撃ベクトル（無制限ループ、実害のあるグリーフィング）
• 署名リプレイ／EIP-712 のエラー

ROI が低い — 簡単に追加できる場合を除き、スキップ：

• ガス最適化（コンテストに Gas プールがある場合のみ）
• コードスタイル、命名（NC / Info → ほとんどのプラットフォームでは報酬なし）
• 既知の問題としてすでに記載されている指摘

ステップ 3 — 有効性の事前確認

各指摘を書く前に、次の基準で確認します。

Is there a working attack path an external actor can execute?
├─ No → Invalid (likely rejected)
│
Is the root cause inside the contest scope?
├─ No → Out of scope (invalid)
│
Does the impact require a trusted role (admin, owner)?
├─ Yes, and admin is listed as trusted → Low at best (often invalid)
│
Can the impact be quantified in USD?
├─ Yes → always include the estimate (judges weight concrete impact)
├─ No → describe the qualitative harm precisely
│
Is there a working PoC?
├─ H/M without PoC → likely downgraded or rejected
├─ Build a Foundry test before writing the report

ステップ 4 — プラットフォーム固有のルール

Code4rena：

• H/M はそれぞれ個別の GitHub issue として提出します。QA の指摘は 1 件の QA レポートにまとめます
• 重複とは、症状ではなく根本原因が同じことを指します → 報酬プールを分割します
• PoC 付きの独自の指摘が最も高い報酬を得ます。一般的でないバグは先行者が有利です
• すべての指摘に、正確な GitHub パーマリンク（ブランチではなくコミットハッシュ）を記載します
• 可能な場合、緩和策には diff 形式を使用します

Sherlock：

• 厳格な事前条件のテンプレートが必要です：「Internal pre-conditions」＋「External pre-conditions」
• admin is trusted = 管理者の不正利用に関する指摘は無効です（Low であっても不可）
• 「1 wei の損失」だけでは無効です。相応の金額的影響、または重大な機能停止が必要です
• エスカレーション期間：Watson によるエスカレーションは Senior Watsons が審査します。判定者が誤っていると考える場合はエスカレーションしてください
• 有効な状態は PoC トランザクション後も維持される必要があります（次のブロックでリセットされないこと）

Immunefi：

• バグ報奨金：まず非公開で開示します。パッチ適用までは公開しないでください
• Critical/High には動作する PoC が必要です。Medium は明確な説明があれば受理される場合があります
• 影響は現実的である必要があります。「理論上」または「最良のケース」を前提とした攻撃は通常却下されます
• 次の情報を含めます：影響を受ける製品のバージョン、環境（mainnet/testnet）、再現手順
• コンテスト形式には含めず、非公開の開示チャネルを使用します

Cantina / CodeHawks：

• 構成は C4 と同様です。正確なファイル名と行番号を示す Context: フィールドを含めます
• CodeHawks では、統合された Severity に加えて、Likelihood と Impact のラベルを明示する必要があります

Step 5 — 出力

references/report-template.md → Contest Submission Format に記載されている、プラットフォームごとの正確な形式を使用してください。

非公開の監査レポート形式は使用しないでください（エグゼクティブサマリー、スコープのセクション、付録は含めません）。

各指摘は単独で成立し、個別に理解できるものでなければなりません。 審査員は何百件もの指摘に目を通します。最初の文で影響を最優先に伝えてください。

---

監査ワークフロー全体

監査は以下の順序で実施してください。各フェーズは前のフェーズを踏まえて進めます。

Phase 0 — 脅威モデリング

プロトコルの種類別監査 — クイックルーティング

プロトコルの種類	主な参考資料	DeFi チェックリストのセクション	主な事例
AMM / DEX	defi-integrations.md §Uniswap	defi-checklist.md §AMM	Curve、Cork Protocol
貸付／借入	defi-integrations.md §Aave	defi-checklist.md §Lending	Euler、Abracadabra
Vault / Yield（ERC-4626）	defi-integrations.md §ERC-4626	defi-checklist.md §Vault	—
Bridge / Messaging	l2-crosschain.md	defi-checklist.md §Bridge	Nomad、Wormhole
ガバナンス / DAO	vulnerability-taxonomy.md §15	defi-checklist.md §Governance	Beanstalk、Compound
無期限 DEX	perpetual-dex.md	defi-checklist.md §Perp	Hyperliquid HLP
LST / リステーキング	staking-consensus.md	defi-checklist.md §Restaking	Bybit
Uniswap V4 Hook	defi-integrations.md §V4-Hooks	defi-checklist.md §V4-Hooks	Cork Protocol
ZK / ロールアップ	zkvm-specific.md	l2-crosschain.md §ZK	—
アカウント抽象化	account-abstraction.md	audit-questions.md §AA	—
AI 生成コード	ai-code-patterns.md	audit-questions.md §AI	Bybit（サプライチェーン）
Intent / Solver	intent-protocols.md	defi-checklist.md §Intents	—
CeDeFi / Synthetic	vulnerability-taxonomy.md §4.7	defi-checklist.md §CeDeFi	xUSD（$285M）
RWA / トークン化資産	rwa-protocols.md	defi-checklist.md §RWA	—
オプション / ストラクチャード商品	options-protocols.md	defi-checklist.md §Options	Deus DAO、Lyra AVAX
予測市場	prediction-markets.md	defi-checklist.md §Prediction	Polymarket の UMA 紛争、Augur REP
マルチシグ / Safe モジュール	safe-modules.md	defi-checklist.md §Safe	Radiant Capital
Move / Sui / Aptos	move-security.md	—（補足資料）	Cetus（$223M）

コードに触れる前に、プロトコルの機能と、経済的にどのような問題が起こり得るかについて、全体像を把握してください。これは、Phase 3 でどこに時間をかけるかを決める指針になります。

1. 関係者を洗い出す：このプロトコルとやり取りするのは誰ですか？

   • 権限のないユーザー、流動性提供者、借り手
   • 特権ロール：管理者、ガーディアン、キーパー、手数料受取人
   • 外部の関係者：MEV ボット、フラッシュローン攻撃者、清算人、ガバナンス参加者

2. 最重要資産を特定する：どの資産や権利が危険にさらされていますか？

   • プロトコルにロックされたユーザー資金
   • プロトコルが所有する準備金や保険基金
   • ガバナンス権限（アップグレード、パラメーター変更、資金流出を実行する能力）

3. 重要な不変条件を定義する：決して偽であってはならない条件は何ですか？

   • 支払能力：負債合計 ≤ 資産合計
   • 会計処理：個々の残高の合計 = 記録された合計
   • アクセス制御：特権操作を実行できるのは、認可された呼び出し元のみ

4. 信頼境界をたどる：このプロトコルは、どの外部システムを信頼していますか？

   • オラクル（Chainlink、TWAP、カスタム）
   • 外部プロトコルとの連携（Uniswap、Aave、Curve）
   • ブリッジ／メッセージングレイヤー（LayerZero、CCIP、Wormhole）
   • マルチシグ署名者またはガバナンス

5. MEV の攻撃対象を見積もる：どの操作で、トランザクションの順序を利用した利益獲得の機会が生まれますか？

   • 清算、裁定取引、サンドイッチ攻撃が可能なスワップ
   • フロントラン可能な公開、請求、または決済

6. アップグレード／管理者権限の影響範囲を確認する：管理者キーやマルチシグが侵害された場合、 最大でどのような損害が発生しますか？タイムロックはありますか？一時停止の仕組みはありますか？

出力：Phase 3 の手動レビューで価値の高い攻撃経路に注力できるよう、脅威の概要を 5～10 行でまとめてください。Quick Scan モードでは、この手順を省略できます。

フェーズ 1 — 初期調査

1. Solidity のバージョン、コンパイラー設定、フレームワーク（Hardhat／Foundry）を特定します
2. コントラクトのアーキテクチャを把握します：継承ツリー、ライブラリの使用状況、外部依存関係
3. プロトコルの種類（DeFi レンディング、AMM、NFT、ガバナンス、ブリッジ、Vault など）を特定します
4. 信頼モデルを明らかにします：特権ロールを持つのは誰ですか？ 何ができますか？
5. すべての外部連携（オラクル、他のプロトコル、トークン規格）を列挙します

フェーズ 2 — 自動分析

環境にツールがある場合は、次の順序で実行します：

# Static analysis
slither . --json slither-report.json

# Compile and test
forge build
forge test --gas-report

# Custom detectors (if Aderyn is available)
aderyn .

ツールがない場合は、これらのツールが確認するのと同じカテゴリを対象に、手動で静的解析を行います。詳細については、references/tool-integration.md をお読みください。

フェーズ 3 — 手動レビュー（コア）

最も価値の高い指摘が見つかるのはこの段階です。references/vulnerability-taxonomy.md の脆弱性分類に沿って、体系的に確認してください。

ナビゲーション： 脆弱性の種類やセキュアなパターンに対応するファイルとセクションをすばやく見つけるには、references/INDEX-vulns.md を読み込みます。DeFi 固有のトピックについては、代わりに references/INDEX-defi.md を読み込みます。カテゴリの全体ガイドについては、references/INDEX.md を参照してください。

最優先 — まず確認する項目：

• 再入可能性（すべての種類：関数間、コントラクト間、読み取り専用）
• アクセス制御の欠陥（モディファイアの欠落、ロールチェックの誤り、保護されていない初期化関数）
• 価格オラクルの操作（スポット価格の使用、単一オラクルへの依存、TWAP の回避）
• フラッシュローン攻撃ベクトル
• プロキシ／アップグレードの脆弱性（ストレージの衝突、未初期化の実装、UUPS の不備）
• チェックされていない外部呼び出しと戻り値
• ERC-7702 の委任に伴うリスク（EOA または認可タプルが存在する場合：悪意のある委任先、古い認可の再利用、ノンス競合、委任コードの再初期化）— references/vulnerability-taxonomy.md §17 を参照

優先度：高

• 整数のオーバーフロー／アンダーフロー（0.8.x より前、または unchecked ブロック内）
• ビジネスルールのロジックエラー（トークンの発行、報酬計算、手数料の分配）
• フロントランニングと MEV への露出（サンドイッチ攻撃、トランザクション順序への依存）
• サービス拒否の攻撃ベクトル（ガス消費を狙った妨害、上限のないループ、ブロックのガス上限）
• 署名のリプレイと可鍛性
• 信頼できないコントラクトへの Delegatecall

優先度：中

• ユーザビリティに影響するガス最適化の問題
• 状態変更に伴うイベント発行の欠落
• 中央集権化のリスクと単一障害点
• タイムスタンプへの依存
• 固定されていないプラグマバージョン
• ゼロアドレスチェックの欠落

優先度：低／参考情報：

• コードのスタイルと可読性
• 未使用の変数とインポート
• NatSpec ドキュメントの欠落
• 冗長なコードパターン

フェーズ 4 — DeFi 固有の分析

DeFi プロトコルを監査する際は、references/defi-checklist.md の専門チェックリストを適用してください。プロトコル固有の項目と不変条件テストを参照するには、references/INDEX-defi.md を読み込んでください。主な領域は次のとおりです。

• レンディングプロトコル：清算ロジック、担保係数の操作、不良債権のシナリオ
• AMM／DEX：スリッページ保護、価格インパクトの計算、LP トークンの計上
• ボールト／イールド：シェア価格の操作（インフレーション攻撃）、出金キューのロジック
• ブリッジ：メッセージ検証、リプレイ保護、バリデーターの信頼に関する前提
• ガバナンス：投票操作、フラッシュローンを利用したガバナンス攻撃、タイムロックの回避
• ステーキング：報酬計算の精度、ステーク／アンステークのタイミング攻撃
• RWA プロトコル：NAV オラクルの信頼性、トランシェの計上、エポック単位の償還、KYC による送金制限、デフォルト処理については、references/rwa-protocols.md を読み込んでください
• オプションプロトコル：決済オラクルの操作、IV 攻撃、担保／証拠金、ボールト戦略のリスク、複数レッグのペイオフの正確性については、references/options-protocols.md を読み込んでください
• 予測市場：解決オラクルの信頼性、CTF の分割／統合ロジック、AMM の価格範囲、市場作成攻撃、解決時のタイミング／MEV については、references/prediction-markets.md を読み込んでください
• Safe モジュール／マルチシグ：モジュールのインストールライフサイクル、delegatecall によるストレージ衝突、ガード回避の手段、フォールバックハンドラー攻撃、ソーシャルリカバリー、Zodiac フレームワークのパターンについては、references/safe-modules.md を読み込んでください

フェーズ 5 — レポートの作成

すべての指摘事項を次の形式で記述してください。

## [SEVERITY-ID] Title

**Severity**: Critical | High | Medium | Low | Informational
**Category**: (from vulnerability taxonomy)
**Location**: `ContractName.sol#L42-L58`

### Description
Clear explanation of the vulnerability, why it exists, and what an attacker could do.

### Impact
Concrete description of damage: funds at risk, protocol disruption, data corruption.

### Proof of Concept
Step-by-step exploit scenario or code demonstrating the issue.

### Recommendation
Specific code changes to fix the vulnerability. Include example code when possible.

Immunefi、Code4rena、Sherlock が使用する標準に従って、深刻度を分類してください。

深刻度	基準
Critical	資金の直接的な損失、プロトコルの恒久的な破損、すべてのアクセス制御の回避
High	条件付きの資金損失、プロトコルへの重大な妨害、権限昇格
Medium	間接的な損失、特定の条件を要する限定的な影響、コストを伴うグリーフィング
Low	軽微な問題、ベストプラクティスへの違反、理論上のエッジケース
Informational	コード品質、ガスの最適化、ドキュメントの不足

適用すべき主要なパターン

Checks-Effects-Interactions（CEI）

状態を変更し、外部呼び出しを行うすべての関数は、CEI に従う必要があります。 外部呼び出しより前に状態変更が行われることを確認してください。

Push より Pull

直接送金するよりも、引き出し方式を優先してください。資金を自動的にユーザーへ プッシュするのではなく、ユーザーが請求できるようにしてください。

最小権限

すべての関数に、必要最小限のアクセスレベルを設定してください。単一オーナー方式よりも、 ロールベースのアクセス制御（OpenZeppelin AccessControl）を優先してください。

多層防御

単一のセキュリティ機構だけを保護手段にしてはいけません。リエントランシー ガード、アクセス制御、入力検証、不変条件チェックを重ねてください。

参考資料

脆弱性の詳細な説明、エクスプロイトの例、修正パターンについては、 次の参考ファイルを参照してください。

中核となる参考資料

• references/vulnerability-taxonomy.md — コード例付きの 50 種類以上の脆弱性
• references/defi-checklist.md — プロトコル固有のチェックリスト（レンディング、AMM、ボールト、ブリッジ、トークン）
• references/industry-standards.md — SWC Registry、深刻度の分類、セキュリティ EIP
• references/quick-reference.md — 迅速なセキュリティ評価のための 1 ページのチートシート

監査ガイド

• references/audit-questions.md — 関数の種類ごとの体系的な質問
• references/secure-patterns.md — 比較対象となる安全なコードパターン
• references/report-template.md — 専門的な監査レポートの形式

テストとツール

• references/tool-integration.md — Slither、Echidna、Foundry、Halmos、カスタム検出器
• references/automated-detection.md — 自動スキャン用の正規表現パターン
• references/poc-templates.md — エクスプロイトを実証する Foundry テンプレート
• references/invariants.md — テスト用のプロトコル不変条件

専門分野

• references/l2-crosschain.md — L2 シーケンサーのリスク、ブリッジのセキュリティ、クロスチェーンのパターン
• references/account-abstraction.md — ERC-4337 のセキュリティ：アカウント、ペイマスター、バンドラー
• references/exploit-case-studies.md — 実際に発生したエクスプロイトの分析（DAO、Euler、Curve など）

v2 の新機能

• references/diff-audit.md — 再監査と変更レビューの手法
• references/severity-decision-tree.md — 構造化された重大度分類の決定木
• references/defi-integrations.md — セキュアな統合パターン：Uniswap v3/v4、Chainlink、Aave、Curve、Balancer

v3 の新機能

• references/intent-protocols.md §8 — ERC-7683 クロスチェーンインテント（Base/Arbitrum で稼働中）：フィラーの信頼モデル、パラメーターの置換、二重実行、決済ファイナリティの競合
• references/staking-consensus.md — Pectra アップグレードのセキュリティ：EIP-7002（トリガー可能な退出）、EIP-7251（MaxEB とスラッシングの増幅）、EIP-6110（オンチェーン入金）
• references/industry-standards.md — OWASP Smart Contract Top 10 2025 の表を追加

v3.19.0 の新機能

• references/move-security.md — Sui/Aptos/Movement エコシステム向けの Move 言語監査補足資料：リソースモデルのセキュリティ（能力の不一致、ホットポテト、ケイパビリティトークン）、Sui オブジェクトモデル（所有権、バージョニング、動的フィールド、PTB の構成）、Aptos 固有のパターン（リソースアカウント、Fungible Asset の移行、乱数 API）、バイトコード検証器の保証とギャップ、Move 監査でよく見られる指摘事項（ケイパビリティの漏えい、算術オーバーフロー、friend の悪用、ジェネリック型の混同）、VM 間ブリッジのセキュリティ（EVM ↔ Move の小数桁数／アドレス／供給量の不一致）、30 項目の Move 監査チェックリスト
• SKILL.md のトリガー：Move/Sui/Aptos のキーワードを 8 個追加
• SKILL.md の Phase 0 ルーティング表：Move/Sui/Aptos の行を追加
• INDEX-advanced.md：Move セクションのエントリーを 8 個追加

v3.18.0 の新機能

• references/fusaka-eof.md — EOF（EIP-7692、Fusaka）の移行とデプロイに関する監査プレイブック：コンパイラー／ツールのサポート状況一覧（solc / Foundry --eof / Slither / Aderyn）、レガシーから EOF への移行レシピ（リエントランシーガード、EOA の検出、動的ジャンプ、ガスベースのロジック、SELFDESTRUCT の返金、CREATE2 ファクトリー）、プロキシとアップグレードの判断マトリックス（すべて EOF／すべてレガシー／ハイブリッドは禁止／運用中の移行）、L2 マルチチェーン展開時の考慮事項（evmVersion 設定、PUSH0 のインシデントパターン、サイドチェーンの互換性）、監査ワークフロー（監査前の質問票、バイトコードのマジックバイト検証、報告テンプレート）、30 項目の移行監査チェックリスト（デプロイ前／デプロイ時／デプロイ後）

v3.17.0 の新機能

• references/staking-consensus.md §5 — Pectra 後の動向（2025 年 5 月～2026 年半ば）：LST/LRT プロトコルの適応状況（Lido、Rocket Pool、EtherFi、EigenLayer）、観測されたインシデントとニアミス（Pectra のプリミティブを悪用した重大なエクスプロイトはなし）、退出キューとバリデーター統合のデータ、10 項目の改訂版監査ヒューリスティックチェックリスト（32 ETH のハードコード、0x01/0x02 プレフィックス、二重スラッシング）、7 つの未解決リスク領域

v3.15.0 の新機能

• references/poc-templates.md — ERC-7702 PoC を最新化：コメントアウトされた呼び出しの代わりに Foundry 1.0 以降のチートコード（vm.signDelegation、vm.attachDelegation、vm.signAndAttachDelegation）を使用。実行可能なテストを 4 件追加：悪意ある委任による資金流出、クロスチェーンリプレイ（chainId=0）、スポンサー付きトランザクションによるサンドボックス脱出、address(0) による委任の取り消し
• references/poc-templates.md — 新しい EOF コンテナー互換性 PoC セクション（EIP-7692/Fusaka）：レガシープロキシから EOF 実装への DELEGATECALL の破損、SELFDESTRUCT 削除のセキュアなパターン、EOF コンテナーの無効な検証、10 項目の EOF 移行監査チェックリスト、forge build --eof および forge test --eof の CLI コマンド

v3.16.0 の新機能

• references/severity-decision-tree.md — 新たな脆弱性カテゴリーに対応する決定木を 4 つ追加：EOF（EIP-7692/Fusaka）、ERC-7702（Pectra の auth-list 委任）、一時ストレージ（EIP-1153 TSTORE/TLOAD。TSTORE による汚染と 2300 ガスのバイパスを含む）、ZK-VM／証明検証（検証器の完全性、回路の制約不足、シーケンサーの脱出口、証明の集約）

v3.14.0 の新機能

• references/safe-modules.md — Safe のモジュール、ガード、フォールバックハンドラーのセキュリティに関する詳細なリファレンス：信頼モデルとプロキシアーキテクチャ、モジュールのインストールライフサイクルとリンクリストの操作、delegatecall によるストレージ衝突（スロットマップ＋ERC-7201 による防御）、execTransactionFromModule によるガードの回避（v1.4.1 より前）、フォールバックハンドラーでの ERC-1271 リプレイ、ソーシャルリカバリーのタイミング攻撃、Zodiac フレームワークのパターン（Reality Module のボンド経済性、Roles Modifier v2 のスコープ設定、Bridge/Connext Module のリプレイ）、包括的な 42 項目の監査チェックリスト
• SKILL.md Phase 0 のルーティングテーブル：Safe Modules の行が vulnerability-taxonomy.md §25 ではなく safe-modules.md を参照するように変更
• SKILL.md Phase 4：Safe モジュールの読み込み手順を追加

v3.13.0 の新機能

• references/prediction-markets.md — 予測市場のセキュリティに関する詳細なリファレンス：決済オラクルの信頼モデル（UMA optimistic oracle、Chainlink、中央集権型、DAO）、CTF の分割／統合ポジション攻撃、AMM の価格境界（LMSR/CPMM）、市場作成ライフサイクルの攻撃、決済時のタイミング／MEV（コミット・リビール、ブラックアウト期間）、プロトコル固有のパターン（Polymarket、Azuro、Augur v2、PancakeSwap Prediction、SX Network、Overtime Markets）、包括的な 42 項目の監査チェックリスト
• SKILL.md Phase 0 のルーティングテーブル：Prediction Markets の行が vulnerability-taxonomy.md §4.1 ではなく prediction-markets.md を参照するように変更
• SKILL.md Phase 4：Prediction Markets の読み込み手順を追加

v3.12.0 の新機能

• references/options-protocols.md — オンチェーンオプションプロトコルのセキュリティに関する詳細なリファレンス：決済オラクルの操作（満期時のフラッシュローン、TWAP による防御、サーキットブレーカー）、IV 攻撃（管理者による IV、AMM ベースの IV 流出、Lyra AVAX のパターン）、担保と証拠金（担保不足のオプション売り、維持証拠金、清算）、ボールト戦略のリスク（敵対的な権利行使価格の選択、エポックのタイミング、Gnosis Auction の悪用）、複数レッグのペイオフの正確性（符号なし演算、スプレッド上限、カレンダースプレッドの独立性）、プロトコル固有のパターン（Lyra v2、Opyn Gamma、Ribbon、Dopex SSOV、Premia v3）、包括的な 42 項目の監査チェックリスト
• SKILL.md Phase 0 のルーティングテーブル：Options の行が vulnerability-taxonomy.md §4 ではなく options-protocols.md を参照するように変更
• SKILL.md Phase 4：Options の読み込み手順を追加

v3.11.0 の新機能

• references/rwa-protocols.md — RWA プロトコルのセキュリティに関する詳細なリファレンス：信頼モデルとプールマネージャーの権限昇格、NAV オラクルの操作、エポックの償還における競合状態、トランシェ会計攻撃、KYC／譲渡制限の回避（ERC-1400/ERC-3643）、債務不履行の処理と評価損計上のタイミング、プロトコル固有のパターン（Centrifuge、Maple、T-bill ボールト）、包括的な監査チェックリスト
• SKILL.md Phase 0 のルーティングテーブル：RWA の行が vulnerability-taxonomy.md §16 ではなく rwa-protocols.md を参照するように変更
• SKILL.md Phase 4：RWA の読み込み手順を追加

v3.9.0 の新機能

• references/tool-integration.md §1 Slither Triage Cheat Sheet — Slither の検出結果 100～300 件を処理するための 7 ステップのフレームワーク：優先順位テーブル（P0→P3）、検出器ごとの誤検知の識別ガイド（9 種類の検出器）、jq フィルターコマンド、グループ化／重複排除用の bash、インライン抑制パターン、.slither.config.json テンプレート、slither-check-upgradeability のワークフロー、およびクイックリファレンス用のトリアージ判断カード

v3.8.0 の新機能

• references/defi-checklist.md §RWA — リアルワールドアセット：NAV 操作、シニア／ジュニア・トランシェの会計、エポックベースの償還タイミング、プールマネージャーへの信頼、KYC による移転制限の回避、デフォルト／清算に関するオフチェーンの信頼
• references/defi-checklist.md §Options — オプションおよびストラクチャード商品：満期時の決済オラクル操作、IV 操作、担保不足のオプション売り、自動ボールトによる行使価格の選択、複数レッグのペイオフに関するバグ
• references/defi-checklist.md §Prediction — 予測市場：リゾルバー／オラクルへの賄賂攻撃、CTF 条件付きトークンのマージ攻撃、AMM 価格の上下限、市場作成スパム、解決時のインサイダー MEV
• references/defi-checklist.md §Safe — Gnosis Safe のモジュールとガード：delegatecall によるストレージ衝突（スロットマップ付き）、enableModule() のタイムロック、フォールバックハンドラーの悪用、execTransactionFromModule() によるガードの回避、Zodiac のロール昇格、ソーシャルリカバリー妨害
• SKILL.md Phase 0 のルーティングテーブル：新たに4つのプロトコルタイプ（RWA、Options、Prediction Markets、Safe Modules）を追加 — 合計13から17へ

v3.7.0 の新機能

• references/exploit-case-studies.md #19 — BNB Chain Bridge 5億7,000万ドル（2022年10月）：iavl Go ライブラリのバグを利用した Merkle 証明の偽造、オフチェーン検証の攻撃対象領域、送金上限とタイムロックによる多層防御、オフチェーン証明ライブラリの監査チェックリスト
• references/exploit-case-studies.md #20 — Multichain 1億3,000万ドル（2023年7月）：CEO 1人への MPC 鍵の集中、法域リスク（中国当局）、運用セキュリティ監査フレームワーク、ガーディアンによる一時停止と高額送金のタイムロックを備えた MPC ブリッジアーキテクチャ
• README.md の修正：「What's Included」テーブル内の不統一な太字表記を統一し、エクスプロイト件数を20に更新し、Contest Mode の行を追加

v3.6.0 の新機能

• references/vulnerability-taxonomy.md §23 — Solidity 0.9.0 の破壊的変更：transfer()／send() の削除、.call{}() への移行に伴う新たなリエントランシー攻撃対象領域、戻り値の未チェックパターン
• references/vulnerability-taxonomy.md §24 — PUSH0 オペコードのクロスチェーン互換性：EIP-3855（Shanghai、2023年4月）、Solidity 0.8.20 以降でのデフォルトの evmVersion、Shanghai 非対応チェーンでのデプロイ失敗、チェーンごとの互換性テーブル
• references/vulnerability-taxonomy.md §25 — ERC-1967 プロキシのストレージスロット破損：アセンブリのスロット衝突、UUPS のブリック攻撃（proxiableUUID チェックの欠如）、delegatecall によるスロットの上書き、ストレージレイアウト移行の破損
• CLAUDE.md の修正：監査モードの数を5に訂正（v3.5.0 で追加された Contest Mode が反映されていませんでした）

v3.5.0 の新機能

• Contest Mode — 競争型プラットフォーム向けの新しい監査モード：Code4rena、Sherlock、Immunefi、Cantina、CodeHawks；プラットフォームのルーティングテーブル、コンテストの ROI 戦略、妥当性の事前チェック、プラットフォームごとのルール（管理者への信頼、事前条件、エスカレーション）
• references/report-template.md — Immunefi のバグバウンティ提出形式を追加。責任ある脆弱性開示のルール
• references/exploit-case-studies.md #17 — Ronin Bridge 6億2,500万ドル（2022年3月）：9人中5人のバリデーター閾値と古い一時的権限、ブリッジのバリデーター信頼モデルに関するチェックリスト
• references/exploit-case-studies.md #18 — Mango Markets 1億1,700万ドル（2022年10月）：自己取引によるオラクル操作、2つのウォレットを使った戦略、Chainlink + 30分 TWAP + サーキットブレーカーを備えた強化型オラクル設計
• バグ修正：taxonomy の目次に §21／§22 を追加、SKILL.md のトリガーの重複を解消、Info→Informational ラベル、Quick Scan の出力を定義、Universal DeFi Access Control における ERC-7702 の tx.origin チェック

v3.4.0 の新機能

• references/ai-code-patterns.md — LLM 固有の Solidity アンチパターン：CEI 違反、壊れたリエントランシーガード、幻覚で生成されたインターフェース、不完全なアクセス制御、EIP-712 の nonce／chainId 欠落；AI 生成コードの危険信号；雰囲気でコーディングされたコントラクト向けの完全な監査チェックリスト
• references/glamsterdam.md — Glamsterdam アップグレードのセキュリティ：EIP-7732 の ePBS ペイロード隠蔽と事前確認のタイミング攻撃；EIP-7928 の BAL における MEV の透明性と並列化の競合状態；両 EIP の監査チェックリスト
• references/exploit-case-studies.md #15 — xUSD／Stream Finance の 2 億 8,500 万ドルの損失（2025 年 11 月）：ハードコードされたオラクルアダプター（$1.00）が再帰的なレバレッジループに入力；pure オラクルアダプターが静的解析を回避する理由
• references/exploit-case-studies.md #16 — Hyperliquid HLP：マーケットメーカーと不良債権の吸収役を兼ねるボールトの二重の役割；独自オラクルの中央集権化；流動性の低い市場の悪用（JELLY インシデント）
• references/perpetual-dex.md §10-§14 — dYdX v4（Cosmos CLOB、CometBFT の MEV）、Gains Network（DAI ボールトの支払能力）、高度なファンディングレート操作（スキュー基準と時間加重）、保険基金の枯渇攻撃、クロスマージンの連鎖的影響と分離マージンからクロスマージンへの切り替えタイミング攻撃
• references/zkvm-specific.md §7-§10 — Noir の unconstrained 関数のリスクとパブリック／プライベート入力の混同、SP1 のサイクル DoS とコミット済み出力の完全性、Polygon CDK シーケンサーの中央集権化と LxLy ブリッジのリプレイ、フォールディング方式（Nova／SuperNova／HyperNova IVC）
• SKILL.md Phase 0 — 「プロトコルタイプ別監査」のクイックルーティングテーブル：13 のプロトコルタイプを、主要なリファレンス、チェックリストのセクション、主要なケーススタディに対応付け

v3.3.0 の新機能

• references/vulnerability-taxonomy.md §4.6 — リステーキング資産のオラクルチェーンの複雑性（Moonwell のパターン）：連鎖するアダプター間での鮮度情報の伝播
• references/vulnerability-taxonomy.md §4.7 — オラクル価格のハードコードによる連鎖的影響の増幅（xUSD/Stream Finance、2億8500万ドル、2025年11月）：担保価格を $1.00 とする再帰的レバレッジ
• references/vulnerability-taxonomy.md §6.7 — カスタムストレージレイアウトの衝突（solc 0.8.29、複数継承 + --via-ir）
• references/vulnerability-taxonomy.md §9.5 — ソースチェーンのイベント漏えいによるクロスチェーン・サンドイッチ攻撃（arXiv、2025年11月、利益率21.4%）
• references/vulnerability-taxonomy.md §12.7 — マルチアクションルーターのセキュリティフラグのリセット（Abracadabra cook()、180万ドル、2025年10月）：OR による累積と直接代入の比較
• references/vulnerability-taxonomy.md §17.6 — EIP-7702 スイーパーキャンペーン + Pectra 後の tx.origin ガードのバイパス（250万ドル以上、2025年5月）
• references/vulnerability-taxonomy.md §19.8 — TransientStorageClearingHelperCollision：一時変数に対する delete が sstore を出力（solc 0.8.28–0.8.33 + --via-ir、§19.6 とは別の問題）
• references/exploit-case-studies.md — Cork Protocol V4 フックの悪用（1100万ドル、2025年5月）：初の大規模な本番環境 V4 フックの悪用事例、onlyPoolManager の欠如
• references/defi-checklist.md — すべての V4 コールバックにおける onlyPoolManager の要件（Cork Protocol のパターン）、CeDeFi と再帰的レバレッジのセクション、sweepUnclaimed() のアクセス制御
• references/account-abstraction.md — ERC-7579：onUninstall のリバートによるモジュール汚染、再インストール後の古い状態、エグゼキューターの delegatecall の悪用、ERC-7484 レジストリ
• references/account-abstraction.md — ERC-7821 最小バッチエグゼキューター：EIP-712 のリプレイ攻撃防止に関する完全なチェックリスト
• references/l2-crosschain.md — クロスチェーン・サンドイッチ攻撃、Fusaka EIP-7825 のガス上限（16.78M）、アプリチェーンのフォークのリスク（Berachain のパターン）
• references/perpetual-dex.md §9 — 清算を吸収する流動性ボールト：Hyperliquid HLP の構造的操作、オラクルの中央集権化リスク
• references/tool-integration.md — Aderyn v0.6 の書き直し（LSP、CI、100 以上の検出器）、Echidna 2025 の検証モード + Foundry の再現コード、Halmos + Recon の自動再現機能
• references/audit-questions.md — AI 支援によるエクスプロイト開発に関する考慮事項（Balancer V2 の console.log の証拠）
• references/industry-standards.md — Solidity の非推奨化スケジュール（transfer/send/ABI v1 → 0.9.0 で削除）、Glamsterdam アップグレード（ePBS、BALs）

v3.2.0 の新機能

• references/vulnerability-taxonomy.md §19.6 — TSTORE Poison コンパイラーバグ（solc 0.8.28–0.8.33 + --via-ir）：所有権の窃取、リエントランシーガードの回避、約50万件の影響を受けるコントラクト
• references/vulnerability-taxonomy.md §19.7 — TSTORE による2300ガスのスタイペンド回避：呼び出し先が TSTORE を使用する場合、transfer()/send() ではリエントランシーを防げなくなります
• references/vulnerability-taxonomy.md §22 — EVM EOF（EIP-7692/Fusaka）：ガス／コードの可観測性の削除、EXTDELEGATECALL のレガシー制限、デプロイ時の検証
• references/vulnerability-taxonomy.md §3.4 — 数値オーバーフローのセンチネルエラー：Cetus の2億2300万ドルの事例、FullMath/PRBMath におけるビットシフト境界の誤り
• references/vulnerability-taxonomy.md §6.6 — OZ v4→v5 のストレージスロット移行の破損：逐次配置と ERC-7201 の名前空間付き配置
• references/vulnerability-taxonomy.md §12.6 — 外部呼び出しの失敗による見せかけの担保：Abracadabra のパターン、共有状態を持つ cook() バッチルーター
• references/vulnerability-taxonomy.md §4.5 — ERC-7726 の誤った有効性の想定：無効なデータを黙って通過させるオラクルアダプター
• references/vulnerability-taxonomy.md §18.6 — V4 フックの LDF 丸め攻撃：Bunni の840万ドルの事例、流動性の追加／削除における非対称な丸め
• references/defi-checklist.md — JIT 流動性攻撃のチェックリスト、LDF 丸めチェックリスト、モジュラー型レンディング（Morpho Blue + Euler V2 EVC）のチェックリスト
• references/account-abstraction.md — EIP-7701 ネイティブ AA のセクション：ACCEPT_ROLE オペコードのリスク、レガシーコントラクトによる意図しない検証
• references/automated-detection.md — TSTORE Poison のバージョン検出器と共使用の正規表現パターン

ナビゲーション

• references/INDEX.md — マスターインデックス。4つの用途別サブインデックスを案内するカテゴリガイドを掲載
• references/INDEX-vulns.md — 脆弱性の種類とセキュアなパターン → フェーズ3で読み込みます
• references/INDEX-defi.md — DeFi プロトコル、トークン、不変条件 → フェーズ4で読み込みます
• references/INDEX-tools.md — ツール、検出パターン、PoC テンプレート → フェーズ2または PoC 作成時に読み込みます
• references/INDEX-advanced.md — L2/AA/ZK/ステーキングと「X を見つけました」クイック参照表 → 専門的なコンテキストで読み込みます

具体的な監査の状況に応じて、必要なファイルを読み込んでください。

重要な注意事項

• レビューが限定的な自動スキャンなのか、完全な手動監査なのかを必ず明確に示してください
• コードが「100%安全」だと決して保証しないでください。監査はリスクを低減しますが、排除するものではありません
• 従来の「脆弱性」ではなくても、中央集権化のリスクを指摘してください
• 経済的なインセンティブを考慮してください。ガスコストを踏まえて、エクスプロイトに利益が見込めるでしょうか？
• 一般的な DeFi プリミティブ（フラッシュローン、MEV、コンポーザビリティ）との相互作用を確認してください
• 深刻度の判断に迷う場合は、Sherlock、Code4rena、Immunefi が類似の指摘をどのように分類しているか確認してください