本連載記事は、OKX Web3とBlockSecが共同キュレーションした「セキュリティ特別号05」からの抜粋であり、DeFiユーザーやDeFiプロジェクトチームが直面するセキュリティ上の懸念に対処します。
Q1：DeFiプロジェクトのセキュリティとリスクプロファイルを予備的に評価するために、どのような基準や指標を使用できますか？
BlockSecセキュリティチーム： DeFiプロジェクトに投資する前に、プロジェクトの包括的なセキュリティ評価を実施することが不可欠です。これは、多額の資本を持つ参加者にとって特に重要であり、セキュリティにおける必要なデューデリジェンスにより、資金の安全性を最大限に確保できます。
まず、プロジェクトのコードセキュリティを包括的に評価することが推奨されます。これには、プロジェクトが良好なセキュリティ評価実績を持つ監査会社によって監査されているかどうか、複数の監査会社が関与しているかどうか、最新のコードが監査されているかどうかなどが含まれます。一般的に、オンラインで実行されているコードが、良好な評判を持つ複数のセキュリティ会社によって監査されている場合、セキュリティ攻撃のリスクは大幅に軽減されます。
次に、プロジェクト側がリアルタイムのセキュリティ監視システムを導入しているかどうかを確認することが重要です。セキュリティ監査は静的なセキュリティを確保するものであり、プロジェクトの稼働後に発生する動的なセキュリティ問題は解決できません。例えば、プロジェクト側がプロジェクトの主要な運用パラメータを不適切に調整したり、新しいプールを追加したりする場合です。プロジェクト側が何らかのリアルタイムセキュリティ監視システムを採用している場合、その運用セキュリティレベルは、そのようなソリューションを採用していないプロトコルよりも高くなります。
第三に、しばしば見落とされる、自動化された緊急対応能力にアクセスします。多くのセキュリティインシデントにおいて、プロジェクトには重要な機能に対する自動化されたサーキットブレーカーが欠如していることが観察されています。緊急事態を手動で処理することは、非効率的であり、時には効果がないことが証明されています。
第四に、プロジェクトの外部依存性とその堅牢性への依存度を精査します。DeFiプロジェクトは、価格や流動性のようなサードパーティのデータに依存することがよくあります。したがって、外部依存性の数、外部依存プロジェクトのセキュリティ、および外部依存からの異常データの監視とリアルタイム処理があるかどうかという観点から、プロジェクトのセキュリティを評価する必要があります。一般的に、トップティアのプロジェクトに依存し、フォールトトレランスと外部プロジェクトからの異常データのリアルタイム処理を備えたプロジェクトは、より安全になります。
第五に、プロジェクト側が比較的良好なコミュニティガバナンス構造を持っているかどうかは非常に重要です。これには、プロジェクト側が主要なイベントに対してコミュニティ投票メカニズムを持っているかどうか、機密性の高い操作がマルチシグネチャで完了されるかどうか、マルチシグネチャウォレットに中立的なコミュニティ参加が導入されているかどうか、コミュニティセキュリティ委員会があるかどうかなどが含まれます。これらのガバナンス構造は、プロジェクトの透明性を向上させ、プロジェクトにおけるユーザー資金のラグプル（詐欺的なプロジェクト終了）の可能性を減らすことができます。
最後に、プロジェクト側の過去の経歴も非常に重要です。プロジェクトチームとコアメンバーのバックグラウンドチェックを実施する必要があります。プロジェクト側のコアメンバーが過去のプロジェクトで複数の攻撃やラグプルの履歴を持っている場合、そのようなプロジェクトのセキュリティリスクは比較的高くなります。
要約すると、DeFiプロジェクトに参加する前に、ユーザー、特に多額の資本を持つユーザーは、プロジェクト稼働前のコードセキュリティ監査から、プロジェクト稼働後のリアルタイムセキュリティ監視と自動応答機能の構築まで、プロジェクト側のセキュリティ投資と安全性を調査し、外部依存性、ガバナンス構造、プロジェクト側の履歴の観点からデューデリジェンスを実施して、プロジェクトに投資した資金の安全性を確保する必要があります。
OKX Web3ウォレットセキュリティチーム： DeFiプロジェクトにおける絶対的なセキュリティは保証できませんが、ユーザーはこれらの主要な側面を考慮することで、セキュリティとリスクプロファイルを評価できます。
-
プロジェクトの技術セキュリティ：
- 1）プロジェクトが、評判の良い経験豊富な複数の監査会社によって監査されているかどうかを確認します。
- 2）監査レポートで報告された問題の数と重大度を確認し、すべてが対処されていることを確認します。
- 3）デプロイされたコードが監査されたバージョンと一致していることを検証します。
-
オープンソースコード：
- 1）コミュニティやセキュリティ専門家がレビューし、セキュリティ上の問題を発見できるかどうか、プロジェクトのコードがオープンソースかどうかを判断します。
- 2）開発チームのバックグラウンド、ブロックチェーンとセキュリティにおける経験、およびチームに関する透明性と公開情報のレベルを調査します。
- 3）バグバウンティ：脆弱性を報告するようセキュリティ研究者にインセンティブを与えるバグバウンティプログラムの存在を探します。
-
財務および経済的セキュリティ：
- 1）ロックされた資金：スマートコントラクトにロックされた資金の量を確認します。量が多いほど、プロジェクトへの信頼度が高いことを示唆する可能性があります。
- 2）取引量と流動性：プロジェクトの取引量と流動性を評価します。流動性が低いと、価格操作のリスクが高まる可能性があります。
- 3）トークン経済モデル：トークン配布、インセンティブメカニズム、インフレモデルなど、トークノミクスを評価し、過度に集中したトークン保有がないかなどを確認します。
-
運用および管理セキュリティ：
- 1）ガバナンスメカニズム：プロジェクトのガバナンス構造、分散型ガバナンスがあるかどうか、コミュニティが重要な決定に投票できるかどうかを理解します。ガバナンストークンの配布と投票権の集中度を分析します。
- 2）リスク管理措置：プロジェクトが潜在的なセキュリティ脅威や経済的攻撃に対処するためのリスク管理措置と緊急時対応計画を備えているかどうかを判断します。また、プロジェクトの透明性とコミュニティコミュニケーション（定期的な進捗レポート、セキュリティアップデート、コミュニティとの積極的な関与など）も考慮します。
-
市場とコミュニティの認識：
- 1）コミュニティエンゲージメント：プロジェクトのコミュニティ活動とユーザーベースを評価します。活発なコミュニティは、プロジェクトに対する広範な支持を示していることが多いです。
- 2）メディアとソーシャルメディアのセンチメント：メディアとソーシャルメディアにおけるプロジェクトの受け止め方を分析し、ユーザーや業界専門家の視点を理解します。
- 3）パートナーシップと投資家：プロジェクトが著名なパートナーや投資家から支援を受けているかどうかを確認します。これはプロジェクトに信頼性を与える可能性がありますが、セキュリティの唯一の決定要因ではありません。
Q2：ユーザーは監査レポートやオープンソースの状況などをどのようにレビューすべきですか？
BlockSecセキュリティチーム： 監査済みのプロジェクトの場合、プロジェクトチームは通常、公式チャネルを通じて監査レポートを公開しています。これらの監査レポートは、プロジェクト側のドキュメント、Githubコードリポジトリ、その他のチャネルで見つけることができます。さらに、監査レポートの真正性を確認する必要があります。これには、監査レポートのデジタル署名を確認したり、監査会社に二次確認のために連絡したりすることが含まれます。
では、投資家はこれらの監査レポートを入手したら、どのように読むべきでしょうか？
まず、監査レポートがBlockSec、OpenZeppelin、Trail of Bitsなどの主要な監査会社のような、評判の高いセキュリティ会社によって監査されているかどうかを確認します。
次に、監査レポートに記載されている問題が修正されているかどうかを確認し、修正されていない場合はプロジェクトの正当性を評価します。監査基準は会社によって異なるため、有効な脆弱性と無効な脆弱性を区別します。有効な発見を優先し、独自のセキュリティ専門家を招いて独立したレビューを検討してください。
第三に、監査レポートのタイミングが最新のプロジェクトアップデートと一致していることを確認します。プロジェクトはコスト制約のため、一部のみを監査することが多いため、監査が現在のすべてのオンラインコードを網羅しているかを確認します。コアプロトコルコードが監査に含まれていたかどうかに焦点を当てます。
第四に、監査レポートのタイミングが最新のプロジェクトアップデートと一致していることを確認します。プロジェクトはコスト制約のため、一部のみを監査することが多いため、監査が現在のすべてのオンラインコードを網羅しているかを確認します。コアプロトコルコードが監査に含まれていたかどうかに焦点を当てます。
第五に、プロジェクトのオンラインコードがオープンソースであり、監査レポートと一致していることを確認します。通常、監査はデプロイされたバージョンではなく、Githubコードに対して行われます。デプロイされたコードがオープンソースでない場合、または監査されたコードと大きく異なる場合、この差異には細心の注意が必要です。
要約すると、監査レポートを読むことは非常に専門的な作業であり、プロセス中にコンサルティング意見を提供するために、独立したサードパーティのセキュリティ専門家を導入することが推奨されます。
OKX Web3ウォレットセキュリティチーム： ユーザーは、OKLinkのような公式またはサードパーティのプラットフォームを介して、DeFiプロジェクトのスマートコントラクト監査レポートとオープンソースの状況にアクセスできます。これらのレビューの一般的な手順は次のとおりです。
まず、公式発表やウェブサイトを探します。ほとんどの信頼できるDeFiプロジェクトは、公式ウェブサイトに適切なドキュメント情報を表示します。「セキュリティ」、「監査」、「コントラクトアドレス」の下に、通常、監査レポートへのリンクとプロジェクト側がデプロイしたコントラクトアドレスのページがあります。プロジェクト側の公式ウェブサイトに加えて、通常、Medium、Twitterなどの公式ソーシャルメディアにも監査レポートとデプロイされたコントラクトアドレス情報を表示します。
次に、プロジェクト側の公式ウェブサイトを読んだ後、OKLinkブラウザを使用して、プロジェクト側から提供されたコントラクトアドレス情報をクエリし、「コントラクト」列でそのアドレスにデプロイされたコントラクトのオープンソースコード情報を表示できます。
第三に、プロジェクト側の監査レポートとデプロイされたコントラクトのオープンソースコード情報を入手した後、プロジェクト側の監査レポートを読み始めることができます。監査レポートを読む際には、以下の点に注意してください。
- 1）監査レポートの構造を理解し、監査レポートの内容全体を把握します。監査レポートは、概要、発見された問題、解決策と推奨事項、監査結果に大別されます。
- 2）概要を読む際は、監査レポートの範囲と目的、監査対象となったファイルとそのコミットIDに注意を払う必要があります。これは、チェーン上でデプロイされたオープンソースコードと一致しているかどうかを確認するために必要です。
- 3）「発見された問題」、「解決策と推奨事項」、「監査結果」を確認する際は、プロジェクトチームが推奨事項に従って脆弱性に対処し、すべての問題が解決されたことを確認するためにフォローアップ監査を実施したことを確認してください。
- 4）複数のレポートを比較します。複数の監査を受けているプロジェクトについては、レポートを比較してプロジェクトのセキュリティ強化を追跡します。
Q3：DeFiプロジェクトのセキュリティ評価において、ハッキング履歴とバグバウンティプログラムの重要性は何ですか？
OKX Web3ウォレットセキュリティチーム： ハッキング履歴とバグバウンティプログラムは、DeFiプロジェクトのセキュリティ評価に一定の参照価値を提供します。これは主に以下の側面で反映されます。
まず、ハッカー攻撃の履歴
- 1）過去の脆弱性を明らかにする：攻撃の履歴は、プロジェクトが過去に抱えていた特定のセキュリティ脆弱性を示すことができます。これにより、ユーザーはどのセキュリティ問題が悪用されたのか、これらの問題が徹底的に解決されたのかどうかを理解できます。
- 2）リスク管理能力を評価する：プロジェクトが過去のセキュリティインシデントにどのように対応するかは、リスク管理と危機処理の能力を反映します。前向きに対応し、脆弱性をタイムリーに修正し、影響を受けたユーザーに補償するプロジェクトは、一般的に、より信頼できる成熟した投資選択肢と見なされます。
- 3）プロジェクトの評判：頻繁なセキュリティ問題は、プロジェクトに対するユーザーの信頼を低下させる可能性があります。しかし、プロジェクトが間違いから学び、セキュリティ対策を強化する能力を示すことができれば、長期的な評判を築くこともできます。
次に、バグバウンティプログラム
DeFiおよびその他のソフトウェアプロジェクトにおけるバグバウンティプログラムの実施は、セキュリティを改善し、潜在的な脆弱性を発見するための重要な戦略です。これらのプログラムは、プロジェクトのセキュリティ評価に複数の参照価値をもたらします。
- 1）外部監査を強化する：バグバウンティプログラムは、世界中のセキュリティ研究者にプロジェクトのセキュリティ監査への参加を奨励します。セキュリティテストのこの「クラウドソーシング」アプローチは、内部監査で見落とされる可能性のある問題を発見し、潜在的な脆弱性の発見と解決の可能性を高めることができます。
- 2）セキュリティ対策の有効性を検証する：バグバウンティプログラムを通じて、プロジェクトは実践においてセキュリティ対策の有効性をテストできます。プロジェクトのバグバウンティプログラムが長期間実行されていても、深刻な脆弱性がほとんど報告されていない場合、これはプロジェクトが比較的成熟していて安全である可能性を示す指標となる可能性があります。
- 3）継続的なセキュリティ改善：バグバウンティプログラムは、継続的な改善のためのメカニズムを提供します。新しい技術や攻撃方法が登場するにつれて、バグバウンティプログラムはプロジェクトチームがセキュリティ対策をタイムリーに更新および強化するのを助け、プロジェクトが最新のセキュリティ課題に対処できるようにします。
- 4）セキュリティ文化を確立する：プロジェクトにバグバウンティプログラムがあるかどうか、そのプログラムの真剣さと活動レベルは、セキュリティに対するプロジェクトチームの姿勢を反映できます。活発なバグバウンティプログラムは、堅実なセキュリティ文化を確立するというプロジェクトのコミットメントを示しています。
- 5）コミュニティと投資家の信頼を高める：バグバウンティプログラムの存在と有効性は、コミュニティと潜在的な投資家に対して、プロジェクトがセキュリティを重視していることを証明できます。これはユーザーの信頼を高めるだけでなく、投資家はセキュリティに対する責任感の高いプロジェクトを選ぶ傾向があるため、より多くの投資を引き付ける可能性もあります。
