PCI 安全标准委员会指南改版：是否实现了足够的“左移”？

本文的一个版本最初发表于《数字交易杂志》。

今年，PCI安全标准委员会发布了一套全新的软件安全指南，作为其PCI软件安全框架的一部分。此次更新旨在使软件安全最佳实践与现代软件开发保持同步。这是一项了不起的举措，它承认了这一流程随时间发生的变化，并要求重新审视那些在我们大多数生活迅速数字化之前就已制定的安全标准。

这清楚地表明，我们的行业正在更紧密地拥抱适应性指南的理念——即能够随我们不断变化的需求而演进的指南——同时也应对了网络安全环境的需求，如果我们继续在安全开发流程中掉以轻心，这种环境可能会迅速失控。当然，由于PCI安全标准委员会在银行和金融行业中扮演着管理机构的角色（即为我们信任的用于保护资金、信用卡、在线交易和销售点系统的软件设定安全标准），他们承担着巨大的风险，也有着极大的动力去降低这些风险。

虽然这些标准确实比之前的版本有所改进，并在一定程度上填补了我们在快速、创新功能开发中兼顾安全质量评估的空白，但令人有些失望的是，我们仍有很长的路要走。

不，我并不是在对这一举措表示“反对”。事实是，这些新的安全指南并没有让我们在“左移”的道路上走得足够远。

我们仍然执着于测试（而且测试得太晚了）。

我在PCI安全标准框架中发现的一个明显问题是它对测试的过度依赖。当然，软件仍然必须经过测试（SAST/DAST/IAST流程依然有其地位），但我们仍在重蹈覆辙，却期待着不同的结果。

是谁写下一行行代码来创建我们所熟知、喜爱并信任的软件的？是软件开发人员。

是谁承担着测试这些代码的艰巨任务，无论是通过扫描工具还是人工代码审查？是应用安全专家。

这些专家不断发现什么？依然是困扰我们几十年的那些老问题。我们多年来就知道如何修复的简单问题：SQL注入、跨站脚本攻击、会话管理漏洞……对他们来说，这就像是陷入了《土拨鼠之日》的循环。他们把时间花在查找和修复开发人员本就有能力修复的代码违规上，只是因为安全在他们的流程中从未被优先考虑——尤其是在当今这个以功能交付为王的敏捷开发时代，安全反而成了扼杀创造性流程和项目圆满完成的“格林奇”。

这并非对任何一方的负面评价；开发人员和应用安全专业人员都有极其重要的工作要做，但他们却不断地相互掣肘。这种情况只会延续一个有缺陷的软件开发生命周期（SDLC）：缺乏安全意识的开发人员在消极的安全文化中工作，产出不安全的代码，然后这些代码必须在编写很久之后再进行扫描、评估和修复。应用安全团队几乎没有时间去处理真正复杂的问题，因为他们被那些如果放任不管就可能给公司带来灾难的琐碎重复问题缠住了。

我们通过让测试成为代码安全漏洞的“万能补丁”来浪费时间、金钱和资源。随着大规模数据泄露事件频发，这种方法显然无法达到最佳效果，甚至根本无效。这些新标准仍在评估最终产品状态（或许是假设所有开发人员都具备安全意识，但事实并非如此）：即已经构建完成的产品。这是修复缺陷最昂贵、最困难的阶段；这就像盖了一栋漂亮的新房子，却在搬进去的那天才请安全团队来检查隐患。如果地基有问题，想象一下要触及该区域并开始解决问题所需的时间、成本和巨大的头痛。通常，直接推倒重来更容易、更便宜（而且对于所有参与第一版构建的人来说，这是一个极其令人沮丧的过程）。

我们绝对必须从源头做起：让开发团队参与到安全最佳实践中来，赋予他们高效编写安全代码的知识，并在每个工作场所建立和维护积极的安全文化。

这有学习曲线吗？当然有。这不可能吗？绝对不是。而且这不必是一项枯燥的苦差事。如果Russ Wolfe在Capital One的经验可以作为参考的话，那些直接吸引开发人员创造力和解决问题特质的培训方法已经在银行和金融领域取得了巨大成功。

我们仍在寻找完美的“最终状态”。

如果你在预期的背景下看待更新后的PCI安全标准，即你的成品金融产品必须遵循这些最佳实践以实现最佳安全性和保障，那么它们绝对是没问题的。然而，在我看来，每一家公司——无论是金融公司还是其他公司——如果能退后一步，意识到从周期开始就进行这些工作效率要高得多，那么他们将更有机会达到既具备功能质量又具备高安全标准的软件最终状态。

那个完美的最终状态？你知道的，就是当产品经过扫描、人工审查后变得完美无瑕时出现的状态？我们仍在寻找它。目前来看，那只是一个传说。

为什么它如此难以捉摸？有几个因素：

• 扫描工具虽被广泛依赖，但并非总是有效。误报不仅令人沮丧且浪费时间，更关键的是，即便将 DAST、SAST 和 PCI 扫描结合使用，也无法识别并揭示代码库中所有潜在的漏洞。它们或许会显示一切正常，但它们真的面面俱到了吗？攻击者只需利用一个漏洞，就能突破你自认为严密的防线。
• 开发人员仍在重复犯同样的错误。团队内部缺乏安全知识的共享，也没有广为人知且记录在案的“安全代码范式”（即优质、安全的代码模式）。
• 企业并未重视构建协作且积极的安全文化。
• 我们需要为开发人员提供合适的工具，让他们在不干扰创作流程和敏捷开发方法的前提下，将安全融入产品开发之中。

这些指南为软件应遵循的安全标准提供了一份强有力的核查清单，但如何通过最佳流程使软件达到该标准，目前尚无定论。

软件不安全并非因为缺乏扫描工具，而是因为开发人员没有获得易于使用、易于理解且能提供指导的安全工具。

我们正处于一个变革时代。多年来，软件安全在很大程度上是可选的。而今天，它已成为基本要求——尤其是对于掌握敏感信息（如金融、医疗、社保等）的机构而言。

PCI 安全标准委员会正在助力树立行业标杆，但我衷心希望他们能凭借其行业声望与影响力，致力于制定更具实操性的开发人员指南，并重点强调有效的培训与工具支持。目前，企业在确保开发团队具备安全意识与合规性方面缺乏压力，许多开发人员也并未意识到，那些看似微小且易于修复的错误一旦被恶意利用，会造成多么严重的后果。

正如生活中任何有价值的事物一样，实现真正的变革需要集体的力量。而这股变革之风（希望）将推动我们所有人向左移。