Sui上のDeFiプロトコルで約15万SUIの不正流出が報じられました。注目点は、最新の中核コントラクトではなく「過去にデプロイされた古いコントラクト」の脆弱性が突破口になった点です。監査やバグバウンティを強化していても、運用上「もう使っていない」と見なした資産が攻撃面として残ることを示しています。
企業のセキュリティ担当者にとっては、脆弱性の種類そのものより、どこまで攻撃面を把握し縮小できているかが論点です。UIや公式導線から切り離しても、オンチェーンに存在する限り第三者による直接呼び出しは可能です。旧コントラクトが資金移動や権限に少しでも関与していれば、そこが最短ルートになります。
運用面では監査・テスト・監視が最新版に偏り、旧版はレビューやアラートの対象外になりがちです。心理面でも「資金は移した」「影響は限定的」という安心感が優先され、棚卸しや停止手順が後回しになります。結果として、旧版に残った移行用機能や救済機能、委任権限が“抜け道”化します。
攻撃者はデプロイ履歴やトランザクションログから依存関係を辿り、権限の名残や資産経路を探索します。新旧の併存期間に残った許可設定、互換レイヤー、管理者関数は特に狙われます。最新版が堅牢でも、旧版の一箇所の欠陥で被害が成立する点が現場の盲点です。
まず「コントラクト棚卸し」を継続業務にします。稼働中・停止済み・移行中を一覧化し、各モジュールが触れられる資産、持つ権限、呼び出し可能者を可視化します。資産と権限をグラフとして捉え、旧版が経路上に残っていないかを定期点検します。
次に監視設計を「コード世代」ではなく「資産経路」起点にします。送金・引き出し・担保移動・清算・ミント/バーン・権限変更といった重要動作を横断的に監視し、旧コントラクトで発生しても検知できるようにします。異常頻度、想定外の呼び出し元、権限変更の兆候を即時対応につなげる体制が必要です。
「監査済み」は最新版の一時点評価に過ぎず、残存リスクは時間とともに増えます。プロトコルが複雑化するほど、過去のコード・過去の権限・過去の移行経路が負債として蓄積します。したがって、棚卸し、停止手順、監視ルールの更新をセットで回すことが重要です。
自社がWeb3/DeFi連携を行う場合も、ベンダやプロトコルの最新版だけでなく、旧版の残存状況や停止可能性を確認項目に入れるべきです。インシデント時はフィッシング誘導も増えるため、公式情報の確認経路や社内エスカレーションも整備します。レガシー管理を「例外対応」ではなく「平時の運用」に落とし込めるかが、被害抑止の分岐点になります。
