🔒 🛡️ 👽 （S）SDLC，或如何使开发更安全。第1部分 🉐 🌱 🎓

每年，开发文化在不断发展，出现了确保代码质量的新工具以及有关如何使用这些工具的新思路。我们已经撰写了有关静态分析设备的文章，关于您需要注意的分析仪的哪些方面，以及关于从组织的角度来看如何基于静态分析构建流程的文章。

基于我们经常遇到的问题，我们描述了将代码扫描器引入安全开发过程的整个过程。今天，我们将讨论如何选择适合您的分析仪。

一种或另一种方式，所有开发人员都面临静态分析（无需执行代码分析）。例如，当编译器根据汇编结果生成一些错误或警告时，这些就是静态分析的结果。我们经常使用短绒-尽管通常很简单，但这也是静态分析。还有更多有趣的示例-Spotbugs（以前是findbugs），它使您可以找到Java字节码中非常有趣的漏洞，或者著名的SonarQube（一个用于监视代码质量的平台）。

但是，仍然很少遇到成熟的SAST工具。首先，我们谈论的是可以发现复杂漏洞的工具。事实证明，众所周知的开放工具无法应对这一任务，至少因为它们专注于另一个领域（错误和简单漏洞）。一个好的SAST工具可以实现过程间数据流分析。分析不应在程序文本上进行，而应在内部显示上进行-CFG，AST等。在上一篇文章中阅读有关此内容的更多信息。

SAST

这是一个示例-众所周知的SQL注入。在此示例中，来自用户的数据属于查询的完成功能，传递给injectableQuery函数，并且已经在那里属于SQL查询，从而使应用程序容易受到SQL注入的攻击。

为了找到这样的漏洞，必须了解“不良”数据来自何处，如何验证此类数据以及无法在何处使用它们。最重要的是-您需要监视整个应用程序中的数据传输，这就是数据流分析。该示例非常简单，在实际应用中，数据可以通过许多功能和模块，赋值和同义词。

显然，文本搜索不会找到这样的漏洞。程序内分析也不会找到，在某些开放式工具中只能执行。要找到此类漏洞（这通常是最关键的漏洞，即SAST工具的主要目标），我们需要使用完善的算法来对具有大规则库的数据流进行过程间分析。

基于算法的复杂性，出现了许多技术问题，这些问题将SAST工具的实现与其他静态分析器（例如SonarQube）区分开来。我们将在一系列文章中讨论这些问题。破坏者：资源消耗，分析持续时间，误报。

应该注意的是，除了算法之外，一个好的工具还可以将所有的数学运算打包在一个方便的界面外壳中，使您无需认真准备就可以使用SAST。此类工具还使用插件和API嵌入到CI / CD中，从而自动搜索漏洞并允许您构建安全的开发流程。

在第一篇文章中，我们试图对在研究SAST期间以及在决定实施该工具之后出现的主要问题进行分类。我们将在这里讨论一些问题，一些将转到以下文章。

开始吧

如果您已经有免费的静态分析仪，为什么要使用SAST？

在上一部分中，我们部分地解决了这个问题。当然，我们绝不会减少开放工具的优点。众所周知，SonarQube是自动进行代码质量评估的出色工具，它具有大量受支持的语言，集成和插件。 SonarQube非常适合嵌入到开发过程中，但更多地用于计数各种代码指标并搜索相当简单的错误或漏洞。它不执行数据流的过程间分析；因此，它不能用于搜索复杂的漏洞。通常，我们建议同时使用SonarQube和良好的SAST工具（如果SAST工具可以与SonarQube集成，则在这里很有用）。

还有其他好的开放式静态分析器。您可以使用find-sec-bugs插件为JVM字节码调用Spotbug（findbugs），该插件使用少量规则实现对数据流的进程内分析。有一个著名的Python强盗分析器。不能不提及clang内置的静态分析器，它具有良好的分析引擎和良好的规则库。

这种工具的问题在于，它们通常是狭义的专用工具（例如，仅适用于一种语言），实现简单的算法（也就是说，不允许发现复杂的漏洞）以及比商业工具小得多的规则库。此外，它们具有较少的功能集，包括接口和集成。好吧，我们可以提到缺乏支持。

另一方面，好的商业SAST工具（也有不好的工具）实现了复杂的特定算法，并具有可包含数千条记录的广泛规则库。通常，它们支持许多编程语言，具有丰富的接口和集成功能（插件，API）。下面我举一个例子说明我们正在谈论的集成。

甚至更低，请看一个可以基于SAST工具构建的集成方案的示例。通常，该方案与引入其他代码质量控制手段没有什么不同。开发人员可以编写代码，并可以立即运行SAST检查。代码进入存储库，然后使用CI / CD通过各种触发器从存储库进入SAST。扫描结果可以在SAST界面中查看，也可以最终使用支持开发过程的工具（错误跟踪器，邮件等）。

选择哪种SAST工具？

我将在选择工具的阶段进行一些介绍。有很多SAST工具，通常在市场上有几款（3-4）。问题出现了，如何选择正确的工具，寻找什么？在这里，我不足为奇，我将重点介绍三点：功能比较，质量比较和许可。将测试工具（试点）放在本地电路中并检查基础架构中的代码非常重要。

尝试该界面的所有功能，以了解它们如何适用于您的情况以及使用它们的便利性将是很好的。我指的是以前的文章之一。以下是一些有用的功能：

自动化程度最高的扫描启动（理想情况下，无需在两个按钮中进行不必要的设置，就可以运行扫描）；
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

集成功能非常重要-带有CI / CD，错误跟踪程序，存储库，Active Directory。如果有的话，尝试使用API自动化一个简单的动作会很好。

要检查质量，您需要扫描代码。最好选择几种不同语言的示例，以使示例具有代表性。从质量的角度来看，您需要查看误报（显然没有漏洞，但工具会显示）和遗漏（理想情况下，您需要知道漏洞在哪里，或者比较不同工具中发现的漏洞）。我不太会注意误报，因为通常只需一次扫描结果，将其标记为错误，然后它们就不会打扰您。

我将重点介绍两个重点。首先，非常重要的一点是要在实际应用中仔细考虑所有这些情况。严格检查您的代码（SAST在不同类型的应用程序上可能会有所不同）。搜索在开发过程中嵌入工具所需的那些功能。检查与现有系统的集成。

其次，在试验期间与供应商沟通非常重要。SAST并非最简单的方法，通常它足以征服供应商的常规建议，以充分了解该工具的功能。

您从什么时候开始扫描？

发现漏洞的时间越早，价格越便宜。从演示到演示都有一些棘手的时间表，我什至不会在这里添加它们。但是这个说法很明显。在漏洞产生后的第二天修复漏洞是一回事，而在已经被黑客入侵的情况下，对战斗服务器进行更改是一回事。因此，有必要将SAST的使用转移到开发的早期阶段。在这里可以争辩说，在开发中引入SAST本身是一项昂贵的事件，并且可能没有回报。在这里，我将争论：通常发现整个实施过程中都存在几个关键漏洞（您甚至可以在试验中进行评估）。

通过这种方法，我们还获得了额外的好处：当开发人员“每天”看到SAST结果时，他们就会对安全编程有所了解，因此，总的来说，安全开发的文化得到了增强，代码也变得更好。

当然，在开发过程中实施SAST时，有必要在CI / CD中实施，以构建DevSecOps。将SAST从发布之前的控制检查转移到开发过程的趋势已经很长时间了，在最近的2-3年中，它已经赶上了我们的市场。现在，如果不测试集成功能，任何飞行员都无法通过。

同时，理想情况下，我会在发行版之前保留对二进制程序集的控制检查（这也是可能的）。因此，您可以确保在组装和将应用程序转移到产品期间不添加任何新漏洞。

技术问题

然后，我将立即提出4个问题。

将SAST连接为SonarQube，困难是什么？
SAST工作了很长时间，如何配置DevSecOps？
SAST会带来误报，如何配置Quality Gate？
如果报告中没有误报，有数千个漏洞，该怎么办？

这些是实施SAST时出现的主要技术问题。它们的产生是由于以下原因。

由于算法具有指数性质，因此SAST可以运行很长时间并消耗大量资源-比linter或SonarQube还要多。
出于同样的原因，SAST可能会产生很多误报-开发人员不太可能希望在下一次扫描后每天解析大量瀑布。
通常，SAST是第一次在代码库上启动的，并且第一次运行可以显示很多操作，尤其是在有很多代码且数据库不是很新的情况下。

所有问题都可以解决。在本系列的下一篇文章中，我们将使用经验中的一个具体示例来研究如何实现SAST，以实现其所有技术功能的平衡并使每个人都满意。

组织事项

我不会忘记组织问题。在大型公司中，很多是由实施过程本身，资源分配，法规创建和过程复制产生的。

组织问题是由我们在上一段中讨论的相同技术特征引起的。好吧，除此之外，发展与安全之间的历史鸿沟和对抗还没有消失。我也参考了我们以前的文章。

未完待续

实施SAST-这是必要的，通常是合理的。但是，开始实施时，熟悉您在使用过程中出现的所有陷阱将是很好的。在本文中，我们开始分解它们，下面我们将继续介绍技术方面。

（S）SDLC，或如何使开发更安全。第1部分