a16z：Web3プロジェクトのスマートコントラクトセキュリティガイド
この8点を守ることで、ハッカー攻撃を最大限に防ぐことができます。出典：a16z
編纂：Katie 辜、星球日报
通常、ハッカーはソフトウェア開発の全プロセスチェーン（設計からデプロイ、さらにメンテナンスまで）の欠陥を発見し、利用することでブロックチェーンプロジェクトのセキュリティバリアを破ります。関連する経験を事前に知ることができれば、安全事故は大幅に減少すると信じています。
この記事では、Web3 開発者とセキュリティチームがスマートコントラクトを設計、開発、維持する際に考慮すべきセキュリティ要素を概説し、脅威モデリングから緊急対応準備までの全周期をカバーします。
安全なソフトウェアを開発するには、以下の5つの段階が含まれます：
設計：開発者はシステムに必要な機能と操作を説明し、重要なベンチマークと固定属性を含めます；
開発：開発者はシステムコードを記述します；
テストとレビュー：開発者はすべてのモジュールをテスト環境に集め、それらの正確性、スケール、その他の要因を評価します；
デプロイ：開発者はシステムを本番環境に投入します；
メンテナンス：開発者はシステムを評価し、修正して、期待される機能を実行することを保証します。
下の図は、考慮すべきセキュリティ要素を上記の段階に対応させています。
注意すべきは、ソフトウェア開発のライフサイクルが常に線形の道筋に従うわけではないということです：各カテゴリーは重なり合ったり、他の段階に拡張されたりする可能性があります。各バージョンに対して、ステップは繰り返されることがあります。一部のセキュリティタスク（テストやセキュリティレビューなど）は、徹底的に実施する必要があります。
上記で説明したソフトウェアライフサイクルのステップとそれに対応するセキュリティ考慮は、スマートコントラクトの安全性を促進するための基盤を提供します。以下では、3つの問題に基づいて、より詳細な研究を行います。
1. 設計段階のスマートコントラクトセキュリティ考慮------脅威モデリングとセキュリティ設計を考慮する
内容：プロジェクト開発ライフサイクルの初期段階からシステムの潜在的な脅威を明確に特定し、その優先順位を決定することが重要です。スマートコントラクト開発者は、開発中に実装すべきすべてのセキュリティコントロールと、テスト、監査、監視で確認すべき脅威を特定する必要があります。攻撃者が予想する複雑さや経済的手段を含むすべてのセキュリティ仮定は、設計段階で明確に定義し、説明する必要があります。
原因：開発者にとって、スマートコントラクトやプロトコルの期待される用途にのみ焦点を当てることは非常に魅力的ですが、この唯一の焦点は「盲点」を生む可能性があり、攻撃者に利用されることがあります。
方法：既知の脅威モデリングの実践に従います。もし開発チームに内部のセキュリティ専門家がいない場合は、設計段階の早い段階でセキュリティコンサルタントと接触するべきです。システムを設計する際には「攻撃者」の視点を持ち、個人、機械、またはサービスが攻撃される可能性があると仮定します。
2. 開発段階のセキュリティ考慮------管理考慮とアクセス制御
内容：アクセス制御を実施し、特権アカウントやスマートコントラクト呼び出しの管理タスク（契約のアップグレードや特別なパラメータの設定など）を実行する特別な機能へのアクセスを制限します。「最小特権の原則」に従う------各参加者は必要な最小限のアクセス権のみを持つべきです。
原因：アップグレードとガバナンスプロセスを通じてプロトコルを維持することで、開発者は新機能を追加したり、セキュリティ問題を修正したり、変化する条件に対処したりすることができます。アップグレード能力が適切に制御されていない場合、重大なセキュリティ脆弱性を構成する可能性があります。
方法：コミュニティの変更を透明に管理するために、マルチシグウォレットまたはDAO契約を設立します。変更は徹底的なレビュー過程を経るべきであり、ガバナンス攻撃の際にその正当性を検証し、ロールバックできるように、タイムロックを設定します（意図的に規定の制定を遅らせ、キャンセルの能力を持つ）。特権キーを安全に保存し、アクセスできるように、自主管理のウォレットまたは安全な保管サービスを確保します。
3. 再利用可能で実戦テスト済みのテンプレートと統合を考慮する
内容：可能な限り既存のスマートコントラクト標準（OpenZeppelin契約など）を活用し、既存のプロトコルとの統合に必要なセキュリティ仮定を評価します。
原因：既存の実戦検証済み、コミュニティ監査済みの標準と実装を使用することで、セキュリティリスクを大幅に低減できます。プロトコル統合のリスクを評価することで、外部コンポーネント（オラクルの操作など）への攻撃を防ぐためのセキュリティチェックを開発するのに役立ちます。
方法：セキュリティ監査済みの信頼できる契約ライブラリとインターフェースを導入します。Web3の重点はオープンソースの使用、再利用性、可組み合わせ性です。コードベースに契約の依存関係とそのバージョンを記録し、コードの占有を可能な限り減らします。たとえば、大規模プロジェクトの特定のサブモジュールを導入し、すべてをインポートしないようにします。リスクエクスポージャーを理解し、サプライチェーン攻撃を監視します。公式インターフェースを使用して外部プロトコルを呼び出し、潜在的な統合リスクを考慮します。再利用される契約の更新とセキュリティ開示を監視します。
4. テストとレビュー段階のセキュリティ考慮------テストと文書を考慮する
内容：明確で包括的なコード文書を作成し、迅速で徹底的、かつ実行しやすいテストスイートを構築します。可能な場合は、テストネットまたはメインネットを模擬したテスト環境を構築し、より深い実験を行います。
原因：コードベースの期待される動作に関する仮定を書くことは、脅威モデル内のリスクが解決され、ユーザーや外部監査人が開発チームの意図を理解するのに役立ちます。コードに対してテストスイートを作成することは、開発仮定を証明（または反証）し、脅威モデルについてのより深い考察を促します。このテストスイートには、極端な市場シナリオでプロジェクトトークン経済のメカニズム設計テストをチェックするテスト、ユニットテスト、統合テストが含まれるべきです。
方法：Hardhat、Mythril、Slither、Truffleなどの既知のテストフレームワークとセキュリティチェッカーを実施し、異なるテスト技術（ファジング、プロパティチェック、さらには形式的検証など）を提供します。NatSpecコメントを広範囲に使用してコードを記録し、期待される副作用、パラメータ、戻り値を指定します。文書生成ツールや高度な設計仕様を使用してリアルタイム文書を生成します。
5. 内部レビューとセキュリティ監査を考慮する
内容：内部および外部のコードレビューを通じて脆弱性を発見するために時間をかけます。
原因：機能開発からセキュリティ問題への焦点を移すことで、開発者は潜在的なファジーな問題を発見する時間を得ます。外部監査は特にこの点で重要であり、開発チームが持たない外部の視点と専門知識をもたらすことができます。
方法：プロジェクト開発の適切なノードで特定の機能を凍結し、内部レビューを行うための時間を確保し、その後外部監査を実施します。これは、実際のデプロイやアップグレードの前に行うべきです。
ConsenSys、Nassent、OpenZeppelin、Trail of Bitsのガイドを確認してください。これらのガイドは、開発者に考慮事項のリストを提供し、監査の準備をしている人の参考になります。また、デプロイメントトランザクションを確認し、監査済みのコードバージョンを使用し、特にソフトウェアをアップグレードする際に適切なパラメータを持っていることを確認してください。
6. デプロイとメンテナンス段階のセキュリティ考慮------ホワイトハットコミュニティの参加を促す
内容：コミュニティがオープンソースコードベースのセキュリティ改善に参加することを奨励するプログラムを作成します。一つの方法は、バグ報奨金を創設することです。もう一つの方法は、コミュニティにプロトコル監視検出ロボットを開発することを奨励することです。
原因：開発チームは広範な知識と経験から利益を得ることができます（これが暗号分野におけるオープンソースの役割です）。このようなプログラムは、プロジェクトへの熱意を喚起し、本質的にコミュニティとホワイトハットハッカーを布教者に変えるのに役立ちます。ハッカーに防御者になる道を提供することで、潜在的な攻撃者をセキュリティ資産に変える手助けもできます。
方法：Code4rena、HackenProof、mmunef、Secureumなどのバグ報奨金プラットフォームを使用して、熟練したハッカーが安全に脆弱性を開示することを奨励します。
注：文中の一部の著者はForta社で働いており、同社は分散型の高品質なセキュリティ監視ロボットを作成するためのトークン化されたインセンティブ構造を提供しています。開発チームは、プロトコルコミュニティが従来の方法とWeb3ネイティブの2つの方法を利用してバグ報奨金を奨励し、セキュリティを強化することで参加者が潜在的に利益を得ることを促すことができます。
7. リアルタイム監視のセキュリティ考慮
内容：スマートコントラクトや重要な操作コンポーネント（オラクルやクロスチェーンブリッジなど）を監視するシステムを実装し、既知の脅威モデルに基づいて開発チームやコミュニティに疑わしい活動を報告します。
原因：問題の早期検出により、チームは脆弱性に迅速に対応し、潜在的に損失を防ぐことができます。
方法：監視プラットフォームまたは分散ノードを使用してロボットを実行し、スマートコントラクトイベントをリアルタイムで監視します。必要に応じて、開発チームや広範なコミュニティにデータダッシュボードや警告通知を挿入します。
8. 予期しない事態と緊急対応操作のセキュリティ考慮
内容：セキュリティ問題が発生した場合に即座に対応できるツールとプロセスを使用します。
原因：最良のデプロイ前の保障策があっても、スマートコントラクトや重要なコンポーネント（オラクルやクロスチェーンブリッジなど）にはリアルタイムの問題が発生する可能性があります。専任のスタッフ、明確なプロセス、適切な自動化装置を備え、事件を迅速に調査し、できるだけ早く解決できるようにします。
方法：最悪の事態に備え、事件や緊急事態にどのように対応するかを計画し、可能な限り自動化された対応能力を持つようにします。調査と対応の責任を割り当て、これらの担当者は分散型のセキュリティメールリスト、コードリポジトリ内の指示、またはスマートコントラクトレジストリを通じてセキュリティ問題について公開連絡を取ることができます。プロトコルの脅威モデルに基づいて、一連のプロセスを開発し、シナリオ演習や緊急行動に必要な期待される応答時間を含めることができます。緊急事態対応に自動化を統合することも考慮できます。
セキュリティ考慮は成功した開発の構成要素であるべきであり、単なる事後の考慮や補足ではありません。このフレームワークは、Web3プロトコルやアプリケーションを構築するための迅速なガイドを共有し、開発プロセス全体でのセキュリティを促進しますが、スマートコントラクトのセキュリティを包括的に議論するための短い概要は存在しません。内部のセキュリティ専門知識が不足しているチームは、資格のあるWeb3セキュリティ専門家に連絡し、特定の状況に適用するための指導と支援を受けるべきです。
セキュリティは単純な問題ではないことを忘れないでください。セキュリティは永遠に続く一連のベストプラクティスです。私たちはまだこれらの実践を確立する初期段階にあり、今こそすべての開発者が協力してそれらを作成し、共有する時です。
