検証対象のアプリケーションが以下を備えていることを確認します。
- 安全で、再現性があり、自動化可能なビルド環境
- サードパーティのライブラリ、依存関係、構成管理を強化し、アプリケーションに古いコンポーネントや安全でないコンポーネントが含まれないようにします
既定のアプリケーションを構成することは、インターネット上で安全である必要があり、安全に構成する必要があります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 1.14.1 | [削除, スコープ外] | ||||
| 1.14.2 | [削除, スコープ外] | ||||
| 1.14.3 | [削除, 14.2.1 と重複] | ||||
| 1.14.4 | [削除, スコープ外] | ||||
| 1.14.5 | [1.10.4, 10.5.1 へ分割] | ||||
| 1.14.6 | [50.8.2 へ移動] | ||||
| 1.14.7 | [修正, 1.1.5 から移動] アプリケーションのすべての通信が文書化されている。これには、アプリケーションが依存する外部サービスや、アプリケーションが接続する外部ロケーションをエンドユーザが提供できる可能性がある場合が含まれる。 | ✓ | ✓ | 1059 |
ビルドパイプラインは再現性のあるセキュリティの基盤です。安全でない何かが発見されるたびに、それをソースコード、ビルドまたはデプロイスクリプトで解決し、自動的にテストが可能。既知のセキュリティの問題が本番環境に展開されないようにビルドを警告または中断する自動セキュリティおよび依存関係のチェックを備えたビルドパイプラインの使用を強く勧めます。不規則に実行される手動手順は、回避可能なセキュリティのミスに直結します。
業界として DevSecOps モデルに移行するにつれ、「Known good（既知の良好な）」状態を実現するには、デプロイメントと構成の継続的な可用性と整合性を確保することが重要。以前はシステムがハッキングされた場合に、それ以上の侵害が生じていないことを証明するのに数日から数か月かかりました。今日では、ソフトウェア定義のインフラストラクチャ、ダウンタイム無しでの迅速な A/B デプロイメント、そして自動化コンテナ化されたビルドでは、侵害された「既知の良好な」代替品を自動的かつ継続的にビルド、強化、デプロイすることができます。
もし従来のモデルがまだ存在する場合は、その構成を強化してバックアップするために手動の手順を実行し、侵害されたシステムを整合性の高い妥協のないシステムに迅速に交換できるようにする必要があります。
このセクションに準拠するには、自動ビルドシステムと、ビルドおよびデプロイスクリプトへのアクセスが必要です。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.1.1 | [削除, スコープ外] | ||||
| 14.1.2 | [レベル L2 > L3] コンパイラフラグが、スタックのランダム化、データ実行防止などの利用可能なすべてのバッファオーバーフローの保護と警告を有効にし、安全でないポインタ、メモリ、フォーマット文字列、整数、または文字列操作が見つかった場合にビルドを中断するように構成されている。 | ✓ | 120 | ||
| 14.1.3 | [修正] すべてのサードパーティ製品、ライブラリ、フレームワーク、サービスにおいて、それぞれの推奨事項に従って、設定の堅牢化が実行されている。 | ✓ | ✓ | 16 | |
| 14.1.4 | [削除, スコープ外] | ||||
| 14.1.5 | [修正] デプロイされた環境の有効期間が短く、頻繁に再デプロイされて「既知の良好な」更新された状態である。あるいは、有効期間が長い環境ではデプロイされた構成が安全でない状態に変更されないように、何らかの形の「ドリフト防止」を使用する必要がある。 | ✓ | |||
| 14.1.6 | [14.2.2 から移動] 不要な機能、ドキュメント、サンプルアプリケーション、コンフィギュレーションがすべて削除されている。 | ✓ | ✓ | ✓ | 1002 |
| 14.1.7 | [追加] 本番環境にテストコードが含まれていない。 | ✓ | ✓ | 489 | |
| 14.1.8 | [追加] ビルドとデプロイメントプロセスに関連するデータ、状態情報、およびサーバーインスタンスはそのプロセスが終了した後には保持しない。 (一過性) | ✓ | |||
| 14.1.9 | [追加] アプリケーションコードや機能は標準的な更新プロセスまたはビルドプロセスを通じてのみ変更可能であり、アプリケーション機能やその他の直接変更メカニズムを通じて本番環境で直接変更することはできない。 | ✓ | ✓ | ||
| 14.1.10 | [修正, MOVED FROM 2.5.4 から移動] デフォルトユーザーアカウント ("root", "admin", "sa" など) がアプリケーションに存在しないか、無効になっている。 | ✓ | ✓ | ✓ | 798 |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.2.1 | [1.10.5, 10.6.1 へ分割] | ||||
| 14.2.2 | [14.1.6 へ移動] | ||||
| 14.2.3 | [50.7.1 へ移動] | ||||
| 14.2.4 | [削除, 1.10.2 へ移動] | ||||
| 14.2.5 | [1.10.2 へ移動] | ||||
| 14.2.6 | [1.10.3, 10.5.1 へ分割] |
本番環境の構成を強化して、一般的な攻撃から保護すべきです。対策としては、デバッグコンソールの無効化、クロスサイトスクリプティング（Cross-site Scripting, XSS）とリモートファイルインクルード（Remote File Inclusion, RFI）攻撃の基準の引き上げ、ペネトレーションテストの報告に散見される発見された些細な脆弱性の排除などが挙げられます。これらの問題の多くはめったに重大なリスクとして評価されませんが、他の脆弱性と連鎖します。これらの問題がデフォルトで存在しない場合、ほとんどの攻撃が成功する前にレベルが引き上げられます。
たとえば、サーバサイドコンポーネントのバージョンを非表示にしても、すべてのコンポーネントにパッチを適用する必要性がなくなるわけではありませんし、フォルダの一覧表示を無効にしても、認可コントロールを使用したり、パブリックフォルダからファイルを遠ざける必要性がなくなるわけではありませんが、ハードルを引き上げます。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.3.1 | [削除, 7.4.1 と重複] | ||||
| 14.3.2 | [修正] デバッグ機能の開示や意図しない情報漏洩を防ぐために、運用環境ではすべてのコンポーネントのデバッグモードが無効になっている。 | ✓ | ✓ | ✓ | 497 |
| 14.3.3 | [修正] アプリケーションはサーバサイドコンポーネントの詳細なバージョン情報を公開していない。 | ✓ | ✓ | ✓ | 200 |
| 14.3.4 | [追加, 4.3.2 から分割] ディレクトリリスティグは、意図して許可されない限り、無効となっている。 | ✓ | ✓ | ✓ | 548 |
| 14.3.5 | [追加, 4.3.2 から分割] ファイルやディレクトリのメタデータ (Thumbs.db、.DS_Store、.git、.svn フォルダなど) の検出や開示が許可されていない。 | ✓ | ✓ | ✓ | |
| 14.3.6 | [文法, 12.5.1 から移動] 意図しない情報やソースコードの漏えいを防ぐために、特定のファイル拡張子を持つファイルのみを処理するように Web 層が構成されている。例えば、バックアップファイル（.bak など）、一時作業ファイル（.swp など）、圧縮ファイル（.zip、.tar.gz など）およびエディタで一般的に使用されるその他の拡張子は、必要ない限り処理しない。 | ✓ | ✓ | ✓ | 552 |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.4.1 | [13.1.7 へ移動] | ||||
| 14.4.2 | [削除, 50.6.1 へマージ] | ||||
| 14.4.3 | [50.3.1 へ移動] | ||||
| 14.4.4 | [50.3.2 へ移動] | ||||
| 14.4.5 | [50.3.3 へ移動] | ||||
| 14.4.6 | [50.3.4 へ移動] | ||||
| 14.4.7 | [50.3.5 へ移動] |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.5.1 | [13.6.1 へ移動] | ||||
| 14.5.2 | [削除, 4.1.1 と重複] | ||||
| 14.5.3 | [50.3.6, 50.4.3 へ分割] | ||||
| 14.5.4 | [削除, 不正確] |
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.6.1 | [文法, 12.6.1 から移動] Web サーバまたはアプリケーションサーバはサーバがリクエストを送信したり、データやファイルをロードできるリソースやシステムの許可リストで構成されている。 | ✓ | ✓ | ✓ | 918 |
| 14.6.2 | [修正, 1.2.1 から移動] ローカルまたはオペレーティングシステムのサービス、API、ミドルウェア、データレイヤなどのバックエンドアプリケーションコンポーネント間の通信は最小限の権限が割り当てられたアカウントで実行されている。 | ✓ | ✓ | 272 |
アプリケーションは、API、データベース、その他のコンポーネントを含む複数の外部サービスとやり取りする必要があります。これらはアプリケーションの内部とみなされるかもしれませんが、アプリケーションの標準アクセス制御メカニズムに含まれていないか、完全に外部かもしれません。いずれの場合も、これらのコンポーネントと安全にやり取りするようにアプリケーションを構成し、必要に応じてその構成を保護する必要があります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.7.1 | [修正, 2.10.1 から移動, 1.2.2 からマージ] API、ミドルウェア、データレイヤなど、アプリケーションの標準ユーザセッションメカニズムをサポートしていないバックエンドアプリケーションコンポーネント間の通信は認証されている。認証は、パスワード、API キー、特権アクセスを備えた共有アカウントなどの不変のクレデンシャルではなく、個別のサービスアカウント、短期トークン、証明書ベースの認証を使用する必要がある。 | ✓ | ✓ | 287 | |
| 14.7.2 | [文法, 2.10.2 から移動] サービス認証にクレデンシャルを使用する必要がある場合、コンシューマが使用するデフォルトクレデンシャルではない (たとえば、一部のサービスではインストール時に root/root や admin/admin がデフォルトになる)。 | ✓ | ✓ | 255 | |
| 14.7.3 | [修正, 4.3.3 から移動] アプリケーションが外部のデータベースやサービスとの統合のためにパスワードや接続パラメータに関する構成の変更を許可する場合、それらは再認証や複数ユーザ承認などの特別なコントロールによって保護されている。 | ✓ | ✓ | 732 |
シークレット管理は、アプリケーションで使用されるデータの保護を確保するために不可欠な構成タスクです。暗号に関する具体的な要件は V6 章にありますが、このセクションではシークレットの管理と取り扱いの側面に焦点を当てています。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 14.8.1 | [修正, 6.4.1 から移動, 1.6.2, 2.10.4 からマージ] key vault などのシークレット管理ソリューションは、バックエンドシークレットを安全に作成、保管、アクセス制御、破棄するために使用している。これには、パスワード、鍵マテリアル、データベースやサードパーティシステムとの統合、シードや内部セキュリティ、API キーなどを含む。シークレットはアプリケーションのソースコードやビルド成果物に含めてはいけない。L3 アプリケーションでは、これには HSM などのハードウェア支援のソリューションを含む必要がある。 | ✓ | ✓ | 798 | |
| 14.8.2 | [修正, 6.4.2 から移動] 鍵マテリアルはアプリケーション (フロントエンドでもバックエンドでも) には公開されないが、代わりに暗号操作のために vault などの分離されたセキュリティモジュールを使用している。 | ✓ | ✓ | 320 | |
| 14.8.3 | [追加] 重要なシークレットには有効期限が定義されており、組織の脅威モデルとビジネス要件に基づいたスケジュールでローテーションしている。 | ✓ | ✓ | 320 | |
| 14.8.4 | [追加] シークレット資産へのアクセスは最小権限の原則に従っている。 | ✓ | ✓ | 320 |
詳しくは以下の情報を参照してください。