修订后的PCI安全标准委员会指南：它们向左移动得足够远吗？

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

今年，PCI安全标准委员会发布了一套全新的 软件安全指南 作为他们的 PCI 软件安全框架的一部分。此更新旨在使软件安全最佳实践与现代软件开发保持一致。这是一项了不起的举措，它承认了这一过程随着时间的推移发生了怎样的变化，需要重新考虑早在我们生活的大部分时间迅速数字化之前就制定的安全标准。

这清楚地表明，我们的行业更加密切地关注适应性指导方针（这些指导方针会随着我们不断变化的需求而变化）的理念，以及网络安全格局的需求，如果我们在安全开发流程中继续松懈，网络安全格局可能会很快失控。当然，由于PCI安全标准委员会充当银行和金融行业的管理机构（例如为我们信任的软件设定安全标准，以保护我们所有的资金、信用卡、在线交易和销售点），它们承担着很大的风险，并且有很大的降低风险的动力。

尽管这些标准肯定在先前版本的基础上有所改进，并在一定程度上填补了我们在快速创新功能开发方面存在的漏洞，该开发还将安全作为整体质量评估的一部分，但发现我们还有很长的路要走，这有点令人失望。

不，那不是我在说 “嘘，骗子！”加入这项倡议。事实是，这些新的安全准则根本无法将我们向左移得足够远。

我们仍然专注于测试（测试为时已晚）。

我在PCI安全标准框架中发现的一个明显问题是它明显依赖测试。当然，仍然必须对软件进行测试（SAST/DAST/IAST流程仍然有其用武之地），但是我们仍然陷入了同样的陷阱，并期望得到不同的结果。

谁在后面写一行 一行代码 来创建我们熟悉、喜爱和信任的软件？软件开发人员。

无论是使用扫描工具还是手动代码审查，谁在测试这些代码方面处于不让人羡慕的地位？AppSec 专家。

这些专家继续发现什么？困扰我们数十年的同样的错误。我们多年来一直知道如何修复的简单问题： SQL 注入， 跨站点脚本， 会话管理的弱点... 对于这些家伙来说，这就像土拨鼠日。他们花时间寻找和修复开发人员自己多年来一直有权修复的代码违规行为，唯一的不同是安全性在他们的流程中没有被列为优先事项”，尤其是在现在，在敏捷开发时代，功能交付为王，安全是窃取创作过程和项目完成胜利的格林奇。

这不是对任何一个团队的负面评估；开发人员和AppSec专业人员都有极其重要的工作要做，但他们继续互相妨碍。这种情况只会延续存在缺陷的 SDLC，即几乎没有安全意识的开发人员在负面的安全文化中运作，生成不安全的代码，然后必须在最初编写之后很长一段时间内对其进行扫描、评估和修复。AppSec几乎没有时间修复真正复杂的问题，因为他们被反复出现的小问题所困扰，如果不加以控制，这些问题仍然可能给公司带来灾难。

我们允许测试成为代码中安全漏洞的万能工具，从而浪费时间、金钱和资源。而且，由于每隔一天就会有大量数据泄露，这种方法显然无法发挥最佳效果。这些新标准仍在评估最终产品状态（可能假设所有开发人员都具有安全意识，但事实并非如此）：就像已经建成的标准一样。这是修复缺陷最昂贵和最困难的阶段；这就像建造一栋漂亮的新房子，但是在你入住的同一天才派出一个安全小组来检查是否有任何危险。如果基金会出了问题，想象一下进入该领域开始解决问题所需要的时间、成本和令人头疼的程度。简单地重新开始通常更容易、更便宜（对于每个构建第一个版本的人来说，这是一个完全不令人满意的过程）。

我们绝对必须从头开始工作：通过让开发团队参与安全最佳实践，为他们提供高效安全编码的知识，此外还要创建和维护积极的安全文化 每个 工作场所。

这是学习曲线吗？见鬼，确实如此。这是不可能的吗？绝对不是。而且这不一定是无聊的苦差事。如果说，直接吸引开发人员创造性、解决问题能力的培训方法已经在银行和金融领域取得了巨大成功 拉斯·沃尔夫斯在 Capital One 的经历 有任何迹象。

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

如果你在更新后的PCI安全标准的预期背景下看待它们，比如说，你完成的、用户就绪的金融产品必须遵循这些最佳实践，以实现最佳的安全保障，那么它们绝对没问题。但是，在我看来，每家公司，无论是财务公司还是其他公司，只要退后一步，意识到从周期开始就这样做会更有效率，就最有可能达到既代表功能质量又能代表高安全标准的软件最终状态。

那完美的最终状态？你知道，当对产品进行扫描、手动审核，结果完美无误时会发生这种情况吗？我们仍在寻找它。此时此刻，它是一只独角兽。

为什么这么难以捉摸？有许多因素：

• 扫描工具是值得信赖的，但它们并不总是有效的。误报是一种令人沮丧、浪费时间的副产品，事实是，即使结合使用，DAST/SAST/PCI 扫描也根本无法识别和揭示代码库中所有可能的漏洞。当然，他们 可能 让你一目了然，但他们真的在寻找所有东西吗？攻击者只需利用一个漏洞即可访问您认为受保护的内容。
• 开发人员继续犯同样的错误。开发人员之间没有关于安全的知识分配，也没有众所周知和有据可查的 “安全代码配方”（好的、安全的代码模式）。
• 不强调建立协作、积极的安全文化。
• 开发人员需要获得正确的工具，在不干扰他们的创作过程和敏捷开发方法的情况下，将安全性融入到他们编写的产品中。

这些指导方针是软件应遵守的安全标准的有力验证清单，但是将软件推向该状态的最佳流程还有待商榷。

我们没有因为缺少扫描仪而不安全的软件，我们有不安全的软件，因为没有为开发人员提供易于使用、易于理解的安全工具来指导他们。

我们现在正处于进化时代。总体而言，多年来，软件安全是可选的。如今，它基本上是强制性的，特别是对于敏感信息（金融、医疗、社会保障... 你明白了）的保存者来说。

PCI安全标准委员会正在帮助设定基准，但我希望看到他们凭借其行业的尊敬和影响力，努力为开发人员纳入实用指南，重点是充分和积极的培训和工具。目前，组织没有压力来确保其开发团队具有安全意识和合规性，许多开发人员也不了解这些小而容易修复的错误在被那些试图造成伤害的人所利用时所面临的严重性。

正如人们对生活中任何有价值的东西所期望的那样，真正实现变革确实需要一个村庄。而且（希望）空气的变化会席卷我们所有人 再往左。