scv-scan

スマートコントラクト脆弱性監査

徹底性と効率性のバランスを取りながら、4 段階のアプローチで Solidity コードベースの脆弱性を体系的に監査します。

使用する場面

• デプロイ前に Solidity コードベースのセキュリティ脆弱性を監査する
• 一般的な悪用パターン（リエントランシー、オーバーフロー、アクセス制御など）についてスマートコントラクトのコードをレビューする
• Solidity プロジェクト全体で、構造化された脆弱性スキャンを実施する
• 変更後に、コントラクトがセキュリティのベストプラクティスに従っていることを検証する

使用しない場面

• Solidity 以外のスマートコントラクト（Vyper、Rust/Anchor、Move）を監査する場合 — パターンが Solidity 固有です
• オフチェーンコード（JavaScript、TypeScript のバックエンド）をレビューする場合 — 代わりに一般的なセキュリティレビューを使用してください
• ユーザーがガス最適化やコードスタイルのフィードバックのみを求めている場合 — このスキルは悪用可能な脆弱性に焦点を当てています
• 不変条件の形式検証を行う場合 — 代わりに Certora、Halmos、Echidna などのツールを使用してください

拒否すべき誤った正当化

• 「コンパイラのバージョンが >=0.8.0 だからオーバーフローは起こらない」— unchecked ブロック、アセンブリ、型のダウンキャストでは、依然としてラップアラウンドが発生します
• 「OpenZeppelin を使っているから安全だ」— 統合時のバグ、誤った継承順序、カスタム関数への修飾子の付け忘れはよくある問題です
• 「その関数は内部関数だから悪用できない」— 外部エントリーポイントから呼び出される内部関数は、呼び出し元のコンテキストを引き継ぎます
• 「ETH を扱っていないからリエントランシーは関係ない」— ERC721 の _safeMint、ERC1155 の安全な転送、ERC777 のフックはすべてコールバックを発生させます
• 「コントラクトはアップグレード可能だから、後で修正できる」— initializer 修飾子のない initialize() 自体が重大な脆弱性です

参照ファイルの構成

references/
  CHEATSHEET.md          # Condensed pattern reference — always read first
  reentrancy.md          # Full reference files — read selectively in Phase 3
  overflow-underflow.md
  ...

references/ 内の各参照ファイルには、次のセクションがあります。

• 前提条件 — 脆弱性が存在するために満たされている必要がある条件
• 脆弱なパターン — 注釈付きの Solidity のアンチパターン
• 検出ヒューリスティック — 脆弱性を確認するための段階的な推論
• 誤検知 — パターンが見られても悪用できない場合
• 修正方法 — 脆弱性の修正方法

監査ワークフロー

フェーズ 1：チートシートを読み込む

Solidity ファイルに触れる前に、{baseDir}/skills/scv-scan/references/CHEATSHEET.md を最後まで読んでください。

このファイルには、既知の脆弱性クラスごとに、名前、確認する項目（構文上および意味上の観点）、デフォルトの重大度をまとめた項目があります。これらのパターンを理解し、スイープ段階での検出対象としてください。まだ完全な参照ファイルは読まないでください。

フェーズ 2：コードベースをスイープする

コードベースに対し、相互に補完する 2 つのパスを実施します。

パス A：構文上の grep スキャン

チートシートの「grep 可能なキーワード」に記載されているトリガーパターンを検索します。grep または ripgrep を使って一致箇所を探してください。

一致するたびに、ファイル、行番号、一致したパターン、疑われる脆弱性の種類を記録します。

パス B：構造的／意味的分析

このパスでは、信頼できる grep のシグネチャがない脆弱性を検出します。チートシートで説明されているロジックに類似する、関連ロジックがないかコードベースを読み進めてください。

このパスで検出した項目ごとに、ファイル、行番号、懸念事項の説明、疑われる脆弱性の種類を記録します。

候補リストを作成する

パス A とパス B の結果を統合し、重複のない候補リストを作成します。各項目は次の形式にします。

- File: `path/to/file.sol` L{start}-L{end}
- Suspected: [vulnerability-name] (from CHEATSHEET.md)
- Evidence: [brief description of what was found]

フェーズ 3：選択的な詳細検証

リスト内の各候補について、以下を行います。

1. 疑われる脆弱性の種類に対応するリファレンスファイル全体を読みます（例：{baseDir}/skills/scv-scan/references/reentrancy.md）。事前ではなく、今読みます。
2. 実際のコードに照らして、検出ヒューリスティックの各ステップをすべて確認します。 正確に行ってください。変数の値を追跡し、修飾子を確認し、呼び出しチェーンをたどります。
3. すべての誤検知条件を確認します。 誤検知条件に該当するものがあれば、その検出結果を破棄し、理由を記録します。
4. 相互参照します。 1 つのコード箇所が複数の脆弱性の種類に該当する場合があります。チートシートで同じパターンが複数のリファレンスに対応付けられている場合は、それぞれを読み、検証します。
5. 確認するか、破棄します。 確認された検出結果のみを最終レポートに記載します。

フェーズ 4：レポート

確認された検出結果ごとに、以下を出力します。

### [Vulnerability Name]

**File:** `path/to/file.sol` L{start}-L{end}
**Severity:** Critical | High | Medium | Low | Informational

**Description:** What is vulnerable and why, in 1-3 sentences.

**Code:**
```solidity
// The vulnerable code snippet

推奨事項： リファレンスファイルの「修正」セクションを参照し、具体的な修正方法を示します。

After all findings, include a summary section:

概要

重大度	件数
重大	N
高	N
中	N
低	N
情報	N

Write the final report to `scv-scan.md`.

## Severity Guidelines

- **Critical**: Direct loss of funds, unauthorized fund extraction, permanent freezing of funds
- **High**: Conditional fund loss, access control bypass, state corruption exploitable under realistic conditions
- **Medium**: Unlikely fund loss, griefing attacks, DoS on non-critical paths, value leak under edge conditions
- **Low**: Best practice violations, gas inefficiency, code quality issues with no direct exploit path
- **Informational**: Unused variables, style issues, documentation gaps

## Key Principles

- **Cheatsheet first, references on-demand.** Never read all full reference files upfront. The cheatsheet gives you ambient awareness; full references are for validation only.
- **Semantic > syntactic.** The hardest bugs don't grep. Cross-function reentrancy, missing access control, incorrect inheritance — these require reading and reasoning, not pattern matching.
- **Trace across boundaries.** Follow state across function calls, contract calls, and inheritance chains. Hidden external calls (safe mint/transfer hooks, ERC-777 callbacks) are as dangerous as explicit `.call()`.
- **One location, multiple bugs.** A single line can be vulnerable to reentrancy AND unchecked return value. Check all applicable references.
- **Version matters.** Always check `pragma solidity` — many vulnerabilities are version-dependent (e.g., overflow is checked by default in >=0.8.0).
- **False positives are noise.** Be rigorous about checking false positive conditions. A shorter report with high-confidence findings is more valuable than a long one padded with maybes.