Audit Prep Assistant

目的

Trail of Bits のチェックリストを使用してセキュリティレビューの準備をしています。よく準備されたコードベースは、レビュープロセスをより円滑かつ効果的にします。

使用時期: セキュリティ監査の 1～2 週間前

---

準備プロセス

ステップ 1: レビュー目標の設定

レビューから得たいものを定義するのに役立ちます：

主要な質問:

• 目標とするセキュリティレベルは？
• 最も懸念される領域は？
  • 過去の監査問題？
  • 複雑なコンポーネント？
  • 脆弱な部分？
• プロジェクトの最悪のシナリオは？

評価チームと共有する目標をドキュメント化します。

---

ステップ 2: 簡単な問題を解決する

スタティック分析を実行し、低リスク項目の修正をサポートします：

スタティック分析を実行:

Solidity の場合：

slither . --exclude-dependencies

Rust の場合：

dylint --all

Go の場合：

golangci-lint run

Go/Rust/C++ の場合：

# CodeQL と Semgrep チェック

その後、以下を実施します：

• すべての検出結果をトリアージ
• 簡単な問題の修正をサポート
• 受け入れたリスクをドキュメント化

テストカバレッジの向上:

• 現在のカバレッジを分析
• テストされていないコードを特定
• 新しいテストを提案
• 完全なテストスイートを実行

デッドコードの除去:

• 未使用の関数/変数を検出
• 未使用のライブラリを特定
• 古い機能を見つける
• クリーンアップを提案

目標: スタティック分析レポートのクリーン化、高いテストカバレッジ、最小限のデッドコード

---

ステップ 3: コードアクセシビリティの確保

コードを明確かつアクセスしやすくするのに役立ちます：

詳細なファイルリストを提供:

• スコープ内のすべてのファイルをリスト
• スコープ外のファイルをマーク
• フォルダ構造を説明
• 依存関係をドキュメント化

ビルド手順を作成:

• ステップバイステップのセットアップガイドを作成
• 新鮮な環境でテスト
• 依存関係とバージョンをドキュメント化
• ビルド成功を確認

安定版を固定:

• レビュー用のコミットハッシュを特定
• 専用ブランチを作成
• リリースバージョンをタグ付け
• 依存関係をロック

ボイラープレートコードを特定:

• コピー/フォークされたコードをマーク
• あなたの変更をハイライト
• サードパーティコードをドキュメント化
• あなたのコードにレビューを集中

---

ステップ 4: ドキュメンテーション生成

ドキュメント作成をサポートします：

フローチャートとシーケンス図:

• 主要なワークフローをマッピング
• コンポーネント間の関係を表示
• データフローを可視化
• クリティカルパスを特定

ユーザーストーリー:

• ユーザーロールを定義
• ユースケースをドキュメント化
• インタラクションを説明
• 期待値を明確化

オンチェーン/オフチェーンの仮定:

• データ検証手順
• オラクル情報
• ブリッジの仮定
• 信頼境界

アクターと権限:

• すべてのアクターをリスト
• ロールをドキュメント化
• 権限を定義
• アクセス制御をマッピング

外部開発者向けドキュメント:

• ドキュメントをコードに紐付け
• 同期を保持
• アーキテクチャを説明
• API をドキュメント化

関数ドキュメンテーション:

• システムと関数の不変式
• パラメータ範囲（最小/最大値）
• 算術公式と精度損失
• 複雑なロジックの説明
• Solidity 用 NatSpec

用語集:

• ドメイン用語を定義
• 頭字語を説明
• 一貫した用語法
• ビジネスロジックの概念

ビデオウォークスルー（オプション）:

• 複雑なワークフロー
• 懸念事項の領域
• アーキテクチャの概要

---

動作方式

起動されると、以下を実施します：

1. レビュー目標の設定をサポート - 懸念事項について質問してドキュメント化
2. スタティック分析を実行 - プラットフォームに適切なツールを実行
3. テストカバレッジを分析 - ギャップを特定し改善を提案
4. デッドコードを検出 - 未使用のコードとライブラリを検索
5. アクセシビリティをレビュー - ビルド手順とスコープの明確性をチェック
6. ドキュメンテーション生成 - フローチャート、ユーザーストーリー、用語集を作成
7. 準備チェックリスト作成 - 完了した内容と残りの内容を追跡

以下に基づいて調整：

• プラットフォーム（Solidity、Rust、Go など）
• 利用可能なツール
• 既存のドキュメンテーション
• レビュータイムライン

---

正当性（スキップしないこと）

正当性	なぜ間違っているのか	必要なアクション
「README でセットアップをカバーしているため、詳細なビルド手順は不要」	README は監査者が持たないコンテキストを前提としている	新しい環境でビルドをテストし、すべての依存関係バージョンをドキュメント化
「スタティック分析はすでに実行済みなので、再度実行する必要はない」	最後の実行以降、コードベースは変更されている	スタティック分析ツールを実行し、新しいレポートを生成
「テストカバレッジはまあまあ見える」	「見える」は測定されたカバレッジではない	カバレッジツールを実行し、テストされていない特定のコードパスを特定
「心配するほどのデッドコードはない」	デッドコードは手動レビュー中に隠れる	自動検出ツールを使用して未使用の関数/変数を検出
「アーキテクチャはシンプルなので、図は不要」	テキスト説明では視覚的なパターンを見落とす	実際のフローチャートとシーケンス図を生成
「監査直前にバージョンを固定できる」	最後の瞬間の固定は急いだ引き継ぎを生成する	今すぐコミットハッシュを特定してドキュメント化し、専用ブランチを作成
「用語は自明である」	ドメイン知識は普遍的ではない	すべてのドメイン固有の用語を含む包括的な用語集を作成
「このステップは後で実施します」	ステップは互いに構築される - スキップはギャップを生成する	すべての 4 ステップを順序を確保して完了し、チェックリストで進捗を追跡

---

出力例

準備完了時には、以下のような具体的な成果物が生成されます：

=== AUDIT PREP PACKAGE ===

Project: DeFi DEX Protocol
Audit Date: March 15, 2024
Preparation Status: Complete

---

## REVIEW GOALS DOCUMENT

Security Objectives:
- Verify economic security of liquidity pool swaps
- Validate oracle manipulation resistance
- Assess flash loan attack vectors

Areas of Concern:
1. Complex AMM pricing calculation (src/SwapRouter.sol:89-156)
2. Multi-hop swap routing logic (src/Router.sol)
3. Oracle price aggregation (src/PriceOracle.sol:45-78)

Worst-Case Scenario:
- Flash loan attack drains liquidity pools via oracle manipulation

Questions for Auditors:
- Can the AMM pricing model produce negative slippage under edge cases?
- Is the slippage protection sufficient to prevent sandwich attacks?
- How resilient is the system to temporary oracle failures?

---

## STATIC ANALYSIS REPORT

Slither Scan Results:
✓ High: 0 issues
✓ Medium: 0 issues
⚠ Low: 2 issues (triaged - documented in TRIAGE.md)
ℹ Info: 5 issues (code style, acceptable)

Tool: slither . --exclude-dependencies
Date: March 1, 2024
Status: CLEAN (all critical issues resolved)

---

## TEST COVERAGE REPORT

Overall Coverage: 94%
- Statements: 1,245 / 1,321 (94%)
- Branches: 456 / 498 (92%)
- Functions: 89 / 92 (97%)

Uncovered Areas:
- Emergency pause admin functions (tested manually)
- Governance migration path (one-time use)

Command: forge coverage
Status: EXCELLENT

---

## CODE SCOPE

In-Scope Files (8):
✓ src/SwapRouter.sol (456 lines)
✓ src/LiquidityPool.sol (234 lines)
✓ src/PairFactory.sol (389 lines)
✓ src/PriceOracle.sol (167 lines)
✓ src/LiquidityManager.sol (298 lines)
✓ src/Governance.sol (201 lines)
✓ src/FlashLoan.sol (145 lines)
✓ src/RewardsDistributor.sol (178 lines)

Out-of-Scope:
- lib/ (OpenZeppelin, external dependencies)
- test/ (test contracts)
- scripts/ (deployment scripts)

Total In-Scope: 2,068 lines of Solidity

---

## BUILD INSTRUCTIONS

Prerequisites:
- Foundry 0.2.0+
- Node.js 18+
- Git

Setup:
```bash
git clone https://github.com/project/repo.git
cd repo
git checkout audit-march-2024  # Frozen branch
forge install
forge build
forge test

Verification: ✓ Build succeeds without errors ✓ All 127 tests pass ✓ No warnings from compiler

---

DOCUMENTATION

Generated Artifacts: ✓ ARCHITECTURE.md - System overview with diagrams ✓ USER_STORIES.md - 12 user interaction flows ✓ GLOSSARY.md - 34 domain terms defined ✓ docs/diagrams/contract-interactions.png ✓ docs/diagrams/swap-flow.png ✓ docs/diagrams/state-machine.png

NatSpec Coverage: 100% of public functions

---

DEPLOYMENT INFO

Network: Ethereum Mainnet Commit: abc123def456 (audit-march-2024 branch) Deployed Contracts:

• SwapRouter: 0x1234...
• PriceOracle: 0x5678... [... etc]

---

PACKAGE READY FOR AUDIT ✓ Next Step: Share with Trail of Bits assessment team

---

## 取得内容

**レビュー目標ドキュメント**:
- セキュリティ目標
- 懸念事項の領域
- 最悪のシナリオ
- 監査人への質問

**クリーンなコードベース**:
- トリアージされたスタティック分析（またはクリーンレポート）
- 高いテストカバレッジ
- デッドコードなし
- 明確なスコープ

**アクセシビリティパッケージ**:
- スコープ付きのファイルリスト
- ビルド手順
- 固定されたコミット/ブランチ
- ボイラープレート特定

**ドキュメンテーションスイート**:
- フローチャートと図
- ユーザーストーリー
- アーキテクチャドキュメント
- アクター/権限マップ
- インラインコードコメント
- 用語集
- ビデオウォークスルー（作成済みの場合）

**監査準備チェックリスト**:
- [ ] レビュー目標をドキュメント化
- [ ] スタティック分析がクリーン/トリアージ済み
- [ ] テストカバレッジ >80%
- [ ] デッドコードを除去
- [ ] ビルド手順を検証
- [ ] 安定版を固定
- [ ] フローチャートを作成
- [ ] ユーザーストーリーをドキュメント化
- [ ] 仮定をドキュメント化
- [ ] アクター/権限をリスト
- [ ] 関数ドキュメント完了
- [ ] 用語集を作成

---

## タイムライン

**監査の 2 週間前**:
- レビュー目標を設定
- スタティック分析を実行
- 問題の修正を開始

**監査の 1 週間前**:
- テストカバレッジを向上
- デッドコードを除去
- 安定版を固定
- ドキュメンテーションを開始

**監査の数日前**:
- ドキュメンテーションを完成
- ビルド手順を確認
- 最終チェックリストを作成
- 監査人にパッケージを送信

---

## 準備完了

準備ができたら、セキュリティレビューの準備をサポートします！