今日求められるアプリケーションセキュリティ・プログラムの構築 (Establishing a Modern Application Security Program)
OWASP Top 10 は、対象となるトピックの最も重大なリスクを周知するための啓発文書です。これは網羅的なリストではなく、あくまで出発点に過ぎません。これまでの版では、これらのリスクを回避するためにアプリケーションセキュリティ・プログラムを開始することを推奨してきましたが、本セクションでは、実効性のあるプログラムをどのように開始し、構築していくかに焦点を当てます。
すでにプログラムを運用している場合は、OWASP SAMM (Software Assurance Maturity Model) や DSOMM (DevSecOps Maturity Model) を用いた成熟度評価を検討してください。これらのモデルは包括的かつ網羅的であり、プログラムを拡張・成熟させるためにどこに注力すべきかを判断するのに役立ちます。なお、SAMM や DSOMM のすべてを完璧にこなす必要はありません。これらはあくまでガイドであり、多くの選択肢を提示するものです。達成不可能な標準や、負担できないプログラムを提示するものではありません。多くのアイデアや選択肢を提供するために、広範な内容となっています。
ゼロからプログラムを開始する場合や、SAMM/DSOMM が現時点では負担が大きいと感じる場合は、以下の助言を参考にしてください。
1. リスクに基づくポートフォリオ・アプローチの確立
- ビジネスの視点から、アプリケーション・ポートフォリオの保護ニーズを特定します。これには、保護対象となるデータ資産に関連するプライバシー法やその他の規制を考慮する必要があります。
- 組織のリスク許容度を反映した、一貫性のある可能性 (Likelihood) と影響 (Impact) の要因を備えた共通リスク評価モデルを確立します。
- すべてのアプリケーションと API を測定し、優先順位を付けます。その結果を構成管理データベース (CMDB) に追加してください。
- 必要なテストの網羅率 (Coverage) と厳格さのレベルを適切に定義するための、アシュアランス・ガイドラインを策定します。
2. 強固な基盤によるイネーブルメント
- すべての開発チームが遵守すべきセキュリティ・ベースラインとして、重点的なポリシーと標準を確立します。
- これらのポリシーを補完し、設計・開発の指針となる、再利用可能な共通のセキュリティ制御 (Security Controls) を定義します。
- 開発者の役割やトピックに合わせた、必須かつ標的を絞ったアプリケーションセキュリティのトレーニング・カリキュラムを確立します。
3. 既存プロセスへのセキュリティ統合
- 安全な実装と検証のアクティビティを、既存の開発・運用プロセスへ定義・統合します。
- アクティビティには、脅威モデリング (Threat Modeling)、安全な設計と設計レビュー、安全なコーディングとコードレビュー、ペネトレーションテスト、および脆弱性の修正 (Remediation) が含まれます。
- 開発・プロジェクトチームが成功できるよう、専門家 (SME: Subject Matter Experts) やサポートサービスを提供します。
- 現在のシステム開発ライフサイクル (SDLC) と、すべてのソフトウェアセキュリティ活動、ツール、ポリシー、プロセスを確認し、文書化します。
- 新規ソフトウェアについては、SDLC の各フェーズに 1 つ以上のセキュリティ・アクティビティを追加します。これらのアクティビティをすべての新プロジェクトで確実に実施することで、許容可能なセキュリティポスチャでソフトウェアが提供されるようになります。
- 最終製品が組織のリスク許容レベルを満たすよう、アクティビティを選択してください。
- 既存のソフトウェア（レガシー資産）については、正式なメンテナンス計画を策定してください。詳細は「運用と変更管理」のセクションを参照してください。
4. アプリケーションセキュリティ教育
- セキュリティチャンピオン・プログラムや、開発者向けの一般的なセキュリティ教育プログラム（普及啓発 (Advocacy) やセキュリティ意識向上プログラムとも呼ばれます）の開始を検討してください。開発者に知っておいてほしいすべてのことを教えるためです。これにより開発者の知識を最新の状態に保ち、安全に業務を行う方法を伝え、組織のセキュリティ文化をよりポジティブなものにできます。また、チーム間の信頼を高め、より良い仕事関係につながることも多いです。OWASP は OWASP Security Champions Guide を通じてこの活動を支援しており、段階的に拡張されています。
- OWASP Education Project では、開発者向けのトレーニング資料を提供しています。ハンズオン学習には OWASP Juice Shop や OWASP WebGoat が最適です。また、最新情報の収集には OWASP カンファレンスや各地の OWASP チャプター会合を活用してください。
5. マネジメントへの可視化提供
- メトリクスに基づく管理を徹底してください。収集したメトリクスと分析データに基づき、改善や資金投入の意思決定を行います。メトリクスには、セキュリティ慣行の遵守状況、発生した脆弱性、緩和された脆弱性、テスト網羅率、タイプ別の不備密度などが含まれます。
- 実装と検証のアクティビティから得られたデータを分析し、根本原因や脆弱性のパターンを特定することで、全社規模での戦略的かつ体系的な改善を推進します。失敗から学び、改善を促進するためのポジティブなインセンティブを提供してください。
繰り返し利用可能なセキュリティ・プロセスの確立と標準的制御の活用
要件とリソース管理フェーズ：
- ビジネス部門と協力し、すべてのデータ資産の機密性、真正性、完全性、可用性に関する保護要件、および期待されるビジネスロジックを含む要件を収集・調整します。
- 機能的および非機能的なセキュリティ要件を含む技術要件をまとめます。要件設定のガイドとして、OWASP ASVS (Application Security Verification Standard) の活用を推奨します。
- セキュリティ・アクティビティを含む、設計、構築、テスト、運用のあらゆる側面をカバーする予算を計画・交渉します。
- プロジェクトのスケジュールにセキュリティ・アクティビティを追加します。
- プロジェクトのキックオフ時にセキュリティ担当者として自己紹介を行い、相談先を明確にします。
提案依頼書 (RFP) と契約：
- 内部または外部の開発者と、SDLC やベストプラクティスを含むセキュリティ要件を交渉します。
- 計画・設計フェーズを含む、すべての技術要件の達成度を評価します。
- 設計、セキュリティ、サービスレベル合意書 (SLA) を含むすべての技術要件を交渉します。
- OWASP Secure Software Contract Annex などのテンプレートやチェックリストを採用してください。
注記: この附則は米国契約法向けに作成されています。サンプル附則を使用する前に、資格のある法律専門家のアドバイスを受けてください。
計画と設計フェーズ：
- 開発者やセキュリティ専門家などの内部ステークホルダーと、計画および設計について交渉します。
- 保護ニーズと想定される脅威レベルに適した、セキュリティ・アーキテクチャ、制御、対抗策、および設計レビューを定義します。
- セキュリティを後付けするのではなく、最初から設計に組み込む方がはるかに費用対効果が高くなります。出発点として OWASP Cheat Sheets や OWASP Proactive Controls を活用してください。
- 脅威モデリングを実施します。
- ソフトウェアアーキテクトに安全な設計コンセプトとパターンを教育し、設計への反映を促します。
- 開発者とともにデータフローを検証します。
- 他のユーザーストーリーと並んで、セキュリティに関するユーザーストーリーを追加します。
安全な開発ライフサイクル (Secure Development Lifecycle)：
- 組織のソフトウェア構築プロセスを改善するために、OWASP SAMM (Software Assurance Maturity Model) の活用を推奨します。
- 開発者に対し、安全なコーディングや堅牢なアプリケーション構築のためのトレーニングを提供します。
- コードレビューを実施します。OWASP Cheat Sheet: Secure Code Review を参照してください。
- 静的分析 (SAST)、ソフトウェア組成分析 (SCA)、シークレットスキャン、IaC (Infrastructure-as-Code) スキャナーなどのツールを提供し、使い方を教育します。
- 可能であれば、開発者をより安全な選択へと導くためのガードレール（技術的な保護策）を作成します。
- 強力で使いやすいセキュリティ制御を構築することは困難です。可能な限り安全なデフォルトを提供し、最も簡単な方法が最も安全な方法となる「舗装された道 (Paved Roads)」（明らかに好ましい方法）を整備してください。OWASP Cheat Sheets は開発者にとって良い出発点であり、多くのモダンフレームワークには認可、検証、CSRF 防止などの標準的かつ効果的なセキュリティ制御が組み込まれています。
- IDE 用のセキュリティプラグインを提供し、活用を推奨します。
- シークレット管理ツールとライセンス、およびその使用方法に関するドキュメントを提供します。
- プライベート AI を提供してください。理想的には、有用なセキュリティドキュメントを満載した RAG (Retrieval-Augmented Generation) サーバー、成果を高めるプロンプト集、および組織のセキュリティツールを呼び出す MCP (Model Context Protocol) サーバーを備えた環境が望ましいです。開発者は好むと好まざるとにかかわらず AI を利用するため、安全な使い方を教育してください。
継続的なアプリケーションセキュリティテストの確立：
- 技術的な機能や IT アーキテクチャとの統合をテストし、ビジネス部門と協力してテストを調整します。
- 技術的・ビジネス的視点から「正常系 (use)」と「異常系 (abuse)」のテストケースを作成します。
- 内部プロセス、保護ニーズ、および想定される脅威レベルに従って、セキュリティテストを管理します。
- セキュリティテストツール（ファザー、DAST など）と安全なテスト環境、およびトレーニングを提供します。または、代わりにテストを実施するか、テスターを雇用してください。
- 高いレベルのアシュアランスが必要な場合は、正式なペネトレーションテスト、ストレステスト、パフォーマンステストを検討してください。
- 開発者と協力してバグレポートから修正すべき項目を決定し、マネージャーは修正のための時間を確保するようにします。
ロールアウト：
- アプリケーションを運用開始し、必要に応じて旧アプリケーションから移行します。
- 構成管理データベース (CMDB) やセキュリティ・アーキテクチャを含む、すべてのドキュメントを完成させます。
運用と変更管理：
- 運用には、アプリケーションのセキュリティ管理に関するガイドライン（例：パッチ管理）を含める必要があります。
- ユーザーのセキュリティ意識を高め、使いやすさとセキュリティの相反する要求を管理します。
- OS、ミドルウェア、ライブラリなどのコンポーネントの更新や移行を含む変更を計画・管理します。
- すべてのアプリをインベントリに登録し、詳細を文書化します。CMDB、セキュリティ・アーキテクチャ、制御、対抗策、運用手順書 (Runbook) などを最新の状態に保ちます。
- すべてのアプリでロギング、監視、アラートを実施します。不足している場合は追加してください。
- 効果的かつ効率的なアップデートとパッチ適用のためのプロセスを構築します。
- 定期的なスキャン（動的、静的、シークレット、IaC、SCA）をスケジュールします。
- セキュリティバグの修正に関する SLA を策定します。
- 従業員（および理想的には顧客）がバグを報告できる手段を提供します。
- ソフトウェア攻撃の手法や可観測性 (Observability) ツールを理解した、訓練済みのインシデント対応チームを確立します。
- 自動化された攻撃を阻止するためのブロッキングまたはシールドツールを運用します。
- 年に一度（またはそれ以上）、設定の要塞化 (Hardening) を実施します。
- 少なくとも年に一度はペネトレーションテストを実施してください（アプリに必要なアシュアランスのレベルによります）。
- ソフトウェアサプライチェーンの要塞化と保護のためのプロセスとツールを確立します。
- 最も重要なアプリケーションとその維持に使用するツールを含めた、ビジネス継続性計画 (BCP) と災害復旧 (DR) 計画を確立・更新します。
システムの廃止：
- 必要なデータはアーカイブし、それ以外のデータは安全に消去します。
- 未使用のアカウント、ロール、権限を削除し、アプリケーションを安全に廃止します。
- CMDB 上でアプリケーションの状態を「廃止 (retired)」に変更します。
OWASP Top 10 を標準として利用する場合
OWASP Top 10 は主に啓発を目的とした文書ですが、2003年の開始以来、業界の事実上の標準 (de facto standard) として利用されてきました。本ドキュメントをコーディングやテストの標準として利用する場合、それは「最低限の出発点」に過ぎないことを認識してください。
標準として使用するのが難しい理由の一つに、本ドキュメントが必ずしも容易にテスト可能な問題ではなく、AppSec の「リスク」を記述している点が挙げられます。例えば A06:2025-安全性を欠いた設計 は、ほとんどのテスト手法の範囲を超えています。また、ロギングと監視が実際に導入され、使用され、効果的に機能しているかの確認は、インタビューや効果的なインシデント対応のサンプリング調査を通じてのみ可能です。静的コード分析ツールはロギングの欠如を検出できますが、ビジネスロジックやアクセス制御が重大なセキュリティ侵害をロギングしているかどうかを判断することは不可能かもしれません。ペネトレーションテスターは、テスト環境でインシデント対応を発動させたことを確認できるかもしれませんが、テスト環境は本番環境と同じ方法で監視されていることはほとんどありません。
以下に、OWASP Top 10 の適切な利用場面をまとめます。
| ユースケース | OWASP Top 10 2025 | OWASP ASVS |
| 啓発 (Awareness) | はい | |
| トレーニング | 初級レベル | 包括的 |
| 設計とアーキテクチャ | 時々 | はい |
| コーディング標準 | 最低限 | はい |
| 安全なコードレビュー | 最低限 | はい |
| ピアレビュー・チェックリスト | 最低限 | はい |
| ユニットテスト | 時々 | はい |
| 統合テスト | 時々 | はい |
| ペネトレーションテスト | 最低限 | はい |
| ツールによるサポート | 最低限 | はい |
| サプライチェーンの安全確保 | 時々 | はい |
アプリケーションセキュリティ標準を導入する場合は、検証・テストが容易な OWASP ASVS (Application Security Verification Standard) の利用を強く推奨します。
ツールベンダーが準拠を主張できる唯一の選択肢は ASVS でしょう。A06:2025-安全性を欠いた設計 を参照すればわかるように、OWASP Top 10 のいくつかのリスクの性質上、ツールだけで OWASP Top 10 を包括的に検出、テスト、または保護することはできません。OWASP は OWASP Top 10 の完全なカバレッジを主張することを推奨していません。それは単に真実ではないからです。