カード決済を扱うシステムのセキュリティ基準 PCI DSS の version 4.0 で、自社開発ソフトに含まれる部品（OSS含む）のインベントリ＝実質的な SBOM が求められるようになりました。要件 6.3.2 です。

要件 6.3.2 の中身

6.3.2 は、自社開発・カスタムソフトウェアと、それに組み込まれた第三者ソフトウェアコンポーネント（OSSライブラリ等）の最新のインベントリを維持することを求めます。

  • 対象：カード会員データ環境（CDE）内の自社開発・カスタムアプリ
  • 含めるもの：自作コード、OSSライブラリ、API、ランタイム、その他依存
  • 目的：脆弱性・パッチ管理で「見落とし」を無くす

PCI DSS は形式（CycloneDX / SPDX 等）を指定していませんが、内容は事実上の SBOMです。

いつから必須か

6.3.2 は v4.0 の新規要件で、2025年3月31日まではベストプラクティス扱い、それ以降は完全に必須となりました。

正確な適用範囲・評価方法は PCI SSC の一次情報（PCI DSS v4.0 / v4.0.1）でご確認ください。本記事は技術的・事実的な整理であり、法的助言・適法性保証ではありません。

OSS の観点で何が要るか

「インベントリを持つ」だけでは不十分で、テスト手続きでも**「脆弱性の特定と対処に使うこと」**が求められます。つまり SBOM を起点に、次の運用が要ります。

  1. 含まれる OSS の版を把握する（SBOM）
  2. 各版の**既知脆弱性（CVE）**を継続的にチェックする
  3. あわせて各 OSS のライセンス義務（表示・コピーレフトの伝搬等）も確認する

ライセンスと脆弱性は**同じ棚卸し（SBOM）**から回せます。詳しくは SBOMとは？ をご覧ください。

決済・FinTech 企業への影響

カード決済に関わるソフトを自社開発している決済事業者・FinTech・ECプラットフォームは、6.3.2 対応として「自社アプリに何の OSS が入っているか」を示せる状態が必要です。受託でこうしたシステムを開発する中小ソフトハウスにも、発注元から同様の要求が及び得ます。

まず着手すること

  1. 対象アプリを1つに絞る
  2. 依存マニフェスト／ロックファイルから SBOM（SPDX / CycloneDX）を生成
  3. ライセンスと既知脆弱性を点検し、運用（誰が・どう更新するか）を決める

決済以外でも、EU CRA（CRA対応ページ）や FDA 524B（医療機器の524B）など、SBOM を求める規制は広がっています。一度作った OSS 棚卸しは横展開できます。

→ 自社アプリの OSS 棚卸しの入口として、公開情報ベースの無料サンプルをお作りできます。お問い合わせからどうぞ。