手法とプロセス

umibit AI の全網羅 + シニアセキュリティエンジニアの判断

私たちは監査プロセスを完全に透明に示します。umibit AI が全コードを全網羅でレビューして見逃しを防ぎ、シニアセキュリティエンジニアが一件ずつ検証して誤検知を取り除き、悪用可能性を確認し、ビジネスロジックと経済モデルの分析を独立して行います。機械が広さを担保し、エキスパートが判断を担保します。

二層のチェックで、相互に検証

機械とエキスパートがそれぞれの役割を担い、補完し合い、相互に検証します。

umibit AI の担当 AI

umibit 独自開発の AI セキュリティエンジンを基盤に、全コードに対して高カバレッジの一次レビューを行います。ホワイトボックス、バックドア、CVE、オフチェーン、ブラックボックス探索までをカバーし、広さを担保します——見逃しません。

  • ホワイトボックス・ソースコードスキャン:semgrep ルールセット + 独自の高リスクパターン
  • バックドア / ハニーポット特徴とセンシティブな関数の識別
  • 依存関係の CVE と SBOM のバージョン範囲マッチング
  • オフチェーンインフラ・鍵・設定の一次スクリーニング
  • ブラックボックス・プローブ:決定論的スキャン + 自律 agent の二系統

シニアセキュリティエンジニアの担当 人工

エキスパートが AI の出力を一件ずつ精査し、誤検知を取り除き、実際の悪用可能性を確認して PoC を作成します。さらにビジネスロジックと経済モデルの分析を独立して行い、深さと判断を提供します。

  • AI の出力を一件ずつ人手で検証し、誤検知を取り除く
  • 実際の悪用可能性を確認し、再現可能な PoC を作成
  • ビジネスロジックの脆弱性とステートマシンの分析
  • 経済モデル / トークノミクスとアービトラージ経路のレビュー
  • 中央集権的な権限、デプロイの整合性、最終的な深刻度判定
プロセス

監査プロセス

範囲の確定から、公開検証できる最終版レポートまで、7つの段階で責任の所在が明確です。

01

初期評価

監査範囲・コントラクト一覧・バージョン / デプロイアドレス・ドキュメントを明確にします。範囲内と範囲外を文書で明記し、責任を画定する基準とします。

02

全網羅レビュー

umibit AI が全コードに対して高カバレッジの一次レビューを行い、一般的な脆弱性パターン(ホワイトボックス / バックドア / CVE / オフチェーン)を検出します。

03

エキスパート検証と PoC

シニアセキュリティエンジニアが、すべての AI 出力を一件ずつ人手で検証します。誤検知を取り除き、実際の悪用可能性を確認し、再現可能な PoC を作成します。さらにビジネスロジックと経済モデルの分析を独立して行います。

04

初版レポート

初版レポート(Draft)を発行します。各脆弱性に説明・影響・PoC・修正提案を記載し、深刻度とステータスを添えます。

05

クライアントによる修正

クライアントが提案に沿って修正し、フィードバックします。私たちは修正方針について必要な質疑応答と確認を行います。

06

再監査・再検証

修正後の指定バージョンに対して再監査を行い、「修正済み / 緩和済み / 認識済み」のステータスを一件ずつ検証します。

07

最終版レポート

最終版レポート(Final)を発行し、公開検証できる場所に公表します。バージョン・コントラクトアドレス・日付を添えます。

評価

深刻度の定義

深刻度 = 影響 × 可能性。

影響 \ 可能性
CriticalHighMedium
HighMediumLow
MediumLowLow

等級の定義

Critical(重大)資金の損失やプロジェクトの制御不能に直結し、ローンチ前に必ず修正が必要です。未修正の Critical が残るプロジェクトは利用すべきではありません。
High(高)特定の条件下で資金の損失や支配権の喪失につながり得ます(深刻な中央集権的権限、ロジックの誤りを含む)。
Medium(中)ユーザーの資金を直接脅かすことはありませんが、プロトコルの正常な機能に影響したり、境界条件下で損害を引き起こしたりします。
Low(低)影響が限定的な軽微な問題、または規範に沿わない実装。
Informational(情報)コードスタイル、Gas 最適化、ベストプラクティスの提案であり、直接的なセキュリティ影響はありません。

ステータスの定義

Open報告済みで、クライアントが未対応。
Acknowledgedクライアントが確認したうえで修正しないことを選択。その説明と残存リスクを添付。
Resolvedクライアントが修正し、監査側が再監査で検証済み。
Mitigated根絶はされていないが、対策によりリスクが低減済み。
チェックリスト

レビューチェックリスト

手法は透明に。以下は、私たちが一項目ずつ確認するチェックリストです。

中央集権的な権限トークン監査で最も重要なポイント

  • 追加発行権限 mint:owner が無制限 / 上限なしで増発できないか
  • owner の特権:取引の一時停止、ブラックリスト登録、残高の凍結、税率の自由な変更
  • 取引スイッチ:owner が全員の取引をワンクリックで停止できないか
  • ブラック / ホワイトリスト:存在の有無、悪用の可能性
  • 権限ガバナンス:重要権限が単一の EOA ではなく、マルチシグ + タイムロックに委ねられているか
  • renounce の確認:権限放棄をうたいながら、実際にはバックドアを残していないか

ハニーポット / バックドア(Honeypot)

  • 買えるのに売れない:転送(売却)経路が特殊な条件で遮断されていないか
  • 特定のアドレスだけが売却できる
  • 送金時のひそかな差し引き / 隠しロジック:transfer 内に控除やリダイレクトが仕込まれていないか
  • 手数料の操作:買い / 売り税が極端な値(例:99%)に変更できないか

経済メカニズム

  • リフレクション / fee-on-transfer:計算と端数処理、外部プロトコルとの互換性
  • 流動性:LP がロックされているか、owner がプールを引き上げて持ち逃げできないか
  • インセンティブ / アービトラージ経路:継続的にアービトラージや操作が可能な設計がないか
  • オラクル依存 / フラッシュローン / MEV リスク

古典的なコントラクト脆弱性

  • リエントランシー:ERC-777 コールバック、fee-on-transfer + 外部呼び出しのシナリオ
  • 整数オーバーフロー / アンダーフロー:0.8 以降は既定で安全、古いコード / unchecked は要確認
  • approve のレースコンディション / 承認管理
  • アクセス制御の欠如、または誤った修飾子
  • アップグレード可能なコントラクト / プロキシ:ロジックがひそかに差し替えられないか
  • 未検証の外部呼び出し戻り値、低レベル call のリスク

デプロイの整合性

  • バイトコード照合:オンチェーンのバイトコードが監査対象のソースコードと一致するか(「A を監査して B をデプロイ」を防ぐ)
  • コンストラクタ引数:初期化パラメータがドキュメントと一致するか
この手法は汎用的なフレームワークであり、各プロジェクトの実際の範囲に合わせて調整します。範囲内と範囲外の内容は、いずれもレポートに明記し、責任を画定する基準とします。