a16z: スマートコントラクトのセキュリティを向上させる開発プロセスを構築する方法

Web3 プロジェクトでは、開発ライフサイクルのすべての段階でセキュリティのためのプロセスの追加を検討する必要があります。

Web3 プロジェクトで発生したハッキングの多くは、スマート コントラクトのセキュリティを強化することで防止できた可能性があります。

多くの場合、攻撃者は、設計から展開、メンテナンス、新しいコードのリリースに至るまで、ソフトウェア開発チェーン全体で欠陥を見つけて悪用します。標準的なスマート コントラクトの開発とリスク対応プロセスがあれば、それに応じてセキュリティ インシデントも減少すると考えています。

この投稿の目的は、Web3 ビルダー、開発者、セキュリティ チームがスマート コントラクト システムを設計、開発、保守する際に考慮する必要がある中核となるセキュリティ要素の概要を説明することです。次のフレームワークでは、脅威のモデリングから緊急対応の準備まで、ソフトウェア開発ライフサイクル全体にわたって実装する必要がある 8 つの主要なセキュリティ要素について説明します。

スマート コントラクトのセキュリティ保護を理解する前に、ソフトウェアの開発段階を理解する必要があります。ソフトウェア開発は次の 5 つのフェーズに分けることができます。

設計: 開発者は、重要なベンチマークや固定プロパティなど、システムに必要な機能と操作について説明します。

開発: 開発者はシステムのコードを作成します。

テストとレビュー: 開発者はテスト環境ですべてのモジュールを実行し、コードの精度と安定性を評価します。

導入: 開発者はシステムを実際の環境に配置します。

メンテナンス: 開発者はシステムを評価および変更して、意図したとおりに動作することを確認します。

基本的な開発サイクルの基盤が整ったので、各ステップでスマート コントラクトのセキュリティに影響を与える考慮事項を掘り下げることができます。以下の図は、考慮すべき要素を関連する開発フェーズにマッピングしています。リンク内の一部の手順には、セキュリティに関する複数の考慮事項があることに注意してください。

上に示したように、ソフトウェア開発ライフ サイクルは必ずしも直線的な経路をたどるわけではありません。実際には、他のフェーズとの重複や拡張が発生する可能性があります。リリースごとに一部の手順を繰り返す必要がある場合があります。テストやセキュリティレビューなどの一部のタスクは、最初から最後まで実行する必要がある場合があります。

上で説明したソフトウェアのライフサイクルとそれに対応するセキュリティの考慮事項は、スマートコントラクトのセキュリティを促進するための有用な基礎情報を提供しますが、これらのプラクティスを理解し、適用し、共有できるようにするために、以下でさらに詳細に検討します。 シンプルで、キーを具体的に分析します。質問: 何を、なぜ、どのように。

設計段階でのスマート コントラクトのセキュリティに関する考慮事項 脅威モデリングとセキュリティ設計を検討する

内容: 開発ライフサイクルの最初から、システムに対する潜在的な脅威を特定し、優先順位を付けるための具体的な計画を実装することが重要です。スマート コントラクトの開発者は、すべての脅威のテスト、監査、検査の監視にすべてのセキュリティ制御が含まれることを特定する必要があります。予想される高度さと攻撃手段を含むすべてのセキュリティの前提条件は、設計段階で明確に定義され、明確に表現される必要があります。

理由: 開発者はスマート コントラクトまたはプロトコルの使用目的のみに焦点を当てる傾向がありますが、この単一の焦点により、攻撃者に悪用される可能性のある盲点が残る可能性があります。

方法: 既知の脅威モデリングの実践に従います。開発チームが社内にセキュリティの専門知識を持たない場合は、設計段階の早い段階でセキュリティ コンサルタントと協力する必要があります。システムを設計するときは「攻撃者」の考え方を採用し、あらゆる個人、ハードウェア、サービスが攻撃される可能性があることを想定します。

開発段階でのセキュリティに関する考慮事項 管理とアクセス制御を考慮する

内容: アクセス制御を実装し、特権アカウントの権限を制限し、スマート コントラクトは管理タスク (コントラクトのアップグレードや特別なパラメーターの設定など) を実行する特別な機能を呼び出します。 「最小権限の原則」に従ってください。各参加者は、必要な最小限のアクセス権限のみを持つ必要があります。

理由: アップグレードとガバナンスのプロセスを通じてプロトコルを維持することで、開発者は新機能の追加、セキュリティ問題のパッチ適用、状況の変化に合わせた最適化によってプロトコルを改善できます。アップグレード機能が適切に制御されていない場合、これは重大なセキュリティ侵害となる可能性があります。

方法: プロトコルへの変更を透過的にするマルチシグネチャウォレットまたは DAO コントラクトを構築し、タイムロック (意図的に遅らせた制定とキャンセル可能性) だけでなく、徹底的なレビュープロセスを経て、それらが正しく適切に検証できることを確認する必要があります。ガバナンス攻撃。特権キーが安全に保管され、セルフホスト型ウォレットまたは安全なエスクロー サービスにアクセスできるようにしてください。

再利用可能で実証済みのテンプレートの統合を検討する

内容: 既存のスマート コントラクト標準 (OpenZeppelin Contracts など) を可能な限り活用し、既存のプロトコルとの統合が必要となる可能性があるセキュリティ上の問題を評価します。

理由: 実戦でテストされ、コミュニティで精査された既存の標準を使用することは、セキュリティ リスクの軽減に大いに役立ちます。プロトコル統合のリスクを評価すると、セキュリティ チェックを実行して、Oracle 操作などの外部コンポーネントに対する攻撃を防ぐことができます。

方法: セキュリティ監査を受けた信頼できるコントラクト ライブラリとインターフェイスをインポートする 結局のところ、Crypto と Web3 の焦点はオープン ソース、再利用、および構成可能性です。コントラクトの依存関係とそのバージョンを必ずコードベースに文書化し、コードのリソース フットプリントを最小限に抑えてください。たとえば、すべてではなく大規模なプロジェクトの特定のサブモジュールをインポートします。攻撃を監視できるように危険性を把握し、公式インターフェイスを使用して外部を呼び出します。プロトコルを確認し、潜在的な統合リスクを必ず考慮し、再利用された契約の更新とセキュリティ情報の開示を監視してください。

テストおよびレビュー段階でのセキュリティに関する考慮事項 テストとプロジェクトの文書化を検討する

内容: 明確で包括的なコード ドキュメントを作成し、迅速で包括的で実行が簡単なテスト スイートをセットアップします。可能であれば、テストネットまたはメインネット シミュレーションでセットアップされたテスト環境で、より詳細な実験を実施します。

理由: 予想される動作の前提条件を記述することは、脅威モデルのリスクに確実に対処できるだけでなく、ユーザーや外部監査人が開発チームの意図を理解するのにも役立ちます。コードのテスト スイートを作成すると、仮説を証明または反証するのに役立ち、脅威モデルについてより深く考えることが促進されます。このテストスイートには、単体テストと統合テストだけでなく、極端な市場シナリオの下でプロジェクトのトークンエコノミクスをチェックする機械設計テストも含める必要があります。

方法: Hardhat、Mythril、Slither、Truffle などの既知のテスト フレームワークとセキュリティ チェック アプリケーションを使用してテストし、ファジング、プロパティ チェック、さらには形式検証 (形式検証) などのさまざまなテスト手法を提供し、テストを徹底的に文書化します。 NatSpec 注釈を使用して、予期される副作用、パラメーター、戻り値を指定するコード。ドキュメント生成ツールと高レベルの設計ノートを使用して、ライブ ドキュメントを生成します。

内部レビューとセキュリティ監査を検討する

内容: 時間をかけて内部および外部のコード監査を通じてバグを発見します。

理由: 機能開発からセキュリティ問題に移行すると、開発者は潜在的なセキュリティ問題を発見する時間が得られます。外部監査は、開発チームが持っていない外部の視点や専門知識をもたらすことができるため、この点で特に役立ちます。

方法: プロジェクト開発の適切な時点で、機能の凍結をスケジュールして、内部レビューとそれに続く外部監査の時間を確保します。これらのアクションは、ライブ デプロイメントやアップグレードの前に実行する必要があります。ConsenSys、Nascent、OpenZeppelin、および Trail of Bits のガイドを確認してください。このガイドでは、監査の準備をしている人向けに、タイミングを含む考慮事項のチェックリストが開発者に提供されています。また、特にソフトウェアをアップグレードする場合は、展開トランザクションを確認して、監査済みのコード バージョンを使用し、適切なパラメータが設定されていることを確認してください。

導入およびメンテナンス段階でのセキュリティに関する考慮事項 ホワイト ハット コミュニティへの参加の動機付けを検討する

内容: オープン ソース コードベースのセキュリティ向上へのコミュニティの参加を奨励するプログラムを作成します。 1 つのアプローチは、バグ報奨金を設定することです。もう 1 つのアプローチは、ボットを監視および検出するためのプロトコルの開発をコミュニティに奨励することです。

理由: 開発チームは、より幅広い知識と経験から恩恵を受けることができます (繰り返しますが、オープンソースは暗号化にも役立ちます)。特に、このようなプログラムは、プロジェクトに対する開発者の熱意を刺激するのに役立ち、本質的にコミュニティとホワイトハットハッカーをエバンジェリストに変えることができます。また、ハッカーに防御者になる方法を提供することで、攻撃者を目指す者を防御者に変えるのにも役立ちます。

方法: バグ報奨金プラットフォーム (Code4rena、HackenProof、Immunefi、Secureum など) を使用して、重大度に応じた報奨金を報奨金システムに提供し、熟練したハッカーに脆弱性を開示するよう奨励します。 (開示: この文書の共著者の一部は、分散型の高品質セキュリティ監視ボットを作成するためのトークン インセンティブ構造を提供するネットワークである Forta で働いています。) 開発チームは、プロトコル コミュニティに従来の Web3 ネイティブのアプローチを活用するよう奨励できます。バグの検索を奨励し、参加者がセキュリティ強化に対する潜在的な報酬を獲得できるようにすることで、全員にとってwin-winの関係を生み出します。

リアルタイム監視を検討する

内容: スマート コントラクトと、オラクルやクロスチェーン ブリッジなどの主要な運用コンポーネントを監視するシステムを実装し、既知の脅威モデルに基づいて不審なアクティビティを開発チームやコミュニティに報告します。

理由: 問題を早期に検出すると、チームは脆弱性やバグに迅速に対応でき、被害を防止または軽減できる可能性があります。これは考えるのは簡単なアイデアのように思えますが、計画を立てる際には見落とされる可能性があります。

方法: 監視プラットフォームまたは分散ノードを使用して、スマート コントラクト イベントをリアルタイムで監視するロボットを実行します。必要に応じて、ダッシュボードを構築し、開発チームやより広範なコミュニティに向けたアラート通知を作成します。

インシデント対応プロセスを検討する

内容: セキュリティ上の問題が発生したときに即座に対応できるツールとプロセスを活用します。

理由: 導入前に最善の保護を実施しても、スマート コントラクトや、オラクルやクロスチェーン ブリッジなどの主要コンポーネントに一時的な問題が発生する可能性があります。専任の人員、明確なプロセス、自動化を導入することで、インシデントを迅速に調査し、できるだけ早く解決できるようになります。

方法: インシデントや緊急事態への対応方法を計画し、その対応を可能な限り自動化することで、最悪の事態に備えます。これには、分散型セキュリティ メーリング リスト、コード リポジトリの指示、またはスマート コントラクト レジストリを通じて、セキュリティ上の懸念事項に関連する人々に公に連絡できる有能な個人に、調査と対応の責任を割り当てることが含まれます。合意の脅威モデルに基づいて、シナリオの演習と緊急の行動に対する予想される応答時間を含むプロセスを開発します。インシデント対応に自動化を統合することを検討してください。たとえば、ツールが Forta ロボットからイベントを受信し、それに基づいて動作することができます。

セキュリティに関する考慮事項は、単なる後付けではなく、開発を成功させるために不可欠な部分である必要があります。

上記のフレームワークは、開発プロセス全体を通じてセキュリティを向上させるために、Web3 プロトコルとアプリケーションを構築するチームにいくつかの簡単なガイドラインを提供しますが、スマート コントラクトのセキュリティのすべての側面を網羅的に説明するには、短い概要だけでは十分ではありません。社内にセキュリティの専門知識が不足しているチームは、チームが上記の一般的なガイダンスを特定の状況に適用するのを支援できる、資格のある Web3 セキュリティの専門家に連絡する必要があります。しかし最も重要なことは、セキュリティとは単にチェックリストにチェックを入れて複雑な問題を管理するだけではなく、常に終わりのない継続的な一連の実践であることを忘れないでください。私たちはまだこれらのプラクティスを確立する初期段階にあるため、今がすべての開発者向けのセキュリティ プラクティスを協力して作成し、共有するときです。