5个关键SAST活动，构建你的DevSecOps流水线 | IDCF

为构建可持续发展的项目，我们需要将SAST工具集成到DevSecOps流水线中，让它们自动化执行，以实现效率、一致性和早期检测。

静态应用程序安全检测（SAST）过程检查源代码中是否存在安全缺陷。SAST是应用程序安全保障流程的众多检查之一，目的是在DevSecOps流程的早期，识别和减少安全漏洞。

将SAST工具集成到DevSecOps流水线中对于构建可持续研发流程至关重要。SAST工具的自动化是其中重要的组成部分，可以在提高效率的同时，保持一致性，以及及早发现安全问题。

关于如何将SAST工具集成到DevSecOps流水线中，客户通常会提出如下几个关键问题：

• 如何处理误报？
• 如何分类结果？
• 识别出来的新问题会如何处理？
• 我的扫描需要4到5个小时才能完成。如何在DevSecOps流水线中使用此工具？

如果你也存在这些问题，并且关心如何将SAST工具集成到DevSecOps流水线中，请继续阅读。

下图列述了DevSecOps流水线的五个关键节点，每一个节点的用途，优势，关键推动因素和用例：

无论你管它叫SecDevOps，DevSecOps还是DevOpsSec，目的都是将安全性构建在持续集成，持续交付和持续部署流水线中。

本文将指导你完成DevSecOps的完整过程（我们在此清单中将其称为DevSecOps），通过深入探讨上述五个活动的目的、优势、关键推动因素和用例，确保你将安全性集成到流水线。

DevSecOps流水线的5个关键检查点

1、预提交检查

预提交检查是DevSecOps流水线中的第一步，在开发人员将代码提交到源码库之前进行。

1）目的

在将源码更改提交到源码库之前查找并修复常见的安全问题。

2）收益

预提交检查的钩子程序作用非常强大，可以帮助团队自动化手工任务并提高生产率。此外，使用IDE中集成的静态分析工具进行安全检查可以设置使用有限数量的规则，以缩短检查时间。当检测到代码库中的较大更改时，还允许手动检查代码。在确定存在安全漏洞时，这些检查还可以触发风险分析。

3）用例

这些检查使开发团队可以在自己IDE中运行扫描。在编写代码时，工具会自动并且及时地提供安全指导。在代码编写并提交到你的源码库之后，无需扫描漏洞。将工具用作是桌面的安全专家，当开发人员编写了可能引入风险的代码时，它会自动提供指导。

接下来，创建钩子程序以触发诸如威胁建模、架构风险分析、手动代码审查之类的活动，另外也可以创建钩子来查看配置文件中的硬编码。

最后，使用钩子程序发送电子邮件给应用程序安全团队或软件安全组（SSG），通知检查到源码库中的关键代码更改。

2、提交时检查

DevSecOps流水线的下一步是提交时检查，签入源码库时会自动触发。

1）目的

生成并执行基本的自动化应用测试，这些测试将结果快速反馈给提交变更的开发人员。

2）收益

提交时检查可确保代码始终保持可编译和可构建的状态，同时引起对关键和高度安全性问题的关注。

3）关键

提交时检查为各种软件安全活动确定了明确定义的流程，同时还使能开发团队及时修复严重的高风险问题。此外，提交时检查还支持QA安全测试。

4）用例

首先，编译并构建代码。接下来，使用有限的规则集配置并运行静态分析，例如运行公司的TOP 3的漏洞（每年更新）。例如，诸如SQL注入和/或跨站点脚本（XSS）反射和存储之类的漏洞。这是一种快速的增量扫描，可在几分钟内向开发人员提供反馈。

接下来，自动化安全测试并收集指标。一旦破坏构建将就严重和高度安全性问题向相关团队发出警报。

3、构建时检查

提交时检查如果成功，会自动触发构建时检查，这是DevSecOps流水线中的第三个活动。

1）目的

对应用程序执行高阶自动化测试，包括更深层次的SAST、开源管理、安全测试、基于风险的安全测试、使用PGP对二进制发行版进行签名，以及将工件存储在存储库中。

2）收益

构建时检查在发生例如下面的任何故障时都会中断构建：

• 代码无法编译
• 单元测试失败
• SAST失败
• 过多问题发现
• 发现漏洞时（例如，SQL注入或XSS）

这些检查还会识别依赖关系，并使用工具（例如SCA）检查是否存在任何已知的，公开披露的漏洞。

3）关键

这些检查通过明确定义的安全活动流程，使QA安全测试成为可能，同时使开发团队能够在引入重大和高风险问题的第一时间进行补救。

4）用例

构建时检查允许用户配置更全面的SAST规则集，例如在处理Web应用程序时的OWASP Top 10。他们还使用工具配置作业以识别第三方组件中的风险。这些检查使基于风险的安全测试自动化，根据系统的风险状况运行特定的安全测试。

每个安全测试的目标旨在探查特定风险，提醒开发团队注意关键和高风险的问题，甚至对工件进行数字签名，并将它们存储在你的制品库中。最后但并非最不重要的一点，构建时检查会收集到很多有用的指标。

4、测试时检查

沿DevSecOps流水线向右移动，成功的构建时检查将自动触发测试时检查。

1）目的

从制品库中选择最新的“好的”构建，并将其部署到类生产或测试环境。包括功能、集成、性能、高级SAST和DAST的所有测试，都基于此版本执行。

2）收益

这是产品上生产之前的最后一个测试阶段，类生产环境是最像生产环境的环境。

3）关键

测试时检查要求针对各种软件安全活动定义明确的流程。一旦引入，便使开发团队能够纠正严重的高风险问题。还使QA安全团队的测试方法成为可能。此外，还可以通过SAST工具和渗透性测试触发手动代码审查。

4）用例

为测试时检查SAST配置更广泛的规则集，可能包括该工具的完整安全规则集。由于你已经在较早的检查中运行过SAST，因此请确保运行那些尚未涉及的测试。并且需要配置运行DAST工具。测试规则集应包括常见的严重和高严重性问题，例如OWASP Top 10中概述的那些。

此阶段也包括模糊测试，给程序的输入参数灌入随机数据，以期引起错误状态。未能正确处理错误格式的输入也会导致安全问题。

配置最新的“好的”版本并将其自动部署到类生产环境。然后，将关键和高风险的问题发送警报到开发团队。

最后，这些活动中也会收集数据指标。

5、部署时检查

如果先前的所有步骤均已成功完成，并且应用程序已准备好进行部署，则部署时检查将完成整个DevSecOps流水线，包括部署前安全检查和部署后安全检查。

1）目的

部署后的测试提供了持续的保障，确保对生产环境的更改不会引起安全问题。实施定期触发安全测试流程是一个很好的策略。

2）收益

部署时检查可以帮助发现在生产前测试活动中可能漏出的错误。连续的监控使组织可以洞察应用程序正在接收的流量类型。此外，收集应用级别的安全指标有助于识别恶意的用户模式。

3）关键

通过此活动发现的缺陷可以反馈给开发团队，并用于改善开发人员的行为。

4）用例

部署前

• 自动化配置管理
• 自动配置运行时环境

部署后

• 持续监控，自动收集应用级别安全指标
• 安排安全扫描
• 执行漏洞扫描
• 协助漏洞扫描
• 创建事件响应计划
• 向DevSecOps团队提供洞察力以推动威胁情报活动

DevSecOps检查工作流程示例

在DevSecOps流水线中实现安全性时，有目的有计划有步骤地进行这些活动很重要。没有任何检查是一成不变的，不要固守或照抄别人的规则。你可以在开发过程的早期或后期安排不同的活动，以适应你自己的应用开发生命周期。

让我们看一个部署的工作流程示例，描述如何执行和触发这几个活动。

我们的核心理念是，将必要的手工监管与适当的自动化活动相结合，将五项不同的SAST自动化活动集成在现有的流水线中，以期达到同时兼顾成本效益、积极主动且安全可控的DevOps流程。

现在，让我们深入研究这五个集成活动。

1、预提交阶段

当开发人员检入代码时，钩子程序会在将代码和配置提交到源码库之前查看对代码和配置的更改，包括客户端和服务器端的钩子。

2、提交时阶段

接下来，将代码提交到源码库后，运行提交时检查。包括带有预定义规则集的增量SAST，可为开发人员提供快速反馈（在几秒钟的代码签入时间内）。如果发现严重或高风险问题（例如SQL注入或XSS），则必须中断构建并立即通知开发人员。

SAST应该是增量的。换句话说，仅对更改的文件集运行SAST。此外，请确保将指标收集到仪表板中。自动跟踪缺陷并创建缺陷。应该以与质量问题相同的方式来处理安全问题。

3、构建时阶段

提交时检查成功后，DevSecOps流水线的下一个阶段就是构建时检查。在这里，你将要使用SAST运行更全面的规则集。也许你还想为你的应用程序运行OWASP Top 10。此时，你还应该运行软件组成分析（SCA）工具，识别免费和开源软件（FOSS）中的漏洞或相关的许可证问题。与提交时检查一样，一旦发现问题，需要中断构建，自动进行错误跟踪并收集指标。

4、测试时阶段

现在，该进行测试时检查了。在运行安全性活动之前，请确保使用最新的成功构建制品。如果你不确定自己的SAST规则，请运行完整的SAST分析规则集。一旦你的SAST工具向你发出绿色信号，请运行已配置的DAST或IAST工具。如果你还拥有模糊测试工具，那么这也是运行它的最佳时机。

在SAST、DAST、IAST和模糊测试活动中发现的任何漏洞都应停止构建，收集指标并立即在Bug跟踪系统中创建缺陷。

到目前为止，你已经知道你的变更如何通过DevSecOps流水线，看到成功完成了哪些活动，在仪表板上查看发现了哪些漏洞，以及判断是继续DevSecOps流水线还是暂停/停止将更改投入生产。

5、部署时阶段

现在我们进入最后阶段：部署前和部署后检查。是时候自动化配置管理了，如果你的应用程序使用SSL连接到数据库，则配置运行时环境（例如，检查访问控制和组权限）。一旦应用程序计划上线，请安排安全扫描，识别可能在生产前测试中遗漏的错误。实施漏洞扫描，分类和调查用户报告的问题。

回顾一下

上述DevSecOps工作流程，我们聚焦在了几个核心的安全活动上，除此以外当然还有许多其他的相关话题（例如，在DevSecOps流水线中执行恶意代码检测），不在此详细列数了。上述的工作流程假定你已经自动化了其他活动（例如单元测试、功能测试、用户验收测试、集成测试等）。

将SAST集成到DevSecOps流水线

前面我们阐述了DevSecOps流水线的5个关键检查点，以及在每一个检查点我们需要进行哪些扫描，接下来我们聊聊如何将SAST工具集成到上述的DevSecOps流水线中。

下面的流程图显示了从研发到交付各个阶段需要运行的SAST工具。SAST工具需要运行在开发人员的IDE中，进行预提交检查，并且在提交、构建和测试等阶段都需要分别执行。

活动1 扫描应用

1）扫描代码和审核/分类结果

对于扫描时长并没有严格的规定。通常，扫描时间取决于代码行数和应用程序的复杂度。扫描时间通常是构建时间中的一小部分，通常而言构建时间会是扫描时间的4到10倍之间。

扫描完成后，你将收到一份包含所有结果的扫描报告文件，此时有两种可能的情况：

• 如果这是对源代码的首次扫描，你需要对扫描的发现问题进行完整的审核检查，称之为“分类”。
• 如果这是对源代码的后续扫描，则会将扫描报告文件上载到企业服务器。企业服务器把新的扫描与先前审核/分类的扫描结果进行合并，并突出显示尚未审核的新问题。这样，你就可以消除重复的工作。

通过企业服务器或是在SAST IDE中查看结果。在审核/分类过程中，确定要修复的错误，哪些错误不是高优先级，哪些结果是误报等等。

最后一步是修复错误。修复了所有错误并添加新代码后，请重复执行以下循环：对刚刚更改的代码执行差异扫描或增量扫描，然后从头再开始这一循环。

第一次扫描应用程序时，你是在创建一个基线。这意味着你应该查看每一个发现或发现组，并采取以下操作之一：

• 标记结果（“不是问题”，“可疑”等）。
• 取消假阳性结果。
• 隐藏这些发现。

建立基线后，确保将扫描报告文件上载到企业服务器。

在后续扫描中，我们将注意力集中在增量上，即与上次扫描相比的差异。这也是为什么我们需要合并这一功能。

2）合并后续扫描结果

让我们讨论合并结果意味着什么。

企业服务器会自动将你旧的扫描结果与新上传的结果进行合并。检索合并的扫描文件，识别新引入的错误。另外，在影响构建或将缺陷提交到错误跟踪系统之前，所有后续扫描都需要推送到企业服务器。

假设你已经因为扫描而破坏了构建，在bug跟踪系统中创建了缺陷，并且开发人员已修复该bug，并且还将某些发现标记为误报。你不会想再经历一次全量审核扫描结果的痛苦。

解决方案是SAST工具的合并功能。假设你在第n周扫描并审查结果，在错误1发现一个误报，在错误2发现了一个真实错误。你修复了错误2，在扫描文件中将错误1标记为“误报”，然后将更多的代码添加到你的项目。

现在你处于第n + 1周，并且进行了另一次扫描，首先要做的是与第n周的扫描合并。因为你已经为SAST工具提供了背景知识，所以它会记住你已标记了bug 1为误报，并且还将注意到你已修复了bug2，它将分别标记为“已抑制”和“已删除”。

你在这段时间添加了代码，因而引入了一个新的错误，即错误3。工具会将错误3标记为“新”。现在你的工作量减少了，你只需要查看并修复错误3。

合并是一项有效的功能，当你将扫描结果上传到企业服务器时，合并会自动完成。这样可以避免重复进行已经完成的工作。

3）消除误报

在安全分析师的协助下，最适合审查源代码是开发人员。SAST工具可以看作是虚拟安全分析员，因为它为开发人员带来了安全知识，并暴露出开发人员可能忽略掉的那些错误。

但是，工具始终是工具。工具也会犯错误，我们把这些错误称为假阳性（误报）。当工具报告的问题根本不是真正的问题时，就出现了假阳性。与此相反，当工具查不出应有的错误时，就会产生假阴性。

造成大量误报最简单的原因是：工具无法像人类一样进行分析，因为它缺乏应用程序所处的上下文环境；因此，它必须谨慎行事，并试图引起用户注意那些潜在的问题。

并非所有的SAST引擎都具有相同的精度，语义分析器倾向于报告较多的误报，数据流引擎则通常会更加准确。

在开始查看工具的发现之前，请确保你了解应用程序的上下文，了解包括应用程序的使用者、信任边界、处理的敏感信息、实现的安全机制、使用的输入验证机制等详细信息，将极大地提升你消除误报并确定实际问题严重性的能力。

4）自定义规则集

定制和调整规则以适应特定的应用程序，对于从工具中获得最准确和可操作的结果至关重要。了解了应用程序加载和分类结果后，此时你可能会需要自定义规则集。

由于注入式攻击是当今网络上的第一大攻击类型，因此在解读或使用数据之前，能够跟踪到数据来自何处以及调用了哪些API至关重要。

异常的来源会多种多样，例如用户输入、属性文件、文件系统和数据库等都可能是污染源。

SAST工具允许你扩展其规则，将你日常的验证声明为更整洁的规则。一旦你为日常验证自定义了规则集，直到你清理了异味，工具才会停止报告发现。

在DevSecOps流水线中自动化SAST工具

完成扫描，分类，消除误报和自定义规则集，下一步就是在DevSecOps流水线中配置自动化工具。

在DevSecOps流水线中调用自动化工具，包括使用命令行选项进行扫描或使用构建服务器可用的插件，自定义破坏构建的阈值，配置向引入问题的开发人员的电子邮件通知，以及自动进行错误跟踪。

活动2 SAST01：高度配置的规则集

装载、分类和自定义规则集后，是时候向开发人员推出SAST IDE插件了。SAST工具会自动检测漏洞，并在开发人员键入代码时提供及时的安全指导。

开发人员可以通过检查代码中的安全漏洞并在编码过程中使用工具提供的指南来解决最常见的安全问题。

由于开发人员需要不断地审查发现的问题，因此关键是确保假阳性发现率尽可能低，甚至为零。经过分类的结果有助于推出准确真实的规则集，使开发人员对SAST工具充满信心。

以下是一些可以在开发人员IDE中配置运行的规则示例：

• SQL注入
• 跨站脚本（存储）
• 跨站脚本（反射）
• 资源泄漏
• 硬编码
• 配置审查

活动3 SAST02：客户的十大问题

如果每个开发人员都认真地运行SAST工具，就没有理由在DevSecOps流水线中进一步运行任何SAST，但事实并非如此。因此，一旦开发人员将他们的代码检入版本控制存储库中，假设SAST工具是自动化的，则会采用与SAST01中配置的扫描规则相同的规则，以及诸如客户端的前10大问题之类的更多规则进行扫描，并且是完全自动化运行。此阶段的SAST工具完成运行扫描不应超过4–5分钟。

让我们看一下SAST02检查的规则：

• SQL注入 - 与SAST01相同
• 跨站脚本（存储） - 与SAST01相同
• 跨站脚本（反射） - 与SAST01相同
• 资源泄漏 - 与SAST01相同
• 硬编码 - 与SAST01相同
• 会话管理
• 配置审查

活动4 SAST03：OWASP十大问题

此时，在DevSecOps流水线中，你正在朝着流程的右侧移动，并且活动通常需要更长的运行时间。如果你的程序是Web应用程序，则可以运行针对OWASP十大问题的SAST工具。你可能还会运行为使用Web服务、REST服务或自定义框架的应用程序，所创建的自定义规则，这些应用程序的SAST工具的规则可能不够完整。SAST01和SAST02的扫描中已经涉及了其中的一些问题，例如SQL注入和XSS。

下面列出了OWASP十大规则集的一部分：

• 恶意文件执行
• 不安全的直接对象参考
• 信息泄漏和错误处理
• 命令注入
• 弱加密
• 拒绝服务
• 路径操纵
• 不安全的密码存储

活动5 SAST04：综合规则集

这是最后一个阶段，你可以使用完整的规则集执行扫描。可以结合使用SAST03和SAST04一起执行检查，或者将它们进一步分解。这里的执行时间可以介于60-90分钟到几个小时之间。

可以在此处配置和运行的一些规则如下：

• XML注入
• XPath注入
• XML外部实体
• 重定向
• DOM XSS
• Cookie注入
• 表述性语言（EL）注入
• 标头注入
• LDAP注入

运行的规则集越广泛，工具完成扫描所花费的时间就越长。这也是尝试在DevSecOps流水线的每个阶段分别运行不同规则的原因之一。

至此，你应该对所有SAST规则有了一定的了解。就像我经常说的那样，没有“一种尺寸能适合所有人 one size fits all”。根据使用的语言、体系结构、技术和框架，你需要仔细的配置规则，并编写自定义的规则。

回顾

为了有效地使用SAST工具，你首先要做的是对工具进行加载，扫描，分类和自定义。一切就绪后，获取IDE插件，在开发人员提交代码前进行检查，以便于在引入问题时检测并解决问题。

接下来，提交时检查，将运行相同的规则集以及客户前十的规则。构建期间，请配置并检查前十OWASP问题。

最后，在测试期间配置全面的规则集。

除了在IDE中运行SAST工具以外，所有其他检查一旦破坏构建，就会发送电子邮件通知并将缺陷推送到缺陷跟踪系统。

自动化是DevSecOps的关键。拥有核心的安全活动的DevSecOps流水线固然非常重要，可以引入一个或多个应用安全工具自动化执行来扩展安全性活动。于此同时，需要强调的是，如果这些工具的配置不正确，会适得其反。

安全活动必须是DevSecOps流水线的组成部分。DevOps团队必须通过开发和运维同样的方式来获得安全性。

许多第一次使用SAST工具的开发人员也许会百感交集，但是相信我，一旦在DevSecOps流水线中启用并自动化工具后，开发人员会开始真正的关注代码安全性。

通过本文建议的五项关键检查活动，我们希望你可以达成以下的关键目标：

• 让开发人员专注于修复缺陷；
• 通过在开发人员的IDE中使用预提交检查，在开发发布周期的早期阶段匹配源代码分析策略；
• 激发开发组织的预防意识；
• 使安全团队能够维护合规并集中的持续跟踪残余风险；
• 允许DevSecOps团队集成SAST工具，同时不增加生产前置时间。

本文翻译并整理自：

• https://www.synopsys.com/blogs/software-security/devsecops-pipeline-checklist/

• https://www.synopsys.com/blogs/software-security/steps-to-integrate-sast-into-devsecops-pipeline/

译者：姚冬

本周四晚8点，【冬哥有话说】第10期，邀请到FIT2CLOUD飞致云东区总经理徐桂林分享《为什么 JumpServer 是多云环境下最好用的堡垒机？》识别下图二维码回复“冬哥”即可入直播群~