Back to Blog

DeFiリスク軽減ガイド 02:DeFiユーザーができるリスク評価の方法

July 5, 2024
10 min read

OKX Web3とBlockSecが共同キュレーションした「セキュリティ特集号05」から抜粋された本連載記事は、DeFiユーザーとDeFiプロジェクトチームが直面するセキュリティ上の懸念に対処します。

Q1:DeFiプロジェクトのセキュリティとリスクプロファイルを予備的に評価するために、どのような基準や指標が用いられますか?

BlockSecセキュリティチーム: DeFiプロジェクトに投資する前に、プロジェクトの包括的なセキュリティ評価を実施することが不可欠です。これは、特に多額の資金を投入する参加者にとって重要であり、セキュリティに関する必要なデューデリジェンスを行うことで、資金の安全性を最大限に確保できます。

まず、プロジェクトのコードセキュリティに関する包括的な評価を実施することをお勧めします。これには、プロジェクトが良好なセキュリティ評判を持つ監査会社によって監査されているか、複数の監査会社が関与しているか、最新のコードが監査されているかなどが含まれます。一般的に、オンラインで稼働しているコードが、評判の良い複数のセキュリティ会社によって監査されている場合、セキュリティ攻撃のリスクは大幅に軽減されます。

次に、プロジェクト側がリアルタイムのセキュリティ監視システムを導入しているかどうかを確認することが重要です。セキュリティ監査は静的なセキュリティを確保するものであり、プロジェクトの稼働後に発生する動的なセキュリティ問題には対応できません。例えば、プロジェクト側がプロジェクトの主要な運用パラメータを不適切に調整したり、新しいプールを追加したりした場合などです。プロジェクト側が何らかのリアルタイムセキュリティ監視システムを採用している場合、その運用セキュリティレベルは、そのようなソリューションを採用していないプロトコルよりも高くなります。

第三に、しばしば見落とされがちな、プロジェクトの自動緊急対応能力にアクセスします。多くのセキュリティインシデントにおいて、プロジェクトは重要な機能に対する自動サーキットブレーカーを欠いていることが観察されています。緊急事態の手動対応は、非効率的で、時には効果がないことが証明されています。

第四に、プロジェクトが外部依存にどれだけ依存しており、それらがどれほど堅牢であるかを精査します。DeFiプロジェクトは、価格設定や流動性などのサードパーティデータに依存することがよくあります。したがって、外部依存の数、外部依存プロジェクトのセキュリティ、および外部依存からの異常データの監視とリアルタイム処理があるかどうかという観点から、プロジェクトのセキュリティを評価する必要があります。一般的に、トップティアのプロジェクトに依存し、フォールトトレランスと外部プロジェクトからの異常データのリアルタイム処理を備えたプロジェクトは、より安全になります。

第五に、プロジェクト側が比較的良好なコミュニティガバナンス構造を有しているかどうかが重要です。これには、プロジェクト側が主要なイベントに関するコミュニティ投票メカニズムを有しているか、機密性の高い操作がマルチシグネチャで完了しているか、マルチシグネチャウォレットに中立的なコミュニティ参加が導入されているか、コミュニティセキュリティ委員会があるかなどが含まれます。これらのガバナンス構造は、プロジェクトの透明性を向上させ、ユーザーの資金がプロジェクトでラグプルされる可能性を減らすことができます。

最後に、プロジェクト側の履歴も非常に重要です。プロジェクトチームとコアメンバーのバックグラウンドチェックを行う必要があります。プロジェクト側のコアメンバーが、過去のプロジェクトで複数の攻撃やラグプルの履歴を持っている場合、そのようなプロジェクトのセキュリティリスクは相対的に高くなります。

要約すると、DeFiプロジェクトに参加する前に、ユーザー、特に多額の資金を投入するユーザーは、プロジェクト稼働前のコードセキュリティ監査から、プロジェクト稼働後のリアルタイムセキュリティ監視と自動対応能力の構築まで、プロジェクト側のセキュリティ投資と安全性、外部依存、ガバナンス構造、プロジェクト側の履歴の観点からデューデリジェンスを行い、プロジェクトに投資した資金の安全性を確保するために、自身で調査を行うべきです。

OKX Web3ウォレットセキュリティチーム: DeFiプロジェクトにおける絶対的なセキュリティは保証できませんが、ユーザーはこれらの主要な次元を考慮することで、セキュリティとリスクプロファイルを評価できます。

  1. プロジェクトの技術セキュリティ:

    • 1)プロジェクトが複数の評判が良く経験豊富な監査会社によって監査されているか確認します。
    • 2)監査レポートで報告された問題の数と深刻度をレビューし、すべてが対処されていることを確認します。
    • 3)デプロイされたコードが監査されたバージョンと一致していることを確認します。
  2. オープンソースコード:

    • 1)プロジェクトのコードがオープンソースであり、コミュニティやセキュリティ専門家がレビューし、セキュリティ上の問題を発見できるかどうかを判断します。
    • 2)開発チームのバックグラウンド、ブロックチェーンとセキュリティの経験、チームに関する透明性と公開情報のレベルを調査します。
    • 3)バグバウンティ:脆弱性を報告するようセキュリティ研究者を奨励するためのバグバウンティプログラムの存在を探します。
  3. 財務および経済的セキュリティ:

    • 1)ロックされた資金:スマートコントラクトにロックされている資金の量を確認します。金額が高いほど、プロジェクトへの信頼度が高いことを示唆する可能性があります。
    • 2)取引量と流動性:プロジェクトの取引量と流動性を評価します。流動性が低いと、価格操作のリスクが高まる可能性があります。
    • 3)トークン経済モデル:トークン配布、インセンティブメカニズム、インフレモデルを含むトークノミクスを評価し、過度に集中したトークン保有がないかなどを確認します。
  4. 運用および管理セキュリティ:

    • 1)ガバナンスメカニズム:プロジェクトのガバナンス構造、分散型ガバナンスがあるかどうか、コミュニティが重要な決定に投票できるかどうかを理解します。ガバナンストークンの配布と投票権の集中を分析します。
    • 2)リスク管理措置:プロジェクトが潜在的なセキュリティ脅威や経済的攻撃に対処するためのリスク管理措置と緊急計画を有しているかどうかを判断します。また、プロジェクトの透明性とコミュニティコミュニケーション、例えば定期的な進捗レポート、セキュリティアップデート、コミュニティとの積極的な関与なども考慮します。
  5. 市場およびコミュニティの認識:

    • 1)コミュニティエンゲージメント:プロジェクトのコミュニティ活動とユーザーベースを評価します。活発なコミュニティは、プロジェクトへの広範な支持を示唆することがよくあります。
    • 2)メディアおよびソーシャルメディアのセンチメント:メディアおよびソーシャルメディアにおけるプロジェクトの評価を分析し、ユーザーや業界専門家の視点を理解します。
    • 3)パートナーシップおよび投資家:プロジェクトが著名なパートナーや投資家から支援を受けているかどうかを確認します。これはプロジェクトに信頼性を与える可能性がありますが、セキュリティの唯一の決定要因であってはなりません。

Q2:ユーザーは監査レポートやオープンソースの状況などをどのようにレビューすべきですか?

BlockSecセキュリティチーム: 監査済みのプロジェクトの場合、プロジェクトチームは通常、公式チャネルを通じて監査レポートを公開します。これらの監査レポートは、通常、プロジェクト側のドキュメント、Githubコードリポジトリ、その他のチャネルにあります。さらに、監査レポートの真正性を確認する必要があります。これには、監査レポートのデジタル署名を確認し、監査会社に二次確認を求めることが含まれます。

では、投資家はこれらの監査レポートを入手したら、どのように読めばよいのでしょうか?

まず、監査レポートがBlockSec、OpenZeppelin、Trail of Bitsなどの主要な監査会社のような、評判の高いセキュリティ会社によって監査されているかどうかを確認します。

次に、監査レポートで言及されている問題が修正されているかどうかを確認し、修正されていない場合はプロジェクトの正当性を評価します。監査基準は会社によって異なるため、有効な脆弱性と無効な脆弱性を区別します。有効な発見を優先し、独自のセキュリティ専門家による独立したレビューを検討してください。

第三に、監査レポートのタイミングが最近のプロジェクトアップデートと一致していることを確認します。プロジェクトはコスト制限のために一部のみを監査することが多いため、監査が現在のすべてのオンラインコードを網羅していることを確認します。コアプロトコルコードが監査に含まれていたかどうかに焦点を当てます。

第四に、監査レポートのタイミングが最近のプロジェクトアップデートと一致していることを確認します。プロジェクトはコスト制限のために一部のみを監査することが多いため、監査が現在のすべてのオンラインコードを網羅していることを確認します。コアプロトコルコードが監査に含まれていたかどうかに焦点を当てます。

第五に、プロジェクトのオンラインコードがオープンソースであり、監査レポートと一致していることを確認します。通常、監査はデプロイされたバージョンではなく、Githubコードに対して行われます。デプロイされたコードがオープンソースでない場合、または監査されたコードと大きく異なる場合、この不一致は注意が必要です。

要約すると、監査レポートを読むことは非常に専門的な作業であり、プロセス中に独立した第三者のセキュリティ専門家を導入してコンサルティング意見を提供することを推奨します。

OKX Web3ウォレットセキュリティチーム: ユーザーは、OKLinkなどの公式またはサードパーティプラットフォームを通じて、DeFiプロジェクトのスマートコントラクト監査レポートやオープンソースの状況にアクセスできます。これらのレビューのための一般的な手順は次のとおりです。

まず、公式発表またはウェブサイトを探します。ほとんどの信頼できるDeFiプロジェクトは、公式ウェブサイトにそれに関連するドキュメント情報を表示します。「セキュリティ」、「監査」、「コントラクトアドレス」の下に、監査レポートやプロジェクト側がデプロイしたコントラクトアドレスへのページリンクが通常あります。プロジェクト側の公式ウェブサイトに加えて、通常、Medium、Twitterなどの公式ソーシャルメディアにも監査レポートとデプロイされたコントラクトアドレスの情報が表示されます。

次に、プロジェクト側の公式ウェブサイトを読んだ後、OKLinkブラウザを使用してプロジェクト側が提供したコントラクトアドレス情報を照会し、「コントラクト」列でそのアドレスにデプロイされたコントラクトのオープンソースコード情報を表示できます。

第三に、プロジェクト側の監査レポートとデプロイされたコントラクトのオープンソースコード情報を入手した後、プロジェクト側の監査レポートの読解を開始できます。監査レポートを読む際には、次の点に注意してください。

  • 1)監査レポートの構造を理解し、監査レポートの内容全体を把握します。監査レポートは、概ね「はじめに」、「発見された問題」、「解決策と推奨事項」、「監査結果」に分けられます。
  • 2)「はじめに」を読む際には、監査レポートの範囲と目的、つまり監査範囲に注意を払う必要があります。監査レポートには通常、監査されたファイルのGithubコミットIDがマークされており、監査レポートで監査されたファイルがチェーンにデプロイされたオープンソースコードと一致しているかどうかを比較する必要があります。
  • 3)「発見された問題」、「解決策と推奨事項」、「監査結果」をレビューする際には、プロジェクトチームが推奨事項に従って脆弱性に対処し、すべての問題が解決されたことを確認するためにフォローアップ監査を実施したことを確認します。
  • 4)複数のレポートを比較します。複数の監査を受けているプロジェクトについては、レポートを比較してプロジェクトのセキュリティ強化を追跡します。

Q3:DeFiプロジェクトのセキュリティ評価において、ハッキング履歴とバグバウンティプログラムの重要性は何ですか?

OKX Web3ウォレットセキュリティチーム: ハッキング履歴とバグバウンティプログラムは、DeFiプロジェクトのセキュリティ評価に一定の参照価値を提供し、主に以下の側面に反映されます。

まず、ハッカー攻撃の履歴

  • 1)過去の脆弱性を明らかにします:攻撃の履歴は、プロジェクトが過去に有していた特定のセキュリティ脆弱性を示すことができ、ユーザーはどのようなセキュリティ問題が悪用されたか、そしてこれらの問題が完全に解決されているかどうかを理解することができます。
  • 2)リスク管理能力を評価します:プロジェクトが過去のセキュリティインシデントにどのように対応するかは、リスク管理と危機対応の能力を反映します。前向きに対応し、脆弱性をタイムリーに修正し、影響を受けたユーザーに補償するプロジェクトは、一般的に、より信頼性が高く成熟した投資選択肢と見なされます。
  • 3)プロジェクトの評判:頻繁なセキュリティ問題はユーザーのプロジェクトへの信頼を低下させる可能性がありますが、プロジェクトが間違いから学び、セキュリティ対策を強化する能力を示すことができれば、長期的な評判を築くこともできます。

次に、バグバウンティプログラム

DeFiおよびその他のソフトウェアプロジェクトにおけるバグバウンティプログラムの実施は、セキュリティを向上させ、潜在的な脆弱性を発見するための重要な戦略です。これらのプログラムは、プロジェクトのセキュリティ評価に複数の側面で参照価値をもたらします。

  • 1)外部監査を強化します:バグバウンティプログラムは、世界中のセキュリティ研究者にプロジェクトのセキュリティ監査への参加を奨励します。セキュリティテストのこの「クラウドソーシング」アプローチは、内部監査が見逃す可能性のある問題を発見でき、それによって潜在的な脆弱性の発見と解決の機会を増やします。
  • 2)セキュリティ対策の有効性を検証します:バグバウンティプログラムを通じて、プロジェクトは実践でセキュリティ対策の有効性をテストできます。プロジェクトのバグバウンティプログラムが長期間稼働しており、重大な脆弱性がほとんど報告されていない場合、これはプロジェクトが比較的成熟しており安全である可能性の指標となる可能性があります。
  • 3)継続的なセキュリティ改善:バグバウンティプログラムは、継続的な改善のためのメカニズムを提供します。新しい技術や攻撃方法が登場するにつれて、バグバウンティプログラムはプロジェクトチームがセキュリティ対策をタイムリーに更新および強化するのを助け、プロジェクトが最新のセキュリティ課題に対処できるようにします。
  • 4)セキュリティ文化を確立します:プロジェクトがバグバウンティプログラムを有しているかどうか、およびそのプログラムの真剣さと活動レベルは、セキュリティに対するプロジェクトチームの姿勢を反映します。活発なバグバウンティプログラムは、堅実なセキュリティ文化を確立することへのプロジェクトのコミットメントを示します。
  • 5)コミュニティと投資家の信頼を高めます:バグバウンティプログラムの存在とその有効性は、プロジェクトのセキュリティへの注力をコミュニティや潜在的な投資家に証明できます。これはユーザーの信頼を高めるだけでなく、投資家はセキュリティ責任意識の高いプロジェクトを選択する傾向があるため、より多くの投資を引き付ける可能性があります。
Sign up for the latest updates
The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 13 – Apr 19, 2026

This BlockSec weekly security report covers four attack incidents detected between April 13 and April 19, 2026, across multiple chains such as Ethereum, Unichain, Arbitrum, and NEAR, with total estimated losses of approximately $310M. The highlighted incident is the $290M KelpDAO rsETH bridge exploit, where an attacker poisoned the RPC infrastructure of the sole LayerZero DVN to fabricate a cross-chain message, triggering a cascading WETH freeze across five chains and an Arbitrum Security Council forced state transition that raises questions about the actual trust boundaries of decentralized systems. Other incidents include a $242K MMR proof forgery on Hyperbridge, a $1.5M signed integer abuse on Dango, and an $18.4M circular swap path exploit on Rhea Finance's Burrowland protocol.

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Apr 6 – Apr 12, 2026

This BlockSec weekly security report covers four DeFi attack incidents detected between April 6 and April 12, 2026, across Linea, BNB Chain, Arbitrum, Optimism, Avalanche, and Base, with total estimated losses of approximately $928.6K. Notable incidents include a $517K approval-related exploit where a user mistakenly approved a permissionless SquidMulticall contract enabling arbitrary external calls, a $193K business logic flaw in the HB token's reward-settlement logic that allowed direct AMM reserve manipulation, a $165.6K exploit in Denaria's perpetual DEX caused by a rounding asymmetry compounded with an unsafe cast, and a $53K access control issue in XBITVault caused by an initialization-dependent check that failed open. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.