ISMG 访谈 - 保护应用程序安全，通过干净的代码加速 DevOps

这是网络安全意识月！首先，我们回顾一下 Sonar 创始人兼联合首席执行官 Olivier Gaudin今年在 Black Hat USA 上与 Information Security Media Group 的 Tom Field 的对话。两人讨论了Clean Code、它是什么、为什么它对安全如此重要，以及最近宣布的更深入的 SAST。

汤姆：大家好，我是汤姆·菲尔德。我是信息安全媒体集团的高级编辑副总裁，谈论清洁代码。我很荣幸地欢迎 Olivier Gaudin 工作室，他是 Sonar 的创始人兼联合首席执行官。 

奥利维尔：非常感谢。

“干净的代码”是什么意思

TOM：那么，我们将从“干净代码”这个术语开始。当你说“干净的代码”时，你到底是什么意思？ 

OLIVIER：好的，我们的意思是不脏的代码。 

汤姆：我想说这就解决了。

奥利维尔：我们如何定义它，我们通过说清洁代码应该是一致的来定义它，也就是说，如果你希望你的开发团队能够真正管理代码，集体拥有它，不浪费时间等等，你需要保持一定的一致性。所以我们谈论的是风格构造，你的代码必须是惯用的，等等。它必须是有意的，任何你知道的——不需要太多细节——任何未释放的资源，任何未经净化的用户输入，任何矛盾的陈述都不是您想要的，因此我们试图抓住这一点以向您展示。代码必须具有适应性，也就是说，您需要能够更改它。根据定义，每个人都期望软件会发生变化。否则，您应该将其称为其他名称。并且，代码应该负责。代码中不应有硬编码的秘密，

没有干净的代码会有什么风险

汤姆：而且，我们知道现在它并不普遍。这是一个很棒的术语，但它并不广泛。它没有得到应有的广泛接受。与我讨论如果没有清洁代码，会存在什么风险。

奥利维尔：是的，如果你考虑软件，我的意思是，代码是软件的主要资产。除了代码之外，您还拥有一次性商品的部件，但代码是软件中最重要的资产。如果你的代码不干净，你实际上不会拥有资产，而是会承担责任。你将会遇到一些很难改变的事情，需要很长时间，每次你改变时，它都会崩溃。安全团队对此不满意，基础设施团队对此也不满意。基本上，我们讨论应用程序的生产力、速度、风险和脆弱性——因此会产生很多后果。 

“代码即干净”方法

TOM：跟我谈谈您的“Clean as You Code”方法以及从中可以找到的好处。 

Olivier：是的，我们在 15 年前创立了 Sonar——三位创始人、三位软件工程师——这是我们生活的主题，从那时起一直如此。我们很快意识到，我们采用的清洁代码方法并不奏效。即使作为车库里的三个人，我们实际上也无法实现我们的目标，我们开始怀疑我们的方法出了什么问题，我们开始怀疑是否有一个业务，这里有一个我们应该继续探索的领域。在某个阶段，我们意识到我们看待问题的方式是错误的。 

奥利维尔：我们正在考虑运行分析，获取一些报告，然后找出解决方法。当你这样做时，你就为实际失败留下了很大的空间，这就是发生在我们身上的事情。我们所做的每一个版本都有一定的目标，这些目标是合理的、雄心勃勃的，但仍然可以实现，但我们无法实现它们。我们必须对数字进行调整或进行一些工作来获得数字，我们觉得，如果我们做不到，那么没有人能做到。所以我们开始思考我们在这里做什么，我们真的在寻找正确的问题吗？我们意识到我们不是。我们正在做的事情，以及许多公司仍在做的事情，就是共同查看代码的状态，并尝试改进整体状态。这是一个问题。我来做个比较——如果你家里漏水， 

汤姆：找到了吗？

奥利维尔：是的。 

汤姆：然后停下来。 

奥利维尔：是的，然后你，你会拖地，对吧？如果漏水处还没修好，你就不会停止拖地，对吗？非常合乎逻辑，是的。当你谈论代码时，这是一样的。也就是说，你看看状态。地板上已经有水了，你立刻就会想：“天哪，我们需要解决这个问题，我们需要解决这个问题，我们需要解决这个问题。” 当您参与其中时，同时发生的事情是您仍然有 2,000 名开发人员在不断推动产品的发展。所以一旦我们开始意识到这一点，当我这样说时，就非常明显了。 

汤姆：是的。

奥利维尔：我们大概花了一年半的时间才真正意识到这一点，然后它就变得非常简单。我们应该做的最重要的事情是修复泄漏。这基本上意味着，确保每当开发人员更改代码或添加代码时，这些代码都是干净的。当你这样做时，突然之间，新代码——我们所说的新代码——就变得干净了。但它也有一个很大的好处，那就是，因为我们不断改变软件，所以我们实际上修复了过去的问题。这就是我们所说的“代码清洁”。也就是说，它是一种非常简单的系统性但功能强大的方法，可以基本上修复整个应用程序中的代码。您正在以此偿还遗留的技术债务。 

使用干净的代码优化 DevOps 工作流程

TOM：请告诉我如何优化 DevOps 工作流程。

OLIVIER：所以，我对 DevOps 的定义是，它是一组流程工具，可支持开发、线性生成代码。会发生的情况是，如果你不执行 Clean Code，你将能够执行一次、两次，你将能够执行一次迭代、两次迭代、三次迭代。但在某个阶段，当您想要添加功能时，您将陷入技术债务的困境。也就是说，你想改变一些东西，但它破坏了其他东西，很难阅读，人们不再真正理解代码。所以基本上，如果你有，如果你交付了干净的代码——首选方法是“代码干净”，这是最有效的方法——你将能够实现可持续、持续的交付。

TOM：是的，想必您的开发人员的生产力、速度和交付也可以得到提高。

奥利维尔：当然。有两大好处——一是我所说的吞吐量，即你可以用相同数量的人做更多的事情，或者你可以用更少的人做同样的事情。还有你的风险管理，也就是说，当你将应用程序发送到生产环境时，你不希望它崩溃或被黑客攻击。基本上，这是两大优点。 

深入研究 SAST

TOM：所以，现在您已经在黑帽大会之前宣布了这一消息。您能告诉我一些细节吗？ 

奥利维尔：当然。所以，我们宣布的是，我们发布了所谓的更深入的SAST，这是一个在进行安全分析时更深入的深度版本。因此，如果您考虑一下当今的应用程序安全世界，您实际上有两个部分。一是，您分析代码。然后第二部分是你在运行时与应用程序交互。因此，根据定义，我们重点关注第一个。在那个分析代码的世界中，又分为两个部分。一种是查看您自己的代码，因此您基本上可以进行静态分析来了解您在哪里引入了漏洞。另一方面是所谓的依赖管理 SCA、OSA 等。 

奥利维尔：对我来说，一直很奇怪的事情之一是这两部分都是代码，但我们以不同的方式看待它们。一方面，我们进行分析。另一方面，我们只是创建将引用漏洞的数据库。我们为什么要做这个？我认为从历史上看，这是由于技术性能等问题造成的，但没有真正的理由再这样做了。我们相信我们应该将这两个部分作为代码来分析，因为归根结底，这些库只是您自己代码的扩展——这是您不会重写的代码，您基本上可以重用。所以这就是我们现在所做的，我们立即分析整个代码，我们可以找到以前找不到的漏洞。 

声纳的区别

TOM： Olivier，您多年来的对话正是许多安全领导者现在正在进行的对话。这是一个软件安全现在受到欢迎的市场。在这个市场中，Sonar 如何从其他竞争对手中脱颖而出？ 

奥利维尔：如果你去过 Black Hat 并逛过展馆，你会发现所有展位上的信息都非常相似。但如果你退后一步，多思考一下人们如何参与，就会发现这在消息传递中实际上非常明显。大多数供应商实际上声称他们对开发人员友好，他们声称他们正在左移，他们声称有时他们帮助开发人员为安全团队服务。我认为这确实是他们所做的，也是大多数供应商所做的，他们实际上在审查安全性时发挥了作用。因为存在如此多的摩擦，他们意识到——摩擦来得太晚了，开发人员也在推迟修复问题——他们正试图在开发部分投入更多精力。我们采取了完全相反的做法，也就是说，我们来自开发人员。也就是说，我们为开发人员服务。作为一个非常好的副作用，它实际上对安全性有很大的影响。所以它实际上有利于安全团队。所以对我来说，这是最大的区别，正如我们从那时起所做的那样，我们基本上必须能够取悦开发人员。也就是说，我们的产品速度超快，集成度超好，并且误报率极低，因为你知道吗？开发人员，他们不喜欢误报。当他们看到一个误报，然后是另一个误报，然后是第三个时，下一个问题——即将到来——将会是这样的，“我什至都没有看它，这是一个误报。” 所以它实际上有利于安全团队。所以对我来说，这是最大的区别，正如我们从那时起所做的那样，我们基本上必须能够取悦开发人员。也就是说，我们的产品速度超快，集成度超好，并且误报率极低，因为你知道吗？开发人员，他们不喜欢误报。当他们看到一个误报，然后是另一个误报，然后是第三个时，下一个问题——即将到来——将会是这样的，“我什至都没有看它，这是一个误报。” 所以它实际上有利于安全团队。所以对我来说，这是最大的区别，正如我们从那时起所做的那样，我们基本上必须能够取悦开发人员。也就是说，我们的产品速度超快，集成度超好，并且误报率极低，因为你知道吗？开发人员，他们不喜欢误报。当他们看到一个误报，然后是另一个误报，然后是第三个时，下一个问题——即将到来——将会是这样的，“我什至都没有看它，这是一个误报。”

汤姆：非常好。珍惜你的时间，珍惜你的洞察力。太感谢了。

奥利维尔：非常感谢。 

TOM：主题是整洁代码。你可以看看这件衬衫——代码更好。我很高兴能与 Sonar 创始人兼联合首席执行官 Olivier Gaudin 进行交谈。我是信息安全媒体集团的汤姆·菲尔德。感谢您今天的时间和关注。