PCI標準のオープンソースセキュリティ要件 — 準拠するには？

現代のソフトウェア開発でオープンソースセキュリティの利用が広がる中、オープンソースを安全に利用することが急務となっています。しかし、オープンソースセキュリティはまだ広く実践されていません。Snykが実施した最近の調査によると、オープンソース開発者の37%は、継続的インテグレーション（CI）プロセスで何らかのセキュリティテストも実施していません。オープンソースの利用が拡大する一方で、セキュリティ標準の整備が追いついていないことから、多くの規制当局や業界監視機関が、オープンソースコードを含むアプリケーションの保護方法について、より厳格で明確なルールを設ける方向に動いています。

PCIがオープンソースの取り組みを推進

2019年1月、Payment Card Industry Security Standards Councilは、アプリケーションセキュリティに焦点を当てたPCI Software Security Framework（SSF）を発表しました。また、PCI Software Security Frameworkの一部としてSecure Software Lifecycle（SLC）Standardも追加されました。この標準は、ソフトウェアベンダーがソフトウェアのライフサイクル全体を通じて決済ソフトウェアのセキュリティをどのように管理しているかを検証できるよう、セキュリティ要件と評価手順を定めています。

（注：新しいフレームワークは、PCI Payment Application Data Security Standard［PCI PA-DSS］に含まれる現行ガイドラインに取って代わるもので、現行ガイドラインは今後数年以内に廃止される予定です。）

Snykは、コード内のオープンソースコンポーネントを保護する重要性をPCIが認め、ソフトウェア開発ライフサイクルのセキュリティに対する責任を積極的に「シフトレフト」するよう組織に促していることを歓迎します。ソフトウェアライフサイクルの早い段階から、特にオープンソースに関するセキュリティのベストプラクティスを取り入れるほど、アプリケーションの安全性は高まります。

とはいえ、他の多くのコンプライアンスフレームワークと同様に、新しいルールを理解し、実践するのは簡単ではありません。そこで、新しいPCIコンプライアンスルールについて解説し、更新された標準のうちオープンソースに関連する要件への具体的な準拠方法をご紹介します。

PCIの更新に対応すべきなのは？

PCI Secure Software Standard（およびその基盤となるSLC Standard）は、決済取引を行う目的で第三者に販売、配布、またはライセンス供与される決済ソフトウェアに適用されます。特にPCI Software Security Frameworkは、決済処理アプリケーションを開発するベンダーや、それらのソリューションを他社に販売するベンダーに関係します。今回の更新では、コンプライアンス基準を満たす責任を、セキュリティ部門のリーダーとエンジニアリングチームの双方が負うことが明確にされています。

PCI-DSSガイドラインの下では、決済を受け付ける企業が対応すべきルールもほかにありますが、この記事で取り上げる標準は、ソフトウェアの開発者に直接関係するものです。

一度きりでは不十分：継続性が鍵

新しい標準でおそらく最も重要なのは、「継続的なアプリケーションセキュリティ」という考え方です。この標準では、組織に対して脆弱性と防御策を継続的に監視し、脅威の変化に応じて対応することを求めています。さらに、アプリケーションのセキュリティ制御を継続的にテストし、時間の経過によって制御が弱まったり、効果を失ったりしていないことを証明する必要があります。これは高いハードルですが、それは望ましいことです。セキュリティを後回しにせず、CI/CDプロセスの一部として扱うことを促します。

PCIの更新の背景とは？なぜ今なのか？

では、なぜこれらの標準が更新されたのでしょうか。冒頭で触れたように、ソフトウェア開発は年月とともに進化してきました。今回のPCI標準の更新はその進化を踏まえたものであり、それに応じてソフトウェアセキュリティのアプローチも見直されています。特に、オープンソースコンポーネントに依存するソフトウェア開発手法が増えていることから、オープンソースに適用される要件と管理策を追加する必要がありました。『State of Open Source Security 2019 Report』では、この分野に関する統計を紹介しました。注目すべきデータをいくつかご紹介します。

• アプリケーションライブラリの脆弱性は2年間で88%増加しました。回答者の81%は開発者がセキュリティに責任を持つべきだと考えていますが、必要なスキルや体制が整っていません。オープンソースのメンテナーは安全性の確保を望んでいるものの、70%は必要なスキルを持っていません。

オープンソース開発が広がる一方で、多くの組織がDevOpsパイプラインにセキュリティツールを統合するようになり、こうしたツールもよりプロアクティブで効果的になってきました。そのため、堅牢なセキュリティを継続的な開発とインテグレーションのサイクルに組み込むことは、必要であると同時に（朗報として）これまで以上に実現しやすくなっています。

PCIの新しい更新におけるオープンソースの役割

新しいPCIルールのうち、オープンソースソフトウェアコンポーネントに適用される内容を詳しく見ていきましょう。（標準の全文はこちらからご覧いただけます。）

1. セキュリティリーダーの説明責任

条文：第1.1項 -- ベンダーの製品およびサービスのセキュリティ確保に関する説明責任は、ベンダーの上級管理職によって個人またはチームに正式に割り当てられる。

組織にとっての意味：大規模組織のセキュリティリーダーは、セキュリティに対する責任を引き受け、更新されたPCI要件を満たせるよう、開発プロセスとツールに適切な変更を加える必要があります。

Snykができること：セキュリティリーダーには、すでに多くの優先課題があります。Snykは、オープンソースの依存関係とライセンスのリスクを可視化することで、新しいPCI標準への準拠を効率化し、適切なタイミングで適切な対処ができるよう支援します。

2. 開発者の役割

条文：第1.2.a項 -- ベンダーの製品およびサービスの設計、開発、テスト、保守に携わる個人（第三者の人員を含む）には、ソフトウェアがセキュリティ戦略および該当するすべてのセキュリティ要件に沿って設計・保守されるようにする責任と説明責任を割り当てるものとする。

組織にとっての意味：新しい要件では、コンプライアンスを満たすために定められた手順に開発者（「ソフトウェア開発担当者」）が関与し、責任を担うことが明確に求められています。

Snykができること：Snykの開発者ファーストのセキュリティアプローチは、開発者がセキュリティのベストプラクティスを簡単に取り入れられるよう支援します。Snykを使えば、開発者は既存のソフトウェア開発プロセスの一環として脆弱性を発見し、修正できます。また、Git上でワンクリックの修正PRや修正の自動化を実現し、発見された脆弱性にすばやく対処できるようにします。

3. オープンソースコンポーネント

条文：第3.2.b項 -- ソフトウェアの一部としてオープンソースソフトウェアコンポーネントが使用されている場合、評価者はプロセス文書や評価結果を含むベンダーの証拠を調査し、これらのコンポーネントが管理されていることを確認するものとする。

組織にとっての意味：オープンソースはソフトウェア開発に大きなメリットをもたらしますが、アプリケーションにオープンソースコンポーネントを組み込む前に、十分な調査と確認を行う必要があります。組織は次のことを実施すべきです。

• コンテナイメージを含め、使用中のすべてのオープンソースコンポーネントの一覧を管理する

• 脆弱性を分析・緩和する成熟したプロセスを構築する

• オープンソースコンポーネントの脆弱性を監視する

• パッチ適用戦略を導入する

Snykができること：Snykを使えば、アプリケーションの依存関係を可視化し、現在の脆弱性を特定するとともに、包括的な脆弱性データベースをもとに新たな脆弱性を継続的に検査できます。自動修正プルリクエストによってトリアージと修正を迅速化する、包括的なパッチ適用・修正機能も備えています。つまり、Snykは3.2.bへの準拠プロセスを自動化し、手作業を減らしてコンプライアンス対応にかかる時間を短縮します。Snykを活用することで、チームはオープンソースコンポーネントの潜在的な脆弱性に対し、チェックポイント、修復、監視を実施していることを示せます。

PCIコンプライアンスを「シフトレフト」の推進力に

組織がセキュリティのシフトレフトを進めるにつれ、新たな課題と機会が生まれます。PCIコンプライアンス要件の更新は、今日のソフトウェア開発プロセスの実態とオープンソースの普及を考えれば妥当なものです。最初は要件が厳しく感じられるかもしれませんが、対応することで組織のセキュリティを強化し、全体的なリスクを低減できます。コンプライアンスの価値にとどまらず、取り組む価値は十分にあります。

新しいPCI標準への対応で多くの組織が直面する最大の課題は、これまで導入していなかったオープンソース専用のセキュリティツールを初めて導入することです。オープンソースセキュリティのベストプラクティスをCI/CDパイプラインに組み込めば、開発プロセスの自然な一部となります。最後になって負担になったり、新たな脆弱性が公表されてから慌てて対応したりする必要がなくなります。

Snykで新しいオープンソースに関するPCIコンプライアンス標準に簡単に準拠する方法をご覧ください。開発者は今すぐ無料でSnykを使い始められます。