PCI DSS対応ソフトウェアとは？準拠を助ける製品と自社開発ソフトの要件を整理

クレジットカードのカード会員データを扱う事業者には、カード業界のセキュリティ基準であるPCI DSSへの準拠が求められます。準拠に向けて「どんなソフトウェアを用意すればよいのか」を調べ始めると、WAFやログ監視、静的解析、脆弱性診断といった製品ページが並び、どれが自社に必要なのか判断しづらいと感じる担当者は少なくありません。

その迷いの多くは、「PCI DSS ソフトウェア」という言葉が2つの別々の意味で使われていることに原因があります。ひとつは準拠を助けるソフトウェア製品、もうひとつは自社が開発・運用するソフトウェアがPCI DSSで満たすべき要件です。この2つを切り分けないまま製品を探すと、目的に合わないツールを順に検討しては外す、という遠回りになりがちです。

本記事では、まず「PCI DSS ソフトウェア」の2つの意味を整理し、要件ごとにどの種類のソフトウェアが対応に役立つかを一覧で示した対応表を用意しました。そのうえで、自社開発ソフトウェアに課される要件6・11の中身をPCI DSS v4.0.1の要件番号で確認し、準拠を助けるソフトウェアの種類と自社で検査を回す手段、費用や進め方の目安までを解説します。

カード会員データを扱う事業会社のご担当者が、自社に必要なソフトウェアを見極める材料としてご活用ください。

PCI DSSにおける「ソフトウェア」が指す2つの意味

ここからは、「PCI DSS ソフトウェア」という言葉が指す2つの意味を切り分けます。自社がどちらを探しているのかをはっきりさせると、必要なソフトウェアの範囲が絞り込めます。

準拠を助けるソフトウェア製品とは

1つ目は、PCI DSSの個別の要件に対応するために導入するソフトウェア製品です。たとえば、公開中のWebアプリケーションを守るWAF（Web Application Firewall）、アクセス記録を集めて監視するログ監視、アクセス権を管理するID管理、開発したコードの弱点を見つける静的解析などが該当します。

これらは「どの製品がどの要件に役立つか」で選ぶもので、1つの製品ですべての要件をまかなえるわけではありません。どの種類のソフトウェアがどの要件に対応するかは、後述の対応表で整理します。

自社で開発・運用するソフトウェアに課される要件とは

2つ目は、自社が開発したり委託して作らせたりしているソフトウェアそのものが、PCI DSSで満たすべき要件です。カード会員データを扱うアプリケーションを自社で開発している場合、要件6（安全なシステムおよびソフトウェアの開発・維持）や要件11（セキュリティのテスト）が関わります。

具体的には、セキュアコーディングやソフトウェア部品の管理、定期的な脆弱性スキャン・ペネトレーションテストが求められます。

こちらは製品を買って終わりではなく、開発・運用のプロセスに組み込む取り組みです。要件6・11で具体的に何を求められるかは、後半の要件解説で確認します。

自社はどちらのケースに当てはまるか

カード会員データを扱うすべての事業者は、要件に対応する製品（1つ目）を検討する立場にあります。加えて、カードデータを扱うアプリケーションを自社で開発・運用している場合は、そのソフトウェア自体に課される要件（2つ目）も同時に満たす必要があります。

決済を外部の決済代行サービスに任せ、自社ではアプリを作っていない場合は、2つ目の比重は小さくなります。ただし自社サイトに決済ページを持ち、外部の決済サービスへ連携しているなら、決済ページのスクリプト管理（要件6.4.3）や改ざん検知（要件11.6.1）は自社に残ります。

一方で、要件6のセキュアコーディングのような自社開発ソフト向けの対応は不要です。

一方、ECサイトや決済系SaaSを内製している企業は、製品側と自社開発ソフト側の両方にまたがると考えて準備を進めるのが現実的です。

そもそもPCI DSSとは（6つの目標と12要件）

PCI DSS（Payment Card Industry Data Security Standard）は、クレジットカードのカード会員データを安全に扱うために、国際カードブランドが共同で策定し、PCI SSC（PCI Security Standards Council）が管理するセキュリティ基準です。カード会員データを保存・処理・伝送する事業者が対象になります。

基準は6つの目標と12の要件で構成され、ネットワークの保護、カード会員データの保護、脆弱性管理、アクセス制御、監視とテスト、情報セキュリティポリシーの整備を幅広くカバーします。

現行版はv4.0.1で、2024年6月にv4.0の限定的な改訂として公開されました。v4.0で新設された要件の多くは「未来日付要件」として段階的に適用され、2025年3月31日に発効済みです。本記事では要件番号をv4.0.1の採番で扱います。

v4.0からv4.0.1にかけて新設・変更された要件が、それぞれいつまでに必須化されたのかを、v3.2.1からの差分として要件番号つきの一覧で確認したい場合は、以下の記事をご覧ください。

ソフトウェアの観点から押さえておきたいのは、12要件のうち要件6が「開発」に、要件11が「テスト」に関わり、ほかの要件（WAF・ログ・アクセス管理など）は主に運用・技術対策で満たすという構造です。

出典・参考資料（2件）

• 参考資料：PCI DSS｜PCI Security Standards Council（https://www.pcisecuritystandards.org/standards/pci-dss/）
• 出典：Now is the Time for Organizations to Adopt the Future-dated Requirements of PCI DSS v4.x｜PCI SSC Blog（https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x）

要件別に見る、どの要件をどの種類のソフトウェアで対応するか

ここでは、PCI DSSの主な要件と、その対応に役立つソフトウェアの種類を対応表にまとめます。要件番号はv4.0.1の採番です。自社に不足している領域を見つける地図として使ってください。

要件（v4.0.1）	要件の概要	対応に役立つソフトウェアの種類	自前ツール／製品／診断委託
要件1	ネットワークセキュリティ制御（内部と外部ネットワークの境界制御）	ファイアウォール、ネットワークセキュリティ制御（NSC）	製品を導入
要件3・4	保存・伝送するカード会員データの保護	暗号化・鍵管理、トークン化（カード情報の非保持化）	製品を導入／決済代行の活用
要件5	マルウェア（悪意あるソフトウェア）からのシステム保護（導入・定期的な更新・検出と駆除）	アンチマルウェア／EDR（エンドポイント検知・対応）	製品を導入
要件6.2.4	開発するソフトウェアで一般的な攻撃・脆弱性を防ぐ手法を定義・実施	SAST（静的アプリケーションセキュリティテスト）／静的解析	自前ツール／製品
要件6.3.2	自社開発ソフトと組み込んだ第三者コンポーネントの目録を維持	SCA（ソフトウェア構成分析）／SBOM作成	自前ツール／製品
要件6.4.2	公開Webアプリへの攻撃を継続的に検知・防止	WAF（Web Application Firewall）	製品を導入
要件7・8	必要最小限へのアクセス制限と利用者の本人確認	ID・アクセス管理（IAM）、多要素認証	製品を導入
要件10	システムとカード会員データへのすべてのアクセスのログ記録・監視	ログ監視・SIEM（ログ集約・相関分析）	製品を導入
要件11.3.1	内部脆弱性スキャン（四半期ごと＋重要な変更後）	脆弱性スキャナ、動的診断（DAST）（内部はASV認定不要）	自前ツール／診断委託
要件11.3.2	外部脆弱性スキャン（四半期ごと＋重要な変更後）	PCI SSC認定ASVによる外部スキャン	ASV（認定事業者）に委託
要件11.4	外部・内部ペネトレーションテスト	ペネトレーションテスト	診断委託（自前で実施する場合もあり）
要件11.6.1	決済ページの不正なスクリプト改変をクライアント側で検知	改ざん検知・スクリプト監視	製品を導入

注意したいのは、ソフトウェアを導入すればその要件を自動的に満たせる、というわけではない点です。要件を満たしているかどうかは、組織の運用実態と、QSA（認定セキュリティ評価機関）による審査やSAQ（自己問診）を通じて評価されます。表はあくまで「対応に役立つ種類」の地図として使ってください。

もう1点、要件11.3.2の外部脆弱性スキャンは、PCI SSCが認定したASV（Approved Scanning Vendor）が実施する必要があります。一般の脆弱性診断サービスやペネトレーションテストは、ASVの外部スキャンとは別物です。自社で契約する診断サービスがASVの外部スキャンに該当するかどうかは、ASV認定の有無で確認してください。

この表は、ソフトウェアで対応しやすい代表的な要件に絞っています。要件2（安全な設定）・要件9（物理的アクセス）・要件12（ポリシー）など、運用や体制の整備が中心でソフトウェア製品だけでは完結しない要件は別途の対応が必要です。

自社で開発・運用するソフトウェアがPCI DSSで満たすべき要件（要件6・11）

ここからは、カードデータを扱うアプリケーションを自社で開発・運用している場合に関わる要件6・11を、v4.0.1の採番で見ていきます。各要件のなかで、v4.0で新設・変更された点も合わせて示します。

要件6.2.4：セキュアコーディング（SAST・静的解析が対応に役立つ）

要件6.2.4は、自社開発ソフトウェアで一般的なソフトウェア攻撃と関連する脆弱性を防止・軽減するために、ソフトウェアエンジニアリングの手法を開発者が定義し、実際に用いていることを求めます。インジェクション攻撃やアクセス制御の不備など、コードの書き方に起因する弱点を作り込まないための取り組みです。

この要件の対応に役立つのがSAST（静的解析）で、ソースコードを解析して脆弱性につながる書き方を早い段階で見つけます。ただしツールの導入だけで要件を満たすわけではなく、安全なコーディングの手法を定義して開発プロセスに組み込んでいることが前提になります。

要件6.3.2：ソフトウェアコンポーネント目録（SBOM）

要件6.3.2は、v4.0で新設された要件です。自社開発ソフトウェアと、そこに組み込んだ第三者製のソフトウェアコンポーネントの目録（インベントリ）を維持し、脆弱性管理とパッチ管理を行いやすくすることを求めます。使っている部品を把握していないと、公表された脆弱性に素早く対応できないためです。

目録の作り方としてSBOM（ソフトウェア部品表）がよく挙げられますが、PCI DSSが特定のフォーマットを義務づけているわけではありません。SBOMは目録を維持するための現実的な手段のひとつという位置づけです。この目録を自動で作り、部品の脆弱性を追えるようにするのがSCA（ソフトウェア構成分析）です。要件6.3.2も未来日付要件として2025年3月31日に発効済みで、現在は対応が必要です。

要件6.4.2・6.4.3：公開Webアプリの保護とスクリプト管理

一般公開しているWebアプリケーションの保護については、v4.0で内容が変わりました。従来の要件6.4.1は「定期的な手動・自動のレビュー、またはWAFの設置」のどちらかを認める形でしたが、この6.4.1は2025年3月31日をもって終了しています。

現行の要件6.4.2では、公開Webアプリケーションに対し、Webベースの攻撃を継続的に検知・防止する自動化された技術的ソリューションを設置することが求められます。これは実質的にWAFのような仕組みを指します。

あわせて要件6.4.3では、決済ページで読み込まれ実行される各スクリプトを認可・管理することが求められます。これと対になる要件11.6.1では、決済ページの不正な改変をクライアント側で検知する仕組みが求められます。いずれも2025年3月31日に発効済みです。

要件11.3・11.4：脆弱性スキャンとペネトレーションテスト

要件11では、システムが攻撃に耐えられるかを定期的にテストすることが求められます。v4.0.1の採番では、脆弱性スキャンが11.3、ペネトレーションテストが11.4に整理されています（ペネトレーションテストはv3.2.1までの11.3からv4.0で11.4へ移りました）。

脆弱性スキャンは、内部スキャン（要件11.3.1）と外部スキャン（要件11.3.2）に分かれ、いずれも少なくとも四半期ごとと重要な変更後の実施が求められます。このうち外部スキャンは、前述のとおりPCI SSC認定のASVが実施しなければなりません。内部スキャンにはASV認定は不要です。ペネトレーションテスト（要件11.4）は、外部・内部の両方について、業界で認められた手法にもとづいて実施します。

この外部スキャンを担うASV（認定スキャンベンダー）とは具体的に何か、四半期ごとの実施やエビデンスの残し方、通常の脆弱性診断・ペネトレーションテストとの違い、認定業者の探し方は、以下の記事で詳しく解説しています。

SSF（ソフトウェアセキュリティフレームワーク）とPA-DSSの廃止

決済アプリケーションそのものの安全性については、PCI DSSとは別のトラックの基準があります。かつて決済アプリケーション向けに使われていたPA-DSS（Payment Application Data Security Standard）は、2022年10月28日に廃止されました。

後継として、PCI SSCのソフトウェアセキュリティフレームワーク（SSF）を構成する「PCI Secure Software Standard」と「PCI Secure Software Lifecycle（Secure SLC）Standard」の2つの基準に置き換わっています。

これは、決済ソフトウェアを検証して販売・掲載する側の事業者に関わる基準です。カード会員データを扱う一般の事業会社が自社利用のアプリを開発する場合は、まずPCI DSSの要件6・11に対応することになり、SSFは直接の対象になりにくい領域です。自社開発したアプリケーションを他社に販売・提供する立場になるかどうかで、関係する基準が変わると整理しておくと混乱を避けられます。

出典・参考資料（3件）

• 参考資料：PCI DSS｜PCI Security Standards Council（https://www.pcisecuritystandards.org/standards/pci-dss/）
• 出典：PA-DSS（Retired on 28 October 2022）｜PCI Security Standards Council（https://www.pcisecuritystandards.org/standards/pa-dss/）
• 参考資料：Farewell to PA-DSS: A Tribute to a Foundational Standard｜PCI SSC Blog（https://blog.pcisecuritystandards.org/farewell-to-pa-dss-a-tribute-to-a-foundational-standard）

PCI DSS準拠を助けるソフトウェアの種類と、自社で検査を回す手段

ここからは、準拠を助けるソフトウェアを種類別に整理し、自社で検査を回すための手段と、どの進め方が自社に向くかを見ていきます。

準拠を助けるソフトウェアの種類

各種類が対応する要件は前述の対応表のとおりです。ここでは、同じ種類の中から製品を選ぶときに見る観点を示します。

• WAF：クラウド型かアプライアンス型か、シグネチャの更新やチューニングを自社で行うか、マネージド運用が付くかで選びます
• ログ監視・SIEM：監視するログの範囲と保存期間、アラートの運用負荷を自社でさばけるかで選びます
• ID・アクセス管理（IAM）／多要素認証：既存の認証基盤やクラウドとの連携、対応する認証方式で選びます
• 改ざん検知・スクリプト監視：決済ページのスクリプト検知に対応するか、検知後の通知・ブロックの仕組みで選びます

これらは本記事で詳しく紹介する診断系のサービスとは別の製品カテゴリにあたり、WAFやログ監視といった個別の領域はMCB FinTechカタログで課題別に探せます。

自社で検査を回す手段

自社開発ソフトの要件6・11に対応するには、開発・運用のなかで検査を回す手段が必要です。対応する要件は対応表のとおりで、ここでは手段を選ぶときの観点を添えます。

• SAST（静的解析）：対応するプログラミング言語、CI/CDへの組み込みやすさ、誤検知の少なさで選びます（要件6.2.4）
• SCA（ソフトウェア構成分析）／SBOM作成：対応するパッケージ管理・レジストリ、ライセンス管理まで見るかで選びます（要件6.3.2）
• Webアプリ・API診断（DAST）：ログイン後のページやAPIの認証に対応するか、スキャンの深さで選びます（稼働中アプリの検証＝要件11の対応に役立つ）
• 脆弱性スキャン・ペネトレーションテスト：対象範囲（内部／外部）と、外部スキャンはASV認定の有無で選びます（要件11.3・11.4）

SAST・SCA・DASTは、ツールとして開発工程に組み込み、自社で継続的に回せるのが利点です。一方、ペネトレーションテストや専門性の高い診断は、外部の診断サービスに委託することが多くなります。

製品導入・自社で作り込む・準拠クラウドの向き不向き

準拠に向けたソフトウェアの揃え方は、大きく3つの方向に分かれます。自社の体制や開発の有無によって向き不向きがあります。

• 要件ごとに製品を導入する：WAF・ログ監視・診断ツールなどを個別に揃えます。必要な要件に合わせて柔軟に組めますが、ツールが増えると運用と管理の手間がかかります
• 自社の開発プロセスに検査を作り込む：SAST・SCA・DASTをCIに組み込み、開発のなかで継続的に回します。自社開発が中心の企業に向きますが、体制づくりに時間がかかります
• PCI DSS準拠を支援するクラウド基盤に乗る：PCI DSS準拠をうたう決済基盤やマネージドホスティングなど、準拠を前提に設計された基盤を利用し、インフラ側の対応負担を抑えます。自社でインフラを持ちたくない場合に向きますが、アプリ側の要件6・11は引き続き自社の対応範囲として残ります

費用・進め方の目安と、どこから支援・診断に頼るか

最後に、費用の目安と進め方の考え方を整理します。ソフトウェアを入れれば準拠が完了するわけではなく、審査や継続的な運用まで含めて進めるものだという前提を押さえておくと、計画が立てやすくなります。

自社で回すツール型の脆弱性診断SaaSは、月額のサブスクリプションで提供されることが多く、利用人数や対象リポジトリ数などでライセンス規模が決まります。一方、専門家による受託型の診断は、1回あたりの料金で提示されることが一般的です。

たとえば受託型のソースコード診断は15万円程度から、Web・API診断を含むプランは50万円程度からといった水準が、サービスによって示されています（2026年11月時点。詳細は後述のサービス紹介を参照）。

ここで挙げた金額は診断系サービスに絞った目安です。WAFやログ監視などの製品費、認定ASVによる外部スキャンの費用、QSAの審査費用は別に見込む必要があり、どの審査方式（訪問審査・スキャン・自己問診）が自社に該当するかで総額は変わります。

進め方としては、SAST・SCA・DASTのように開発工程に組み込めるものは自社で回し、専門性の高いペネトレーションテストや、認定が必要なASVの外部スキャンは外部に委託する、という線引きが現実的です。そのうえで、準拠の判定自体はQSAによる審査やSAQ（自己問診）で行われるため、どの審査方式が自社に該当するかの確認も早い段階で進めておくとよいでしょう。

そもそも自社がPCI DSSの対象なのか、どのレベルでどの検証手段（訪問審査・スキャン・自己問診）が必要か、準拠までの手順や費用感の全体像から押さえたい場合は、以下の記事で解説しています。

PCI DSS対応のソフトウェア診断を始められるサービス

ここでは、自社で検査を回す手段のうち、要件6（セキュアコーディング・コンポーネント管理）や要件11（Web・API診断・ペネトレーションテスト）の対応に役立つサービスを紹介します。開発工程に組み込むツール型と、専門家による受託型の代表を取り上げます。

1. Aikido Security（株式会社AndGo）

Aikido Securityは、ソースコードの診断（SAST）、依存ライブラリの分析（SCA）、クラウド設定のチェック（CSPM）、稼働中のWebアプリ診断（DAST）などを1つの管理画面でまとめて扱えるオールインワンの脆弱性診断SaaSです。開発元はベルギーのAikido Security BVで、日本では株式会社AndGoが販売・問い合わせの窓口を担います。

PCI DSSのソフトウェア要件との関係では、SASTが要件6.2.4のセキュアコーディング、SCAやSBOM作成が要件6.3.2のコンポーネント目録の対応に役立ちます。

単機能のツールを個別に足していくとアラートが分散しがちですが、本サービスは検知結果を統一して対応すべきものを絞り込み、修正案をプルリクエストとして自動作成する機能も備えます。開発の初期からセキュリティを組み込むDevSecOpsの進め方に向いています。

料金は月額のサブスクリプション型で、利用するエンジニアのスロット数などでライセンス規模が決まります。日本窓口のAndGoでは年額3,780ドルからのBasicプランが案内されており、月額5万円台からとされています（年間契約・利用者10人までの参考価格。2026年11月時点）。

正式な見積りはAndGoへの確認が必要です。また、人手によるペネトレーションテストは、AndGoの別サービスとして案内されています。

開発工程にセキュリティを組み込むという考え方について、株式会社AndGoの原氏は取材で次のように述べています。

2. CoWorker 脆弱性診断サービス（CoWorker株式会社）

CoWorker株式会社が提供するのは、自社開発AI「Red Agent」による自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた受託型の脆弱性診断サービスです。診断メニューは、ソースコードAI診断、動的脆弱性診断（Web・API診断）、実践攻撃シミュレーション診断（ペネトレーションテスト）の3つで構成されます。

ソースコードや設計書を対象にしたAI診断は要件6の開発面に、Web・API診断やペネトレーションテストは要件11.4のテスト面に役立つ内容です。AIによる自動解析で診断にかかる時間を抑えつつ、専門家がレポートを仕上げる二段構成が特徴で、プレスリリースでは最短3営業日での報告書納品がうたわれています。

料金は、MCB FinTechカタログの掲載情報ではソースコードAI診断が15万円、ソースコードと動的診断を含むLiteプランが50万円からとされています（2026年11月時点。公式サイトには通常50万円からの記載があり、プラン別の料金は掲載情報にもとづきます）。

受託型のため、外部に診断を委託したい場合の選択肢になります。ただし、要件11.3.2の外部スキャンはASV認定が前提となるため、ASVスキャンが必要な場合は認定の有無を確認してください。

脆弱性診断を行う頻度の変化について、CoWorker株式会社の一ノ瀬氏は取材で次のように述べています。

ここで紹介したサービス以外にも、脆弱性診断サービスは数多くあります。診断方法や費用相場、選び方を横断的に比較して自社に合うものを探したい方は、以下の記事で詳しく解説しています。

まとめ

「PCI DSS ソフトウェア」を考えるときは、まず準拠を助ける製品を探しているのか、自社開発ソフトの要件を知りたいのかを切り分けるのが近道です。

製品側はWAF・ログ監視・アクセス管理などを要件に合わせて組み合わせ、自社開発ソフト側は要件6・11（6.2.4のセキュアコーディング、6.3.2のコンポーネント目録、6.4.2の公開Webアプリ保護、11.3の脆弱性スキャン、11.4のペネトレーションテスト）に対応していきます。

要件番号はv4.0.1の採番で確認し、v4.0で新設・変更された要件が2025年3月31日に発効済みである点を押さえておきましょう。ソフトウェアの導入は準拠の出発点で、最終的な判定はQSAの審査やSAQで行われます。

自社で回せる検査はツールで、専門性の高い診断は受託サービスで、という線引きを早めに決めて、自社に必要なソフトウェアの検討を進めてください。

よくある質問（FAQ）

Q. PCI DSS ソフトウェアとは何ですか？

A. PCI DSS ソフトウェアとは、PCI DSSの準拠を助けるソフトウェア製品と、自社が開発・運用するソフトウェアがPCI DSSで満たすべき要件という、2つの意味で使われる言葉です。

前者はWAF・ログ監視・脆弱性診断といった製品を指し、後者は要件6・11で求められるセキュアコーディングや脆弱性スキャンなどを指します。自社がどちらを探しているのかを切り分けると、必要なソフトウェアの範囲が絞り込めます。

Q. PCI コンプライアンスソフトウェアとは何ですか？

A. PCI コンプライアンスソフトウェアとは、PCI DSSの個別の要件への対応を支援するソフトウェア製品の総称です。カード会員データの所在やアクセス権の可視化、ログ監視、アクセス管理、脆弱性診断など、どの要件を助けるかで役割が分かれます。1つの製品で12要件すべてをまかなえるものではないため、自社に不足している要件に合わせて組み合わせるのが基本です。

Q. PCI DSS準拠はソフトウェアを導入するだけで満たせますか？

A. PCI DSS準拠は、ソフトウェアを導入するだけでは満たせません。ソフトウェアは要件への対応を助ける手段であり、要件を満たしているかどうかは、組織の運用実態と、QSA（認定セキュリティ評価機関）による審査やSAQ（自己問診）を通じて評価されます。ツールの導入は準拠の出発点と位置づけ、運用と審査まで含めて計画を立てるのが現実的です。

Q. PCI DSSの要件6.3.2でSBOMの作成は必須ですか？

A. PCI DSSの要件6.3.2はソフトウェアコンポーネントの目録を維持することを求めていますが、SBOM（ソフトウェア部品表）という特定のフォーマットを義務づけているわけではありません。SBOMは目録を維持するための現実的な手段のひとつという位置づけです。要件6.3.2はv4.0で新設され、2025年3月31日に発効済みのため、目録の維持そのものは現在必要な対応です。

Q. ASVスキャンと一般の脆弱性診断は何が違いますか？

A. ASVスキャンは、PCI DSS要件11.3.2の外部脆弱性スキャンとして、PCI SSCが認定したASV（Approved Scanning Vendor）だけが実施できる点が、一般の脆弱性診断と異なります。

一般の脆弱性診断サービスやペネトレーションテストは、ASVによる外部スキャンの代わりにはなりません。自社が契約する診断サービスが外部スキャン要件に該当するかどうかは、ASV認定の有無で確認してください。

Q. PCI DSS v4.0でソフトウェア開発に関する要件は何が変わりましたか？

A. v4.0では、ソフトウェアコンポーネントの目録を求める要件6.3.2の新設、公開Webアプリ保護の「レビューまたはWAF」から自動化された技術的対策（要件6.4.2）への変更、決済ページのスクリプト管理（要件6.4.3）の追加などが行われました。

これらを含むv4.0の新規要件は未来日付要件として段階的に適用され、2025年3月31日に発効済みです。要件番号はv4.0の採番を引き継いだv4.0.1で確認します。

Q. 自社でアプリを開発していなくてもPCI DSSのソフトウェア要件への対応は必要ですか？

A. カード会員データを扱うアプリを自社で開発していない場合でも、要件に対応する製品を検討する立場にはありますが、自社開発ソフトに課される要件6・11の比重は小さくなります。決済を外部の決済代行サービスに任せ、自社でアプリを作っていない場合などが該当します。一方、ECサイトや決済系SaaSを内製している企業は、製品側と自社開発ソフト側の両方にまたがると考えて準備を進めるのが現実的です。

Q. PCI DSSのソフトウェア対応は自社ツールと外部委託のどちらで進めるべきですか？

A. SAST・SCA・DASTのように開発工程に組み込めるものは自社ツールで継続的に回し、専門性の高いペネトレーションテストや、認定が必要なASVの外部スキャンは外部に委託する、という線引きが現実的です。

自社開発が中心の企業ほど検査を開発プロセスに作り込む価値が高く、インフラ側の対応負担を抑えたい場合は、PCI DSS準拠を支援するクラウド基盤に乗る選択肢もあります。ただしクラウド基盤を使っても、アプリ側の要件6・11は自社の対応範囲として残ります。

脆弱性診断・セキュリティ診断サービスの料金・資料を一括チェック

MCB FinTechカタログでは、PCI DSS対応に役立つ脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。対応する診断範囲や料金、支援の形を見比べて、自社に合うサービスを選べます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。