code-maturity-assessor

コード成熟度アセッサー

目的

Trail of Bits の9カテゴリのフレームワークを使用して、コードベースの成熟度を体系的に評価します。証拠に基づく評価と、実行可能な推奨事項を提示します。

フレームワーク：Building Secure Contracts - Code Maturity Evaluation v0.1.0

---

仕組み

フェーズ1：調査

コードベースを調査し、以下を把握します。

• プロジェクトの構造とプラットフォーム
• コントラクト／モジュールのファイル
• テストカバレッジ
• ドキュメントの有無

フェーズ2：分析

9つのカテゴリそれぞれについて、以下を行います。

• 関連するパターンをコード内で検索します
• 実装を評価するために主要なファイルを読みます
• ファイルへの参照を添えて調査結果を提示します
• コードからは確認できないプロセスについて確認の質問をします
• 基準に基づいて評価を決定します

フェーズ3：レポート

以下を作成します。

• エグゼクティブサマリー
• 成熟度スコアカード（9カテゴリすべての評価）
• 根拠を示した詳細な分析
• 優先順位順の改善ロードマップ

---

評価システム

• 不足（0）：存在しない／実装されていない
• 弱い（1）：大幅な改善が複数必要
• 中程度（2）：十分だが、改善の余地がある
• 良好（3）：平均を上回り、軽微な改善のみ必要
• 優れている（4）：卓越しており、可能な改善はわずか

評価ロジック：

• 「弱い」に該当する基準が1つでもある → 弱い
• 「弱い」はなく、「中程度」の基準の一部が未達 → 中程度
• 「中程度」の基準をすべて満たし、「良好」の基準の一部を満たす → 良好
• 「良好」の基準をすべて満たし、卓越したプラクティスがある → 優れている

---

9つのカテゴリ

コード成熟度のあらゆる側面を網羅する、包括的な9つのカテゴリを評価します。詳細な基準、分析方法、評価のしきい値については、ASSESSMENT_CRITERIA.mdを参照してください。

クイックリファレンス：

1. 算術

• オーバーフロー保護の仕組み
• 精度の処理と丸め
• 数式の仕様
• エッジケースのテスト

2. 監査

• イベントの定義と網羅性
• 監視インフラストラクチャ
• インシデント対応計画

3. 認証／アクセス制御

• 権限管理
• ロールの分離
• アクセス制御のテスト
• 鍵の漏えいシナリオ

4. 複雑さの管理

• 関数のスコープと明確さ
• 循環的複雑度
• 継承階層
• コードの重複

5. 分散化

• 集中化のリスク
• アップグレード制御の仕組み
• ユーザーがオプトアウトする手段
• タイムロック／マルチシグのパターン

6. ドキュメント

• 仕様とアーキテクチャ
• インラインのコードドキュメント
• ユーザーストーリー
• ドメイン用語集

7. トランザクション順序付けのリスク

• MEV の脆弱性
• フロントランニング対策
• スリッページ制御
• オラクルのセキュリティ

8. 低レベル操作

• アセンブリの使用
• 安全でないコード箇所
• 低レベルの呼び出し
• その使用根拠とテスト

9. テストと検証

• テストカバレッジ
• ファジングと形式検証
• CI/CD との統合
• テストの品質

分析内容、確認事項、詳細な評価のしきい値（WEAK/MODERATE/SATISFACTORY/STRONG）を含む評価基準の全容については、ASSESSMENT_CRITERIA.mdを参照してください。

---

出力例

評価が完了すると、以下を含む包括的な成熟度レポートが提供されます。

• エグゼクティブサマリー：全体スコア、主な強みトップ3、主なギャップトップ3、優先度の高い推奨事項
• 成熟度スコアカード：9つのカテゴリすべてのスコアと注記を記載した表
• 詳細分析：根拠（ファイル名と行番号の参照）を添えたカテゴリ別の分析
• 改善ロードマップ：作業量の見積もりを含む優先順位順の推奨事項（CRITICAL/HIGH/MEDIUM）

評価レポートの完全な例については、EXAMPLE_REPORT.mdを参照してください。

---

評価プロセス

呼び出されると、以下を行います。

1. コードベースを調査

   • コントラクト／モジュールのファイルを探す
   • テストファイルを特定する
   • ドキュメントを探す

2. 各カテゴリを分析

   • 関連するコードパターンを検索する
   • 主要な実装を読む
   • 基準に照らして評価する
   • 根拠を収集する

3. 対話型評価

   • ファイル参照とともに調査結果を提示する
   • コードから確認できないプロセスについて質問する
   • 判断が分かれるケースについて話し合う
   • 一緒に評価を決定する

4. レポートを作成

   • エグゼクティブサマリー
   • 成熟度スコアカードの表
   • 根拠を含むカテゴリ別の詳細分析
   • 優先順位を付けた改善ロードマップ

---

もっともらしい言い訳（省略しないでください）

もっともらしい言い訳	それが誤りである理由	必須の対応
「いくつか見つかったので、評価は完了です」	評価では9つすべてのカテゴリを確認する必要があります	9つすべてのカテゴリについて、それぞれ根拠を示して評価を完了する
「イベントがあるので、監査カテゴリは問題なさそうです」	イベントがあるだけでは、監査の成熟度を判断できません	ログの網羅性、テスト、インシデント対応プロセスを確認する
「コードがシンプルなので、複雑度は低そうです」	見た目のシンプルさでは、構成の複雑さが見えないことがあります	循環的複雑度、依存関係の深さ、ステートマシンの遷移を分析する
「DeFiプロトコルではないので、MEVカテゴリは該当しません」	MEVはDeFiに限らず、ガバナンス、NFT、ゲームにも関係します	N/Aと判断する前に、トランザクション順序の分析で確認する
「アセンブリが見つからないので、低レベルカテゴリはN/Aです」	低レベルのリスクには、外部呼び出し、delegatecall、インラインアセンブリも含まれます	このカテゴリを省略する前に、低レベルのパターンをすべて検索する
「時間がかかりすぎます」	網羅的な評価には、カテゴリごとに時間が必要です	9つすべてのカテゴリを完了し、オフチェーンのプロセスについて確認の質問をする
「根拠がなくても評価できます」	file:lineの参照がない評価は、裏付けのない主張です	各カテゴリの評価に対して、具体的なコードの根拠を収集する
「ユーザーは改善点が分かるでしょう」	曖昧な案内では、行動につながりません	具体的な改善策と工数の見積もりを含め、優先順位を付けたロードマップを提示する

---

レポート形式

詳細なレポート構成とテンプレートについては、REPORT_FORMAT.mdを参照してください。

構成：

1. エグゼクティブサマリー

   • プロジェクト名とプラットフォーム
   • 全体的な成熟度（評価の平均）
   • 主な強みトップ3
   • 重大なギャップトップ3
   • 優先度の高い推奨事項

2. 成熟度スコアカード

   • 9つすべてのカテゴリを含む表
   • 評価とスコア
   • 主な調査結果の注記

3. 詳細分析

   • カテゴリごとの内訳
   • file:line参照付きの根拠
   • ギャップと改善アクション

4. 改善ロードマップ

   • CRITICAL（直ちに対応）
   • HIGH（1～2か月）
   • MEDIUM（2～4か月）
   • 工数の見積もりと影響

---

さっそく始めましょう

所要時間の目安：30～40分

必要なもの：

• コードベース全体へのアクセス
• プロセスに関する知識（監視、インシデント対応、チームの慣行）
• プロジェクトの背景（DeFi、NFT、インフラなど）

このコードベースを評価しましょう！