S1. アーキテクチャ、設計、脅威モデリング (Architecture, Design, and Threat Modeling)
S1.1 セキュアデザインパターン (Secure Design Patterns)
管理目標
スマートコントラクトがモジュール性、アップグレード可能性、関心の分離を考慮して設計され、安全な運用、アップグレード、保守が可能であることを確認します。コントラクトは、複雑なアップグレード、権限移譲、依存関係の不適切な管理に関するセキュリティリスクを最小限に抑えるように設計されるべきです。
セキュリティ検証要件
S1.1.A モジュール性とアップグレード可能性 (Modularity and Upgradability)
S1.1.A1
コントラクトがモジュラーコンポーネントやコントラクトに分割されていることを検証します。
✓
✓
S1.1.A2
アップグレードメカニズムが安全で制御されたアップデートを可能にするように設計されていることを確認します。
✓
✓
S1.1.A3
モジュール境界が明確に定義され、依存関係が管理されていることをチェックします。
✓
✓
S1.1.A4
コントラクトバージョン間でのストレージ変数の順序やタイプの変更が管理され、ストレージの衝突やデータの破損を避けていることを確認します。
✓
✓
S1.1.A5
重要な権限移譲が二段階のプロセスで実施され、安全で信頼性の高い権限変更を確保していることを検証します。
✓
S1.1.A6
仮想関数の呼び出し時に無効なコードが生成されないように、内部関数とパブリック関数をオーバーライドする際に、パラメータやリターン変数のデータ位置が正しく処理されていることを検証します。
✓
S1.1.B 関心の分離 (Separation of Concerns)
S1.1.B1
さまざまな機能が個別のコントラクトやモジュールに分離されていることを検証します。
✓
✓
S1.1.B2
各モジュールが単一の責任を持ち、他のモジュールへの依存関係が最小限であることを確認します。
✓
✓
S1.1.B3
セキュリティリスクにつながる可能性のある、モジュール間の依存関係についてチェックします。
✓
✓
S1.1.B4
さまざまなエッジケースを考慮して、権限移譲時にプロトコルが一貫性と信頼性の高い動作を維持することを確認します。
✓
S1.1.B5
プロキシコンストラクトが initializer
の代わりに onlyInitializing
修飾子を使用して、適切な初期化を確保していることを検証します。
✓
S1.1.B6
コントラクトバージョン間のストレージレイアウトが一貫しており、データの破損や予期しない動作を防いでいることを検証します。
✓
S1.1.B7
プロキシアップグレード時に実装間で不変変数が一貫していることを確認します。
✓
S1.1.B8
コントラクトのさまざまな部分にまたがる同じロジックの実装が一貫しており、エラーや脆弱性の発生を避けていることを検証します。
✓
S1.1.B9
適切なチェックで ETH と WETH が個別に処理されており、排他性に関する正しくない想定によるエラーを避けていることを確認します。
✓
S1.1.B10
プロキシのセットアップでコンストラクタを有するコントラクトが使用されておらず、代わりに初期化ロジックが使用されていることを検証します。
✓
S1.2 プロキシパターン (Proxy Patterns)
管理目標
プロキシパターンとアップグレードメカニズムが安全に実装され、適切に管理されており、コントラクトアップグレード、廃止、コントラクトバージョン間の移行時のリスクを軽減していることを確認します。
セキュリティ検証要件
S1.2.A アップグレードメカニズム (Upgrade Mechanisms)
S1.2.A1
コントラクトにアップグレードメカニズム (プロキシパターンなど) が実装されていることを検証します。
✓
✓
S1.2.A2
アップグレードプロセスには認可されていないアップグレードに対するセーフガードを含んでいることを確認します。
✓
✓
S1.2.A3
アップグレードメカニズムは文書化され、セキュリティがレビューされていることをチェックします。
✓
✓
S1.2.A4
プロキシのアップグレード時に実装間で不変変数が一貫しており、誤用を防いでいることを検証します。
✓
S1.2.A5
プロキシのセットアップで実装コントラクトの selfdestruct
および delegatecall
が脆弱性や予期しない動作をもたらさないことを検証します。
✓
S1.2.A6
UUPSUpgradeable コントラクトが初期化されていない実装コントラクトに影響を及ぼす可能性のある脆弱性から保護され、安全なアップグレードメカニズムを確保していることを検証します。
✓
S1.2.B 非推奨の管理 (Managing Deprecation)
S1.2.B1
非推奨のコントラクトバージョンが正しくマークされ、処理されていることを検証します。
✓
S1.2.B2
非推奨バージョンへのアクセスが制限または無効にされていることを確認します。
✓
S1.2.B3
非推奨バージョンから新しいバージョンへの移行パスが安全であることをチェックします。
✓
S1.2.C 透過プロキシと非透過プロキシ (Transparent vs. Opaque Proxies)
S1.2.C1
透過プロキシと非透過プロキシのどちらが使用されているか、およびそれがコントラクトに適しているかどうかを検証します。
✓
✓
S1.2.C2
プロキシパターンが正しく実装され、脆弱性をもたらさないことを確認します。
✓
✓
S1.2.C3
プロキシパターンの選択が文書化され、正当化されていることをチェックします。
✓
✓
S1.2.C4
初期化されていないコントラクトが攻撃者に乗っ取られないようにし、初期化関数が正しい修飾子で保護されていることを確認します。
✓
S1.2.C5
TransparentUpgradeableProxy
および同様のプロキシパターンがセレクタの衝突とデコード不可能なコールデータを正しく処理して透過性を維持していることを検証します。
✓
S1.3 脅威モデリング (Threat Modeling)
管理目標
徹底した脅威モデリングプロセスを実施することで、スマートコントラクトシステムのセキュリティ脅威を特定、評価、緩和し、リスクを最小限に抑え、重要なコントラクト機能に対して保護が適切にあることを確認します。
セキュリティ検証要件
S1.3.A 脅威の特定 (Identifying Threats)
S1.3.A1
潜在的な脅威が特定され、文書化されていることを検証します。
✓
✓
✓
S1.3.A2
脅威の特定プロセスにセキュリティ専門家からの意見が含まれていることを確認します。
✓
✓
S1.3.A3
脅威がその影響度と発生可能性に基づいて分類されていることをチェックします。
✓
✓
S1.3.A4
フロントランニングに対する保護を実装して、ガバナー提案の作成において、攻撃者が提案をブロックしたり不当な利益を得ることを防ぎます。
✓
S1.3.B リスクの評価 (Assessing Risks)
S1.3.B1
特定した脅威に対してリスク評価が実施されていることを検証します。
✓
✓
S1.3.B2
リスクはその潜在的な影響度と発生可能性に基づいて優先順位付けされていることを確認します。
✓
✓
S1.3.B3
リスク評価の結果が文書化され、レビューされていることをチェックします。
✓
✓
S1.3.C 緩和策の実施 (Implementing Mitigations)
S1.3.C1
優先度の高いリスクに対して緩和策が実施されていることを検証します。
✓
✓
S1.3.C2
緩和戦略が文書化され、テストされていることを確認します。
✓
✓
S1.3.C3
実施した緩和策の有効性がレビューされ、検証されていることをチェックします。
✓
✓
Last updated