コードが全く理解できず、2つのプロトコルのロジックが本当に類似しているかを自分で判断できない場合、どうすればいいですか？
コードの詳細を自分で読む必要はない。この5つのステップで本当に必要な技術力は「検索と読解」であり、「プログラムロジックの理解」ではない。ステップ1と2は検索エンジンで完了できる。ステップ3で監査レポートの技術用語が理解できない場合、この既知の弱点に関連する段落を直接コピーし、サポートやコミュニティのメンバーに平易な言葉で説明してもらうよう頼むことができる。ステップ4は単にこのチームが過去に公に発言したことがあるかを確認するだけであり、コードの読解は伴わない。
あるステップを全く完了できないことに気づいた場合（監査レポート自体が公開されていない、プロトコル側が関連する質問への回答を拒否するなど）、この「見つからない」という結果自体も意味のある情報である——この層の透明性が不十分であることを意味し、この情報の欠落自体を独立したリスク要因として扱う価値がある。
見つかった類似性が表面的なものにすぎない場合（同じプログラミング言語を使っているなど）、これは本当のクロスプロトコル攻撃シグネチャと言えますか？
言えない。これは重要な区別である。クロスプロトコル攻撃シグネチャとは、具体的なロジック構造の類似性（同じ関数呼び出しの順序、同じ権限検証フローの設計など）を指し、一般的な技術選定の類似性（同じくSolidityで書かれている、同じチェーンにデプロイされているなど）ではない。ほとんどのプロトコルは同じ主流のプログラミング言語を使用しており、このレベルの類似性は意味のあるリスクシグナルを全く構成しない。
本当に注目すべき類似性は、ステップ2で見つけた具体的な攻撃の技術的詳細（攻撃者がどの部分のプログラムロジックを悪用したか、脆弱性をトリガーするのにどんな前提条件が必要だったか）を検証した後、使用しているプロトコルが本当に全く同一または高度に類似したロジック構造を持っているかを確認することであり、「同じプログラミング言語」「同じ貸出プロトコル」といった表層的な特徴だけを見て、両者が比較可能な攻撃シグネチャを持つと直接結論づけることではない。
プロトコルチームが「既知の脆弱性に対して修正を行ったか」という私の質問への回答を拒否した場合、それは何を意味しますか？
これは2つの可能な拒否の状況を区別する必要がある。一つは、チームが合理的なセキュリティ上の考慮から、詳細な修正の技術的詳細を公開したがらない場合（詳細を明らかにすることが逆に潜在的な攻撃者を助けることを避けるため）である。この場合、より合理的な方法は、チームに間接的な証拠を提供できるか尋ねることである——第三者監査レポートがこの問題をカバーしているか、あるいは技術的詳細を伴わない高レベルの確認（「はい、私たちはこの問題を認識し、対処を完了しました」など）を提供できるか。
もう一つの状況は、チームが全く回答せず、あるいは曖昧な言葉でこの具体的な質問を回避する場合であり、この状況はより警戒を強めるべきである。なぜなら本シリーズで前述した透明性の原則がここにも適用されるからだ——責任あるチームは、たとえ技術的詳細を公開するのが不都合であっても、通常何らかのレベルの確認や高レベルの説明を提供する意欲がある。完全な沈黙や回避自体が、リスク評価リストに加える価値のあるシグナルである。
このチェックリストは、本シリーズで前述した他のデューデリジェンスチェックリスト（クロスチェーンブリッジのファイナリティチェックなど）とどう優先順位をつければいいですか？
実務上、異なるデューデリジェンスチェックリストは異なるリスク次元を対象としており、理想的には全て実行すべきだが、時間が限られており優先順位をつける必要がある場合、シンプルな判断原則を参考にできる：あなたが使っている製品の「具体的な技術特性」に直接関連するチェックリストを優先的に実行する——この製品がクロスチェーン操作を伴う場合、クロスチェーンブリッジのファイナリティチェックを優先する。この製品が有名なオープンソーステンプレートを採用している、または最近同業他社で似たアーキテクチャの事故が起きた場合、このクロスプロトコル攻撃シグネチャの比較を優先する。
評価している製品が複数の技術的次元にまたがる場合、時間コストの低いチェック（公開情報の確認、監査レポートの閲覧）を先に行い、チームに能動的に連絡して尋ねる必要のあるステップを後回しにすることも検討できる。そうすれば、時間が足りず全てのチェックリストを完了できなくても、低コストのチャネルを通じて既に明らかなリスクの一部を排除できている。
本シリーズでは以前クロスプロトコル攻撃シグネチャという概念について触れた——攻撃者はあるプロトコルを突破した後、しばしば同じ手法をそのままアーキテクチャが似た他のプロトコルに持ち込む。この記事では、あなたが使っているDeFAI製品が、最近突破されたプロトコルと類似の脆弱な構造を共有していないかを判断するのに役立つ、実用的な比較チェックリストを示す。
ほとんどのDeFiおよびDeFAIプロトコルはゼロからコードを書くのではなく、広く流通しているオープンソースのテンプレートを参照または直接フォークして修正している。まず、使用しているプロトコルの技術文書やコードリポジトリに「[有名なオープンソースプロジェクト]に基づいて構築」と明確に記載されているかを確認する。これが類似性を判断する最も直接的な手がかりである。
テンプレート名を見つけたら、「[テンプレート名] exploit」や「[テンプレート名] vulnerability」といったキーワードで検索し、同じテンプレートに基づく他のプロトコルが攻撃事件を起こしたことがあるかを確認する。関連する事件が見つかれば、その事件の技術分析をさらに読み、攻撃者が具体的にテンプレートのどの部分のロジックを悪用したかを理解する価値がある。
既知の脆弱なロジック部分を見つけたら、使用しているプロトコルの監査レポートや更新履歴を確認し、このロジックが既に修正されているか、それとも元のテンプレートの書き方のままかを確認する。プロトコル側が「私たちはこの種の既知の脆弱性に対して強化を行いました」と公に説明していれば、これは具体的で信頼に値するポジティブなシグナルである。
単一のコード部分が類似しているかを比較すること以外に、このプロトコルチームが過去に同業他社で起きた攻撃事件を公に議論したことがあるか、自社のアーキテクチャが影響を受けるかを能動的に説明したことがあるかを確認する価値もある。同業他社の教訓に能動的に注目するチームは、通常セキュリティを継続的な作業として扱っており、ローンチ後は二度と見直さない一度限りの事項として扱っていないことを意味する。
最初の4つのステップを経て、使用しているプロトコルが既知の突破されたプロトコルと確かに類似のロジックを共有しており、修正の記録が全く見つからないことがわかった場合、それは直ちに撤退する必要があることを意味しないが、この発見を正直にポジション計画で追加考慮すべきリスク要因として扱い、この現時点で排除できない不確実性に、より保守的な投入金額で対応する価値がある。
この5つのステップは、本シリーズで前述したクロスプロトコル攻撃シグネチャの概念を、あなたが自分で実際に操作できる比較チェックリストに変えたものである。ほとんどのユーザーはプロトコルを評価する際、そのプロトコル自体に過去事故が起きたことがあるかだけを見る。このチェックリストは、同業他社の教訓も同様に、あなたが使っている製品と照らし合わせる価値があることを思い出させてくれる。攻撃者は一度攻撃しただけで手を引くことは滅多にないからだ。