安全员电视采访 - 深入了解 SAST 和简洁代码

我们的联合创始人兼首席执行官 Olivier Gaudin 以及我们的研发主管 Johannes Dahse 在 Black Hat USA 2023 期间会见了 Security Guy TV 的 Chuck Harold，讨论了 Sonar 宣布的更深入的 SAST 以及清洁代码的重要性。 

CHUCK：大家好，欢迎回到 Black Hat USA 2023。这是第 2988 集。我的下一位嘉宾是 Olivier Gaudin 先生，他是首席执行官，还有 Johannes Dahse，他是 sonarsource.com 的研发主管。欢迎先生，欢迎来到演出。

约翰斯：谢谢，查克。 

声纳更深 SAST - 高级检测分析

CHUCK：现在是今天的主题，使用Sonar 更深入的 SAST发现代码中隐藏的安全问题。很棒的对话，有很多值得学习的东西。你们最近于 8 月 2 日宣布了一项强大的深度分析，旨在发现代码中隐藏的安全问题。它被称为更深层次的 SAST。其新的高级检测解决了传统 SAST 工具遗漏的问题。今天我们就来聊聊这个。让我们首先询问更深层次的 SAST 有何独特之处。 

JOHANNES：我们认为，代码中的各种问题都可能使您的代码库不健康，而安全问题是我们检测到的问题的重要组成部分之一。安全问题的挑战通常是它们可能无处不在您的代码库中。当我们指的是代码库中的任何地方时，我们讨论的是可以由多个代码片段组合而成的问题，并且这些代码片段也可以位于依赖代码中。传统上，市场上发生的情况是我们只扫描开发人员的代码库，即他们编码的内容。但是每个软件项目都包含许多很多依赖项，现在我们还能够发现与此依赖项代码交互所产生的安全问题。 

查克：现在，这对我来说听起来有点不同。那么，Sonar 在这个领域的做法与市场上其他公司有何不同？

奥利维尔：是的，我认为如果您考虑一下其他供应商到目前为止对此的看法，您编写的代码和其他人编写的代码之间有明显的区别。传统上，您编写的代码是，好吧，我们必须分析此代码以查看是否存在任何流程问题，是否有人可以在应用程序中输入数据并且数据不会被清理。当谈到依赖关系时，市场的方法是仔细检查各种依赖关系和各种库，并手动检查是否存在问题。而这两个世界，它们是存在的，但却是分开存在的。SonarSource 的想法是，归根结底，无论你写代码还是其他人写代码，这都是代码，值得通过工具进行整体分析。这实际上就是我们所谓的更深入的 SAST 所做的事情，也就是说，我们实际上查看您编写的代码，我们添加库的代码，然后我们分析整个事情，我们发现我们无法发现的问题通过查看我们自己的代码或查看漏洞数据库来查找。这澄清了吗？

查克：是的，确实如此。对于我，这说得通。现在，我很久以前就开始这样做了，比如九年前。我在网络安全方面确实是自学成才。我了解到大多数代码都是开源的。我想当时有多达 80% 的代码来自开源。现在还是这样吗？我们是否仍然在开源编码方面处于高位，您是如何做的，或者您是否以同样的方式解决这个问题？我的意思是就像你说的，代码就是代码。我认为这是一个很好的表达方式。 

JOHANNES：所以我认为今天超过 90% 的软件都使用依赖关系。开发人员不想再次编写每个代码功能。他们希望避免返工并重用现有的开源代码，对吗？问题是开发人员真的不知道这个开源代码中有什么。他们没有时间验证他们正在使用的代码，每当他们使用一段代码和依赖代码并与之交互时，这都可能导致严重的漏洞。这并不意味着每个依赖项都容易受到攻击，或者每当您这样做时，您的代码就会变得容易受到攻击。但是，每隔一段时间，当您将代码与依赖项的一段代码以独特的组合方式组合时， 

定义干净的代码 

CHUCK：现在让我们定义干净代码。我认为这个定义多年来可能已经发生了变化，这对我来说就是这样的。还记得我们过去常说的“这是实时的”吗？十年前，实时意味着一天。而现在，实时已经更接近实时了。干净代码的含义与 10 年前有什么不同吗？

奥利维尔：我不认为如此，但我认为我们现在已经提出了一个更好的定义。因此，我们定义“干净代码”的方式实际上是一致的代码。也就是说，如果你想让一个团队来照顾代码，你必须在风格方面保持一致，而且在我们如何解决某些问题、关于代码构造方面也必须保持一致。所以整个代码应该是一致的。第二件事是代码应该是故意的，这意味着任何逻辑错误、任何未使用的内容、任何信息、任何未经清理的用户输入、任何使用后未释放的资源，都不被视为是故意的，并且应该修复。但我们还需要代码具有适应性。基本上，我们需要代码是可更改的。也就是说，如果你，如果我们不能再更改代码，我们不能再认为我们是在编写软件。它是别的东西，但你不能称之为软。因此，我们需要确保代码保持灵活性，能够被更改。最后，代码应该负责，这意味着我们不应该窃取代码来构建软件，我们不应该对密码进行硬编码等，因此需要照顾一整套事情来保持代码负责。这就是我们如何定义“清洁代码”，即一致、有意、适应性强和负责任。因此，需要注意一整套事情才能让代码负责。这就是我们如何定义“清洁代码”，即一致、有意、适应性强和负责任。因此，需要注意一整套事情才能让代码负责。这就是我们如何定义“清洁代码”，即一致、有意、适应性强和负责任。 

更深入的 SAST - 实现整洁代码的一部分

查克：所以我来自物理安全环境，这就是我开始的地方。我是一名警察，在工作室工作，1984 年我拥有了第一台电脑，甚至可能在你们俩出生之前。所以，我认为网络安全的进步是从基本上没有密码的互联网开始到现在我们遇到了所有这些安全问题，对吗？我一直认为它基本上是一种网络卫生状态。我们应该在这方面做得更好，我正在研究你们在网络卫生方面所做的工作，保持代码清洁。如果这有意义的话，我就是这样在脑海中想象它的。那么，更深入的 SAST 如何支持组织实现这种清洁代码状态？这是一个国家，对吗？这就像一种准备状态。 

JOHANNES：我认为更深入的 SAST 是清洁代码所需的一部分，对吧？因此，最后，我们希望找到各种导致代码不干净的问题，而安全性是重要的一部分。我们找到各种代码原因。但对于组织来说，安全问题的后果有时是巨大的，对吧？所以奥利维尔提到的是有意的部分，这确实是如果你使用依赖项的代码片段，你应该非常有意识地对待你正在做的事情。通常，开发人员没有时间真正弄清楚依赖项中的每段代码在做什么，因此我们确保有意使用并安全地使用它，以在代码库中实现干净代码的状态。

CHUCK：现在，你说了一些让我感兴趣的事情——代码还存在其他问题。你知道，可能是编程错误之类的。您是否发现大多数问题都是常规编程错误和缺乏安全编码的组合？他们是向一侧倾斜还是向另一侧倾斜？ 

JOHANNES：我认为它们都是相互关联的，这就是为什么我们也相信清洁代码如此重要。如果你看看 Olivier 刚才提到的内容，比如说一致或适应性强的代码，你就无法真正解决你的安全问题。我们在安全行业一直在谈论的是，例如，如果您有无法维护的代码，您就无法继续解决问题。或者另一个例子是，如果你有错误的代码，那么它可能会导致崩溃，但这些崩溃也可能导致安全问题，这就是为什么我们相信干净代码的所有这些不同支柱都是相互关联的，并且对于共同解决非常重要，所以你没有安全问题。 

声纳的区别 

CHUCK：现在，我必须说，伙计们，我已经做了很多演出，技术上超过 3,000 场。声纳对我来说听起来不一样。我听得对吗？听起来你做的事情与大多数人不同，坦率地说，对我来说，这听起来更彻底。这是一个很好的描述方式吗？

OLIVIER：我们一直从我们自身的需求出发，根据工程需求来开发产品。但是，我们也有一个超级大的社区。所以我认为 SonarSource 值得注意的事情之一是我们与市场的一致性，也就是说，有时我们有点早，然后我们的社区迎头赶上，然后他们将其推向某个方向……因此，如果它作为一种产品感觉非常真实，可能就是因为这个。 

奥利维尔：我只想回顾一下您之前所说的一件事，这对我来说非常非常正确。你谈到了卫生问题，我认为这就是问题所在，如果你不这样做，如果你没有良好的卫生习惯有了你的代码，到最后，你的软件就不会成为一种资产。这将是一种责任。因为你的代码成为一种责任，你的软件也将成为一种责任。因此，我们确实试图在工程层面解决这个问题，这就是全部，这种卫生应该在开发阶段进行。之后就不应该发生这样的事。然后，您想要真正解决复杂的问题、威胁建模等。安全团队应该将所有时间、专业知识和精力集中在这个更复杂的问题上。不运行分析工具来查看开发阶段是否完成了良好的工作（如果有意义的话）。 

人工智能对代码的影响

查克：确实有道理。你知道，我们的新挑战是人工智能，ChatGPT。我并不是选择 ChatGPT，但我们只是以它为例。您是否发现这种先进的人工智能现在会给您所在的行业带来新的挑战？有帮助吗？会阻碍吗？

OLIVIER：我的意思是，我认为对于 SonarSource 来说，这是一个真正的机会。对于这个行业来说，我认为这确实是一个挑战。归根结底，我认为通过人工智能、生成式人工智能，我们将看到更多的代码被编写出来。无论是因为开发人员变得更加高效，还是因为非开发人员能够编写应用程序，最终都会有更多的代码。而且该代码肯定不会干净。其中一些可能是本地干净的，但总的来说，必须对这段代码进行审查，我认为这对我们来说是一个很好的机会。 

查克：朋友们，谈话非常好。很高兴你来参加这个节目。Olivier Gaudin 和 Johannes Dahse，sonarsource.com，Black Hat USA 2023。祝你们好运，希望明年能见到你们。我会尝试亲自回来参加演出。感谢您来到保安员电视台。