1. サマリ
- •PCI SSCはソフトウェアセキュリティに関する基準Secure Software Standardの最初のメジャーバージョンアップとなる2.0を2026年1月にリリースした[1]。
- •新たに基準本体とは別文書の「機密資産の識別」[2]が導入された。v1.xの「重要な資産（Critical Assets）」は「機密資産（Sensitive Assets）」に置き換わり、機密情報、機密リソース、機密機能、機密動作モードから構成されるものとして整理された。評価対象ソフトウェアの開発ベンダは、本文書に従って機密資産を識別する必要がある。
- •コントロール中心の整理から機密資産中心の整理となり、コントロール目標がセキュリティ目標に変わると共に、全体的に大きく再構成された。個々の要件としては大きく変わらないものの、より詳細になった要件や、機密資産とその構成要素に対して求められる事項として整理・明確化された要件がある。また特定の種類のソフトウェアに対して追加で適用されるモジュールA～Cの一部の要件は、全てのソフトウェアを対象とするコアに移動された。
2. PCI Secure Software Standard の概要
2.1. PCI Secure Software Standard の特徴
以前のコラム「PCI の新たなソフトウェアセキュリティ基準 Software Security Framework - その1：Framework の概要」でご紹介した通り、PCI SSC はソフトウェアセキュリティに関する基準として、PCI Software Security Framework（SSF）を2019年1月にリリースしました。SSFは、ソフトウェア自体のセキュリティにフォーカスしたSecure Software Standardと、ソフトウェアライフサイクルにフォーカスしたSecure SLC Standardの二つの基準から構成されています。今回ご紹介するのは前者のSecure Software Standardの新バージョンです。なおSecure Software StandardはPCI SSCが策定しているものの、対象は決済ソフトウェアに限定されておらず広く一般的なソフトウェアに適用可能な基準です（特にクレジットカード情報（アカウントデータ）を扱うソフトウェアの場合は、追加でモジュールAが適用されます）。以下、公式な略称ではないのですが、何分長いので必要に応じてPCI Secure Software StandardをPCI SSSと略記します。
PCI SSS の特徴として、
- •機密資産（Sensitive Assets）の機密性（Confidentiality）と完全性（Integrity）の保護に特化
- •目標ベースアプローチ（Objective-Based Approach）に基づき、他のPCI基準（PCI DSSなど）と異なり、コントロールの具体的なベースライン（厳密さや頻度）を定めていない
- •適用必須のコアと複数のモジュールから構成され、モジュールはソフトウェアの種類によって追加で適用される
といったことが挙げられます。また検証方法（テスト要件/Test Requirements）にはインタビューや観察（Observe）がなく、v2.0 では主にベンダ文書の調査（Examine vendor documentation）、ソフトウェアの静的解析と動的解析の実施（Perform static/dynamic analysis）から構成されています（一部、証跡の調査（Examine evidence）を求めるテスト要件や、具体的な方法が定められていないテスト要件もあります）。
2.2. 他のソフトウェアセキュリティ基準との比較
現在、PCI SSC以外の団体が策定しているソフトウェア開発におけるセキュリティ基準/規格としては、
- •NIST SP800-218 Secure Software Development Framework（以下：NIST SSDF）[3]
- •OWASP Application Security Verification Standard（以下：OWASP ASVS）[4]
- •ISO/IEC 27034 Application Security[5]
などがあります。ここではPCI SSSを、NIST SSDFおよびOWASP ASVSと簡単に比較してみます。
まずNIST SSDFです。NIST SSDFはプラクティスとその子要素であるタスクから構成されており、各タスクには複数の実装例と他の基準への参照が挙げられています。参照の中にはPCI Secure SLC Standard（以下：PCI Secure SLC）のコントロール目標がありますが、PCI SSSはありません。このことから、NIST SSDFはPCI Secure SLCと対応しており、PCI Secure SLCと同様にPCI SSSとは互いに相補的な基準であると言えます。
表1にNIST
SSDFの各プラクティスとPCI Secure SLCへの参照を示しました（正確には上記の通り、プラクティスの子要素のタスクごとに参照されているのですが、表が煩雑になるのを避けるためプラクティスレベルで記載しています）。
| NIST SSDF Version 1.1 | |
|---|---|
| プラクティス | 参照（PCI Secure SLCのみ） |
| PO.1 ソフトウェア開発のためのセキュリティ要件を定義する（Define Security Requirements for Software Development） | PCI Secure SLC 2.1, 2.2, 2.3, 3.3 |
| PO.2 役割と責務を実装する（Implement Roles and Responsibilities） | PCI Secure SLC 1.1, 1.2, 1.3 |
| PO.3 支援ツールチェーンを実装する（Implement Supporting Toolchains） | N/A |
| PO.4 ソフトウェアセキュリティチェックのための基準を定義、利用する（Define and Use Criteria for Software Security Checks） | PCI Secure SLC 2.5, 3.3 |
| PO.5 ソフトウェア開発のための安全な環境を実装、維持する（Implement and Maintain Secure Environment for Software Development） | N/A |
| PS.1 全ての形式のコードを不正アクセスと改ざんから保護する（Protect All Forms of Code from Unauthorized Access and Tampering） | PCI Secure SLC 5.1, 6.1 |
| PS.2 ソフトウェアリリースの完全性を検証するメカニズムを提供する（Provide a Mechanism for Verifying Software Release Integrity） | PCI Secure SLC 6.1, 6.2 |
| PS.3 個々のソフトウェアリリースをアーカイブ、保護する（Archive and Protect Each Software Release） | PCI Secure SLC 5.2, 6.1, 6.2 |
| PW.1 セキュリティ要件を満たしリスクを低減するようにソフトウェアを設計する（Design Software to Meet Security Requirements and Mitigate Security Risks） | PCI Secure SLC 3.2, 3.3 |
| PW.2 セキュリティ要件とリスク情報の準拠を検証するため、ソフトウェア設計のレビューをする（Review the Software Design to Verify Compliance with Security Requirements and Risk Information） | PCI Secure SLC 3.2 |
| PW.4 重複した機能よりも適切な場合、既存の十分セキュアなソフトウェアを再利用する（Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality） | PCI Secure SLC 3.2, 3.4, 4.1 |
| PW.5 セキュアコーディングプラクティスに従ってソースコードを作成する（Create Source Code by Adhering to Secure Coding Practices） | N/A |
| PW.6 実行時セキュリティを改善するようにコンパイル、インタプリタ、ビルドプロセスを構成する（Configure the Compilation, Interpreter, and Build Processes to Improve Executable Security） | PCI Secure SLC 3.2 |
| PW.7 脆弱性を識別し、セキュリティ要件への準拠を検証するため、人間可読なコードをレビューおよび/または解析する（Review and/or Analyze Human-Readable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements） | PCI Secure SLC 3.2, 4.1 |
| PW.8 脆弱性を識別し、セキュリティ要件への準拠を検証するため、実行可能なコードをテストする（Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements） | PCI Secure SLC 4.1 |
| PW.9 デフォルトでセキュアな設定となるようソフトウェアを構成する（Configure Software to Have Secure Settings by Default） | PCI Secure SLC 8.1, 8.2 |
| RV.1 継続的に脆弱性を識別し、確認する（Identify and Confirm Vulnerabilities on an Ongoing Basis） | PCI Secure SLC 3.4, 4.1, 9.1, 9.2, 9.3 |
| RV.2 脆弱性を評価、優先付けし、修正する（Assess, Prioritize and Remediate Vulnerabilities） | PCI Secure SLC 3.4, 4.1, 4.2, 10.1 |
| RV.3 脆弱性の真因分析をする（Analyze Vulnerabilities to Identify Their Root Causes） | PCI Secure SLC 2.6, 4.2 |
次にOWASP ASVSです。OWASP ASVSはOWASPが策定している規格であり、Webアプリケーションに特化しています。OWASP ASVS v5.0.0にはV1からV17までのチャプターがあります。各チャプターにはコントロール目標と複数のセクションがあり、セクションには具体的な要件と検証方法が定められています。
OWASP ASVS v5.0.0のチャプターを表2に示しました。OWASP ASVSの各チャプターの内容を後述するPCI SSS v2.0のセキュリティ目標と比較すると、OWASP
ASVSではかなり具体的な項目が並んでいることが分かります。
| OWASP ASVS Version 5.0.0 |
|---|
| V1 エンコードとサニタイズ（Encoding and Sanitization） |
| V2 検証とビジネスロジック（Validation and Business Logic） |
| V3 Webフロントエンドセキュリティ（Web Frontend Security） |
| V4 APIとWebサービス（API and Web Service） |
| V5 ファイルの取り扱い（File Handling） |
| V6 認証（Authentication） |
| V7 セッション管理（Session Management） |
| V8 認可（Authorization） |
| V9 自己完結型トークン（Self-contained Tokens） |
| V10 OAuthとOIDC（OAuth and OIDC） |
| V11 暗号（Cryptography） |
| V12 セキュアな通信（Secure Communication） |
| V13 設定（Configuration） |
| V14 データ保護（Data Protection） |
| V15 セキュアコーディングとアーキテクチャ（Secure Coding and Architecture） |
| V16 セキュリティログ取得とエラーハンドリング（Security Logging and Error Handling） |
| V17 WebRTC（WebRTC） |
OWASP ASVSには、NIST SSDFにもPCI SSSにも無い概念として「レベル」があります。レベルは要件ごとに対応の優先度を定めたもので、レベル1:Minimum、レベル2:Standard、レベル3:Advancedのいずれかが設定されています。
なおPCI SSSと異なりNIST SSDFにもOWASP ASVSにも公式の認定の仕組みはありません。
| 基準 | PCI SSSと比較した時の特徴 |
|---|---|
| NIST SSDF |
|
| OWASP ASVS |
|
3. PCI SSS v1.2.1からの変更点の概要
ここからは、PCI SSS v2.0と合わせてリリースされた「v1.2.1からv2.0への重要な変更点のまとめ（Summary of Significant Changes from v1.2.1 to v2.0）」に基づいて、変更点の概要を説明します。
3.1. 「機密資産の識別（Sensitive Asset Identification）」文書の導入
v2.0でのもっとも大きな変更点の一つとして、「機密資産の識別（Sensitive Asset Identification）」という文書が新たに導入されたことが挙げられます。これは基準本体とは別文書になっていますが、v2.0で新たに整理された機密資産の定義と、識別の実施を支援するためのひな形が含まれています。また本文書は基準本体から参照され、本文書に基づいた機密資産の識別を実施することが求められています。
v1.2.1（1.x）では、機密データ、機密機能、機密リソースの全体を指す用語として重要な資産（Critical
Assets）が定義されていました。v2.0ではこれに変わって、ソフトウェア製品そのものを含む、評価対象となるソフトウェア製品の要素の集合として機密資産が定義されました。機密資産には、機密データ、機密リソース、機密機能、機密動作モードが含まれ、これらの関係が「機密資産の識別」の図1に示されています。これを和訳したものを本コラムの図1に示しました。
機密資産の構成要素の内、機密データ、機密機能、機密リソースはv1.2.1（1.x）にもありましたが、v2.0の定義ではより一般化されています。また図1を見ると、機密データ、機密リソース、機密機能には重複があること、機密動作モードは機密機能のサブセットで、機密データと機密リソースとは重複しないことが分かります。また機密動作モードは、v1.2.1では8.2にのみ登場する特権動作モード（privileged
modes of operation）を含み、より一般化したものとして定義されています。
図1：PCI SSS v2.0の機密資産
（引用元：Sensitive Asset Identification p.5 Figure.1を和訳）
3.2. 項目の大幅な再構成
v1.2.1では、最上位にモジュール（コア、A～C）があり、コアの下に12のコントロール目標（Control Objective）がありました。v2.0でも最上位にモジュールがあることは変わりがありませんが、コアの下は11のセキュリティ目標（Security Objective）になりました。v1.2.1（1.x）のコントロール目標は名前の通り、コントロール中心の観点で分類、構成されていましたが、v2.0では保護対象である機密資産中心の観点で分類され、大きく再構成されました。それに伴って、コントロール目標からセキュリティ目標に変更されたものと思われます。またv1.2.1ではテスト要件だった項目がv2.0では一つ上のレイヤとなるセキュリティ要件に移動されたり、モジュールB（端末ソフトウェア要件）およびモジュールC（Webソフトウェア要件）からコアに移動されたりしているものがあります。特にコアは全てのソフトウェアに適用されるため、モジュールB、Cから移動された要件は、アプリケーションの種類によって実質的に新規要件となります。
図2にv2.0のセキュリティ目標、セキュリティ要件、テスト要件（およびガイダンス）の構成を示します。また表4にv1.2.1のコントロール目標とv2.0のセキュリティ目標を示します。
図2：PCI SSS v2.0 のセキュリティ目標、セキュリティ要件、テスト要件の構成
（引用元：PCI Secure Software Standard v2.0 p.8）
| v1.2.1コントロール目標 | v2.0セキュリティ目標 |
|---|---|
| 1. 重要な資産の識別（Critical Asset Identification） | 1. ソフトウェアアーキテクチャ、構成、バージョニング（Software Architecture, Composition, and Versioning） |
| 2. 安全なデフォルト設定（Secure Defaults） | 2. 機密資産の識別（Sensitive Asset Identification） |
| 3. 機密データの保持（Sensitive Data Retention） | 3. 機密資産の保存と保持（Sensitive Asset Storage and Retention） |
| 4. 重要な資産の保護（Critical Asset Protection） | 4. 機密動作モード（Sensitive Modes of Operation） |
| 5. 認証とアクセス制御（Authentication and Access Control） | 5. 機密資産の保護メカニズム（Sensitive Asset Protection Mechanism） |
| 6. 機密データの保護（Sensitive Data Protection） | 6. 機密資産の出力（Sensitive Asset Output） |
| 7. 暗号の利用（Use of Cryptography） | 7. 乱数（Random Numbers） |
| 8. 活動の追跡（Activity Tracking） | 8. 鍵管理（Key Management） |
| 9. 攻撃の検知（Attack Detection） | 9. 暗号（Cryptography） |
| 10. 脅威と脆弱性の管理（Threat and Vulnerability Management） | 10. 脅威と脆弱性（Threats and Vulnerability） |
| 11. 安全なソフトウェアの更新（Secure Software Updates） | 11. 安全な開発と管理（Secure Development and Management） |
| 12. ベンダーセキュリティガイダンス（Vendor Security Guidance） |
v1.2.1のコントロール目標からv2.0のセキュリティ目標に単純にマッピング出来るのはv1.2.1コントロール目標10からv2.0セキュリティ目標10、v1.2.1コントロール目標11および12からv2.0セキュリティ目標11くらいです。v1.2.1のコントロール目標1～9は、いったんバラバラにされた上でv2.0のセキュリティ目標1～9に再構成されています。例えばv1.2.1のコントロール目標7「暗号の利用」とv2.0のセキュリティ目標9「暗号」は、名前からはそのまま対応しているようにも見えますが、実際にはv1.2.1コントロール目標7の要件は、v2.0ではセキュリティ目標1、2、7、8、9に含まれる要件に対応します。
3.3. コア要件の概要
ここではv2.0コア要件のセキュリティ目標ごとに、新しい内容を中心にv1.2.1のモジュールB、Cからコアに移動されたものも含めて概要をご紹介します。
セキュリティ目標1：ソフトウェアアーキテクチャ、構成、バージョニング
セキュリティ目標1は、ソフトウェアアーキテクチャとその構成、およびバージョニングの文書化が主な内容です。v1.2.1の内容も含みますが、概ね新しい内容のセキュリティ要件から構成されています。またv1.2.1のB.1.1（端末ソフトウェアに対する構成の文書化）、C.1.x（SBOM）に対応する内容を含みます。
特にSBOMは、v1.2.1ではWebソフトウェアのみを対象としていましたが、v2.0では全てのソフトウェアに対して要求されることになりました。またバージョニングに関する要件はPCI
Secure SLCにはあるのですが、PCI SSSにはありませんでした。この2点はv1.2.1のやや不自然な点であったと思いますが、v2.0で解消されました。
セキュリティ目標2：機密資産の識別
セキュリティ目標2は、機密資産の識別とその保持に関するセキュリティ要件から構成されます。v1.2.1のコントロール目標1（重要な資産の識別）、6.1（保存機密データの保護）、7.2（鍵管理）などに対応する内容を含みます。v1.2.1の1.2でも機密リソースと機密機能の識別は求められていましたが、v2.0ではこれらの識別に関する要件で求められる内容がより詳細になっています。
セキュリティ目標3：機密資産の保存と保持
セキュリティ目標3は、機密資産の保存（Storage、ストレージへの保存）と保持（Retention、メモリ上での保持）に関する要件です。概ねv1.2.1のコントロール目標3に対応しますが、対象が機密データに加えて、機密リソース、機密機能も含まれるように拡張されています。
セキュリティ目標4：機密動作モード
セキュリティ目標4は、機密動作モードに関する要件から構成されます。機密動作モードは機密機能のサブセットとしてv2.0で新たに整理された概念のため、機密動作モードに対する要件として明確化され、その意味で新しい要件を多く含むセキュリティ目標となっています。
セキュリティ目標5：機密資産保護のメカニズム
セキュリティ目標5は、機密資産保護のメカニズムに関する要件です。v1.2.1のさまざまな要件に対応し、保護の対象が、重要な資産から機密資産とその構成要素に拡張されています。またv1.2.1ではコア以外の要件だったB.1.2（データフロー図と機能の文書化）、B.3.2（エラーハンドリング）、C.1.7（サードパーティコンポーネントの真正性確認）、C.3.2（信頼できないソースからの入力値の検証）などに対応する内容が統合されています。
セキュリティ目標6：機密資産の出力
セキュリティ目標6は機密資産の出力に関する要件です。ここでいう「出力」には、ハードウェアI/Fを介した出力に加えて、ネットワークによる伝送、プラットフォームOSへの「出力」、同じプラットフォームで動作している他のアプリへの「出力」、共有メモリへの「出力」など、ソフトウェアから見た他の何かへの全ての出力を含みます。
内容的には概ねv1.2.1の6.2に対応しますが、対象が機密データだけでなく、機密リソース、機密機能も含めるよう拡張されています。
セキュリティ目標7：乱数
セキュリティ目標7は乱数に関する要件です。概ねv1.2.1の7.1-7.3に対応しますが、より詳細な内容を含みます。また新しい内容としてシードに関する要件（7-1.3.2～7-1.3.4）が追加されています。
セキュリティ目標8：鍵管理
セキュリティ目標8は鍵管理に関する要件です。概ねv1.2.1の7.1、7.2に対応します。v1.2.1の7.2ではテスト要件だったものが、v2.0では一つ上のレイヤであるセキュリティ要件になったものを含みます。またv2.0の8-2.1では、平文鍵の不揮発性メモリ（ストレージ）への保存禁止が明確化されています。
セキュリティ目標9：暗号
セキュリティ目標9は暗号に関する要件です。概ねv1.2.1の6.3、7.1に対応する内容です。v2.0ではコントロールではなく機密資産に基づく分類となったため、セキュリティ目標9以外にも暗号に関する要件が含まれています。セキュリティ目標9は、他のセキュリティ目標/要件でカバーされていない暗号利用に対しても強力な暗号の利用を要求する、全体を補完するものとなっています。
セキュリティ目標10：脆弱性管理
セキュリティ目標10は脆弱性管理に関する要件です。ほぼそのままv1.2.1のコントロール目標10に対応します。
セキュリティ目標11：セキュアな配布と管理
セキュリティ目標11はソフトウェアの配布と管理に関する要件です。v1.2.1のコントロール目標11に対応する内容に加えて、コントロール目標12（実装ガイドに関する要件）に対応する内容を含みます。
3.4. コア要件以外のモジュールの概要
コア以外のモジュールについても簡単にご紹介します。
モジュール A：アカウントデータの保護要件
アカウントデータを伝送、処理、保存するソフトウェアに適用される追加要件です。アカウントデータの保護に関する内容で構成されます。v1.2.1では、許容されるPANの保護方法がトランケーション、インデックストークンとパッド、暗号化のみとなっており、PCI DSS v4.0.xで許容されている暗号学的鍵付ハッシュが含まれていませんでした。v2.0ではPCI DSSとの整合性を取るように、PCI DSSを参照する旨の記述に変更されました。
モジュールB：POI デバイスソフトウェア
PCI PTS POIデバイス上に配布、実行されるソフトウェアに適用される追加要件です。モジュールの名称が「端末ソフトウェア要件（Terminal Software Requirements）」から「POI デバイスソフトウェア（POI Device Software）」に変更されました。コアに移動（統合）された以外の残りの要件は整理され、より詳細になった要件も含まれます。特にPTS POI SREDに関して、認定にSREDが含まれる場合（B2-1）と含まれない場合（B2-2）で、セキュリティ要件が分割整理されました。
モジュールC：パブリックにアクセス可能なソフトウェア
パブリックネットワークを介してアクセス可能なソフトウェアに適用される追加要件です。名称が「Webソフトウェア要件（Web Software Requirements）」から「パブリックにアクセス可能なソフトウェア（Publicly-accessible Software）」に変更されました。C.1.5（ソフトウェア更新時のSBOMの更新）とC.1.6（サードパーティコンポーネントとサービスのモニタリング）はPCI Secure SLCで考慮されている要件としてPCI SSSからは削除されました。コアに移動（統合）された以外の残りの要件は整理され、より詳細になった要件も含まれます。
モジュールD：ソフトウェア・デベロップメント・キット
v2.0で新たに追加されたモジュールで、SDKとして提供されるソフトウェアに適用される追加要件です。SDKの設計について、SDK自体の改ざんや機密資産への侵害を低減すること（D1-1）、および統合するアプリケーションがSDKの整合性と真正性を容易にすること（D1-2）が要求されています。
4. まとめ
PCI SSCが策定しているSecure Software Standardのv2.0について、v1.2.1からの変更点を中心にご紹介しました。
「機密資産の識別」という新たな外部文書が導入され、機密情報、機密リソース、機密機能、機密動作モードという概念が導入、整理されました。また、それに伴いコア要件を構成する要素は、コントロール中心のコントロール目標から、保護対象である機密資産中心のセキュリティ目標に変わりました。その一方で、個々の要件としては大きく変わりありませんが、より詳細になった要件や、機密資産の各要素に対して求められる事項として整理・明確化された要件があります。コア以外のモジュールについては、アカウントデータを取り扱うモジュールAがPCI
DSSとの整合性を取るように修正され、各モジュールの一部の要件がコアに移動された上で再構成されました。またSDKを対象とするモジュールDが新たに導入されました。
当社は、PCI Secure Software Standardに基づいたソフトウェアセキュリティの評価を実施する資格を有する、国内唯一のSecure Software Assessor会社です。自社ソフトウェアに対するPCI Secure Software Standardによる評価にご興味のあるお客様は、お気軽にお問い合わせください。
PCI準拠支援／非保持化対応支援サービス
PCI準拠支援／非保持化対応支援サービス | 株式会社NTTデータ先端技術
参考文献
- [1]PCI SSC Releases Version 2.0 of the PCI Secure Software Standard
https://blog.pcisecuritystandards.org/pci-ssc-releases-version-2.0-of-the-pci-secure-software-standard - [2]Sensitive Asset Identification For use with the PCI Secure Software Standard v2.x
https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-Sensitive-Asset-Identification_v1.0.pdf - [3]NIST SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
https://csrc.nist.gov/pubs/sp/800/218/final - [4]OWASP Application Security Verification Standard (ASVS)
https://owasp.org/www-project-application-security-verification-standard/ - [5]ISO/IEC 27034-1:2011 Information technology --Security techniques-- Application security
https://www.iso.org/standard/44378.html
- ※文中の商品名、会社名、団体名は、一般に各社の商標または登録商標です。