在你决定用源代码审查或者Web应用程序防火墙来满足PCI DSS规则遵从的需求时，我建议你抽点时间，全面了解一下PCI的Web应用程序要求，包括澄清文档（clarification documents），并考虑这两种选择应该如何同你的架构和资源结合起来。目前，企业有多种途径进行规则遵从，如果执行恰当的话，任何一种选择都可以帮助企业达到规则遵从要求，而且能够提高Web应用程序的安全性。
当然，在应用程序安全方面并不存在万全之策。除非你很幸运，既能进行代码审查又能运行WAF，不过这样做依然需要人工去完成。企业是否有员工可以完成以下工作：
配置和维护应用层防火墙？
进行代码审查？
使用第三方漏洞监测工具，并处理在审查中所发现的问题？
当然，这个决定还要考虑架构，以及WAF与现有系统及设备的兼容性如何。其中一个需要考虑的因素（尤其是对那些倾向于使用第三方代码审查的企业而言）是企业对其代码状态的满意度如何。随着时间的推移，支付卡应用程序的开发可能会包含来历不明以及目的不明确的遗留代码。安全人员可能不想冒破坏任务优先应用程序的风险而删除这些遗留代码。在应用程序前面放置一个防火墙可能会比在代码审查中重写程序成本要低，或者破坏性要小。
另一种方法是用威胁模型（threat modeling）来识别和评估应用程序的风险。我们以三大关键风险为例，并确定哪些方法能***地处理它们：代码审查、漏洞评估、WAF产品。但是请注意，部署WAF并不能减少你的安全软件开发过程需求（要求6.3）！而应用程序漏洞评估和代码审查却都能加强开发和质量保证周期。
对于小型商业网站来说，上述选择过于昂贵。所以，我建议把支付任务外包给第三方支付服务供应商，不必担心所有昂贵的安全要求，包括Web安全、以及实际的PCI DSS遵从等。只要你不处理任何卡支付，你就不需要遵从PCI DSS标准。
规则遵从与安全的权衡
不管你选择什么方式，许多人都会争论PCI遵从是否同可接受的安全水平一致。负责安全的人员需要了解上述每种选择的局限性和能力。源代码分析本身可以进行规则遵从，但它不是保障应用程序安全的好办法。事实上，没有一种方法能完全保证所有的要求。PCI DSS侧重于与PCI相关的支付卡应用程序和组件，但它并不是以整体方式查看企业及其全部网络操作，而需要在整个企业中全面部署安全措施。
即使有了PCI要求6.6信息补充的澄清说明，许多商户还是不确定哪些行动能够很好地进行规则遵从。这就导致了典型的规则遵从困境（compliance dilemma）。如果你要公布一个可以增加安全性的标准，你就必须回答这个问题：“我必须做哪些工作来满足这个标准？”而该问题又会迅速演变为：“满足标准的最小工作量是多少？”如果你只是以“选中复选框并继续”的观点来看待PCI规则遵从的话，那么WAF将是快速、简单的选择。
然而，PCI DSS的确给企业提供了创建安全架构和业务模型的基础。它还让企业高层关注安全问题。如果你关心安全，那么遵从PCI要求只是顺理成章的事情。在你的开发人员能够安全编程之前，多层次的安全方案将永远是减轻风险的***方法，因为在这种情况下，安全方案包括了代码审查、漏洞评估和WAF产品。一旦漏洞扫描的结果整合到WAF的配置中，WAF将更加有效。这样做将会为程序提供保护，同时对源代码进行分析和修正，以消除漏洞。
在PCI审查之后，漏洞还会不会暴露出来？当然会，但是不会那么多，也可能不会那么严重。降低成本和商业因素可能导致低水平的评估和保护，但在真实的商业世界中，安全必须引起人们的重视。
【编辑推荐】
