A06:2025 安全性を欠いた設計 (Insecure Design)

背景 (Background)

「安全性を欠いた設計」は、前回から順位を2つ下げて第6位となりました。これは「セキュリティ設定の不備 (A02)」と「ソフトウェアサプライチェーンの失敗 (A03)」が急上昇し、本カテゴリを追い越した結果、こうなりました。2021年に導入されて以来、業界全体で脅威モデリング（Threat Modeling）への関心が高まり、設計の安全性を重視する傾向が強まったことで、一定の改善が見られます。本カテゴリは、設計やアーキテクチャの欠陥に起因するリスクに焦点を当てており、脅威モデリング、安全な設計パターン、およびリファレンスアーキテクチャのさらなる活用を求めています。これには、アプリケーション内部で予期しない状態変化を定義していないといった、ビジネスロジックの不備も含まれます。

私たちは、コーディングにおける「シフトレフト」を超え、セキュア・バイ・デザイン（Secure by Design）の原則に不可欠な、要件定義や設計といった「実装前のアクティビティ」を強化しなければなりません（今日求められるアプリケーションセキュリティプログラムの確立: 計画・設計フェーズを参照）。主要な CWE (共通弱点一覧) には、認証情報の保護されていない保存 (CWE-256)、不適切な特権管理 (CWE-269)、危険な種類のファイルの無制限アップロード (CWE-434)、信頼境界の侵害 (CWE-501)、および認証情報の保護不足 (CWE-522) が含まれます。

スコアテーブル (Score Table)

紐付けられた CWE 数	最大出現率	平均出現率	最大網羅率	平均網羅率	平均加重悪用スコア	平均加重影響スコア	出現総数	CVE 総数
39	22.18%	1.86%	88.76%	35.18%	6.96	4.05	729,882	7,647

説明 (Description)

安全性を欠いた設計は、「制御設計の欠落または効果の不足」を意味する広範なカテゴリです。「安全性を欠いた設計 (Insecure Design)」と「不適切な実装 (Insecure Implementation)」は明確に区別されるべきです。これらは根本原因、発生フェーズ、および修正方法が異なります。設計が安全であっても実装に不備（バグ）が生じることはありますが、設計自体に欠陥がある場合、たとえ実装を完璧に行っても、特定の攻撃を防ぐためのセキュリティ制御がそもそも存在しないことになります。

安全な設計を実現するためには、以下の 3 要素を柱としたガバナンスが必要です。

1. 要件定義とリソース管理 (Requirements and Resource Management)

ビジネス部門と協力し、すべてのデータ資産の機密性、真正性、完全性、可用性に関する保護要件と、期待されるビジネスロジックを収集・調整してください。アプリケーションの露出状況を考慮し、アクセス制御とは別に、テナント間の隔離が必要かどうかを判断します。機能要件および非機能セキュリティ要件を含む技術要件を取りまとめてください。また、セキュリティ活動を含む、設計から運用までの全フェーズをカバーする予算を計画し、調整してください。

2. 安全な設計 (Secure Design)

安全な設計とは、脅威を絶えず評価し、既知の攻撃手法を防御できるよう堅牢に設計・テストする文化と手法です。脅威モデリングをリファインメントセッション（または類似のアクティビティ）に統合し、データフローやアクセス制御、その他のセキュリティ制御の変更を注視してください。ユーザーストーリー作成時には、正常なフローだけでなく「失敗時の状態 (Failure States)」を定義し、責任者および影響を受ける関係者間で十分に理解され、合意されていることを確認してください。正常系および異常系の前提条件を分析し、それらが正確かつ望ましい状態を維持していることを確認してください。前提条件を検証し、適切な挙動に必要な条件を強制する方法を決定してください。結果はユーザーストーリーに文書化してください。失敗から学び、改善を促進するためのポジティブなインセンティブを提供してください。安全な設計は、ソフトウェアに後付けできるアドオンやツールではありません。

3. 安全な開発ライフサイクル (Secure Development Lifecycle)

ソフトウェアの安全性を確保するには、安全な開発ライフサイクル (SDLC)、安全な設計パターン、舗装された道（Paved Road）の方法論、セキュアなコンポーネントライブラリ、適切なツール、脅威モデリング、およびプロセス改善のためのインシデントポストモータム（事後検証）が必要です。ソフトウェアプロジェクトの開始時から、プロジェクト全体を通じて、そして継続的なソフトウェア保守においても、セキュリティ専門家と連携してください。OWASP Software Assurance Maturity Model (SAMM) を活用して、安全なソフトウェア開発の取り組みを構造化することを検討してください。

開発者自身が負うべき責任が大きいことは、ときに十分に自覚されていないものです。意識、責任、およびプロアクティブなリスク軽減の文化を醸成してください。セキュリティに関する定期的な意見交換（脅威モデリングセッション中など）は、重要な設計上の意思決定においてセキュリティを考慮するマインドセットを生み出すことができます。

防止方法 (How to Prevent)

セキュリティ専門家と協力し、セキュリティやプライバシーに関する制御を設計・評価するための SDLC を確立・運用してください。
安全な設計パターンのライブラリ、あるいは舗装された道（Paved Road）のコンポーネントを活用してください。
認証、アクセス制御、ビジネスロジック、および主要なデータフローに対して、脅威モデリングを継続的に実施してください。
セキュリティマインドセットを醸成するための教育ツールとして、脅威モデリングを活用してください。
セキュリティ要件と制御を、ユーザーストーリーに統合してください。
各層（フロントエンドからバックエンド）において、妥当性チェック (Plausibility Checks) を統合してください。
ユニットテストおよび統合テストを作成し、主要なフローが脅威モデルに対して耐性を持っていることを検証してください。正常系 (Use-cases) だけでなく、異常系 (Misuse-cases) のテストも不可欠です。
露出状況や保護ニーズに応じて、システム層およびネットワーク層を分離（Segregate）してください。
設計段階から、すべての層において堅牢なテナント分離を徹底してください。

攻撃シナリオの例 (Example Attack Scenarios)

シナリオ #1：不適切な資格情報リカバリ 資格情報の復旧ワークフローに「秘密の質問と回答」が含まれているケース。これは NIST 800-63b や OWASP ASVS で禁止されています。回答は本人以外も知りうるため、証拠として信頼できません。このような機能は削除し、より安全な設計に置き換える必要があります。

シナリオ #2：ビジネスロジックの不備（大量予約） ある映画館チェーンが、15名以上の予約時にのみデポジットを要求していた。攻撃者がこのフローを分析し、デポジットなしで全館・全席を占有し続ける攻撃が可能であることを突き止めた。これにより、映画館側は甚大な収益損失を被ることになります。

シナリオ #3：ボット対策の欠如（買い占め） eコマースサイトに、転売目的のボットによる買い占め対策が備わっていなかった。結果、高価なビデオカードが発売直後にボットに独占され、一般の愛好家が購入できない事態を招いた。発売から数秒以内の購入を識別して拒否するといった、ドメインロジックに基づいたアンチボット設計が必要です。