ソースコードスキャン-PCI要件-サービスプロバイダー
私はソースコードスキャンの要件に関して多くの調査を行ってきましたが、以下の私の質問に関しては決定的なものは見つかりませんでした。 StackExchangeのInfo SecコミュニティのPCIエキスパートからのガイダンスが必要です。
HP Fortify SCAなどのツールを使用してソースコードをスキャンするために、社内でカスタムビルドされた支払いアプリケーション（PA DSSではない）を使用するサービスプロバイダーは必要ですか？または、彼らが持っているすべてのコードベースに対して手動でコードレビューを行うだけで準拠できますか？彼らが手動のコードレビューを行うことで逃げることができる場合、OWASPトップ10はどのようにプレイするのですか？
覚えておいてください。WAFはありません。
参照： https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf
安全なソフトウェア開発ライフサイクルを実現することは、PCI DSSの要件です。 要件6.3.2 状態：
6.3.2プロダクションまたは顧客にリリースする前にカスタムコードを確認して、潜在的なコーディングの脆弱性を特定し（手動または自動プロセスのいずれかを使用）、少なくとも以下を含めます。
- コードの変更は、元のコードの作成者以外の個人、およびコードレビューの手法と安全なコーディング方法に精通している個人によってレビューされます。
- コードレビューは、コードが安全なコーディングガイドラインに従って開発されていることを確認します
- リリース前に適切な修正が実装されています。
- コードレビューの結果は、リリース前に経営陣によってレビューおよび承認されます。
注：コードレビューのこの要件は、システム開発ライフサイクルの一部として、すべてのカスタムコード（内部向けと一般向けの両方）に適用されます。コードのレビューは、知識の豊富な社内担当者または第三者が実施できます。 PCI DSS要件6.6で定義されているように、公開されているWebアプリケーションも、実装後に進行中の脅威と脆弱性に対処するための追加の制御の対象となります。
および6.6には、WAF（ない）または次のいずれかが記載されています。
手動または自動化されたアプリケーション脆弱性セキュリティ評価ツールまたは方法を介して、少なくとも年に1回、および変更後に、公開されているWebアプリケーションをレビューする
6.6 内のオプションの1つは
要件6.6オプション1 –アプリケーションコードレビュー
...
- アプリケーションのソースコードの手動レビュー
したがって、両方の要件を満たすために、手動のコードレビューを実行できます。
OWASPトップ10はどのように機能しますか？
6.3.2に戻って、em me：
コードの変更は、元のコード作成者以外の個人、およびコードレビュー手法と安全なコーディングプラクティスに精通した個人によってレビューされます。
6.5これについて（em me）：
6.5次のように、ソフトウェア開発プロセスにおける一般的なコーディングの脆弱性に対処します。
一般的なコーディングの脆弱性を回避する方法や、機密データがメモリ内でどのように処理されるかを理解するなど、安全なコーディング手法について開発者をトレーニングします。
- 安全なコーディングガイドラインに基づいてアプリケーションを開発します。
注：6.5.1から6.5.10にリストされている脆弱性は、このバージョンのPCI DSSが公開されました。ただし、脆弱性管理に関する業界のベストプラクティスが更新されているため（たとえば、[〜＃〜] owasp [〜＃〜]ガイド、SANS CWEトップ） 25、CERTセキュアコーディングなど）、現在のベストプラクティスをこれらの要件に使用する必要があります。
したがって、OWASPなどの業界ガイドラインを念頭に置いて、コードレビューを実行する必要があります。彼らのPCIポリシーは、開発とコードのレビュー中にどのガイドラインに従うかを明記する必要があります。
標準の免責事項：私はQSAではなく、さらに重要なこととして、yourQSA
スキャンと手動のコードレビュー
カスタムビルドされた社内ソフトウェアは、PANデータを処理する場合、PCIコンプライアンスの範囲内です。 PCI DSS、要件6.6 は、社内向けの2つのオプションを表しますPANデータを処理するソフトウェアの開発者：コードレビューを行うか、Webアプリケーションファイアウォール（WAF）を実装できます。もちろん、コードレビューまたはWAFのオプションの性質を指定し、いずれかのオプションを使用する場合のコンプライアンスの最低基準。
したがって、コンプライアンスを達成するために、コードレビュールートを利用するか、Webアプリケーションファイアウォールルートを利用するかを選択できます。
コードレビュー
PCI DSSは、準拠コードレビューに4つのオプションが利用可能であると述べています：
- アプリケーションのソースコードの手動レビュー
- 自動化されたアプリケーションソースコードアナライザー（スキャン）ツールの適切な使用
- 手動のWebアプリケーションセキュリティ脆弱性評価
- 自動化されたWebアプリケーションのセキュリティ脆弱性評価（スキャン）ツールの適切な使用
したがって、 PCI DSSセクション6.6。 で特に言及されている要件をカバーする限り、（あなたが説明する）「手動」レビュープロセスで十分です、特に資格のある人によって行われ、SDLCに組み込まれていること。
もちろん、自動化ツールを使用することもできます。そのツールも要件を満たすように機能する限り。多くの組織は、自動レビューと手動レビューの両方を組み合わせて使用することを選択します。これにより、コンプライアンスに十分満足するだけでなく、より現実的なセキュリティが提供されます。
OWASPトップ10
OWASPトップ10についての言及は、2番目のオプションであるアプリケーションレベルのファイアウォールを対象としています。 PCI DSSは、Webアプリケーションファイアウォールが準拠していると見なされるための要件の1つとして、次のことを行う必要があると述べています。
OWASPトップ10および/またはPCI DSS要件6.5で識別された、関連する脆弱性に対する脅威に適切に（アクティブなポリシーまたはルールによって定義されて）対応します。
「オプション1」のコードレビュールートを実行している場合は、コンプライアンスを維持するためにWAF資料を気にする必要はありません。
ただし、多くの組織は、「オプション1」のコードレビューとWebアプリケーションファイアウォールの両方を使用することを選択します。これにより、組織のセキュリティが大幅に向上します。したがって、オプションは相互に排他的ではありません。現時点では、1つのオプションを選択するだけで、コンプライアンスを達成できます。
準拠は常に安全であるとは限りません
「準拠」が「安全」であるために十分であるかどうか、およびソフトウェアの侵害のリスクは何か、そしてそれを適切に保護するためにどれだけのリソースを投資する必要があるかを判断するのは、あなた次第です。