DevSecOps

1. DevSecOps是什么？

DevOps到DevSecOps的转型

传统的保障安全的方法基本都是被放在整个软件开发生命周期的后期集中进行，虽然它耗时较长，但在瀑布研发模式下也还能被很好的执行。但随着更多企业开始进行数字化转型和敏捷转型，软件应用发布的周期在不断被缩短，频率在不断被提升。顶级的敏捷团队甚至能做到一天发布多次。这时，传统的保障安全的方法已经完全不能跟上这样快节奏的应用发布速度。虽然大部分敏捷研发团队都已经采用了DevOps来保障发布质量，但DevOps中没有关注到安全部分，因此不能及时检测并修复软件中的安全漏洞。此时，DevSecOps应运而生了。

将安全整合到DevOps的“DevSecOps”会带来思维方式、流程和技术的整体变化。安全和风险管理的领导者，必须坚持合作，DevOps的敏捷性意味着其在开发过程是无缝的和透明的，同理，“DevSecOps”中的“安全”也应当是沉默的。
企业在执行DevSecOps时通常会面临以下几个方面的挑战：

• 作为一名安全或风险管理人员，应当很清楚企业的业务发展是核心，因此向客户提供新的IT功能的产品开发团队才是王道，而不是信息安全或IT团队。
• 信息安全工作必须适应开发过程和相应的工具，而不是背道而驰。
• 组织使用DevOps生产新的应用和服务，DevOps相关的过程和工具也有责任遵照公司对其他应用程序的要求，产生安全且符合要求的代码。要求应用程序达到百分百的安全是不现实的，企业一旦陷入“将安全漏洞的数量降为零”的错误追求中，安全测试的负担识别加重，且很可能成为业务发展的一个障碍。

因此，问题的关键是风险的控制和管理，而非单纯的追求安全。想要确保应用程序和数据安全，在进行安全和风险管理（Security and risk management，SRM）时，应当注意：

• 将安全和合规测试无缝地整合到DevSecOps中，使开发者专注工作在持续集成和持续部署工具链环境中。
• 持续的扫描已知的漏洞和配置错误，对象包括所有开源的和第三方组件。理想情况下，管理并维护一套完整的资产清单，便于完成对所有软件组件的分析。
• 不要尝试删除自定义代码中所有未知的漏洞，相反，应把开发人员看作放在最严谨和最自信的人。
• 鼓励尝试使用新的工具或方式，以减少与开发人员的摩擦，例如使用交互式应用安全测试（IAST）来取代传统的静态和动态测试。
• 把信息安全团队完美地融入DevOps进程中。
• 使用相同的统一的规范来处理所有自动化脚本、模板、图像和设计，并保证安全工作覆盖了所有的源代码。

DevSecOps的特点

• 安全融入：在软件开发的整个生命周期中都融入安全，从设计到上线之后的运维、监控阶段。安全贯穿始终。
• 安全左移(security shifting left)：传统开发模式下，安全都是在开发的最后阶段介入，甚至上线之前。在DevSecOps 模式下，安全在计划阶段就介入，在软件的生命周期中，可以看到左移了。
• 每个人都要对安全负责

这种嵌入安全的DevOps模式，除了DevOps所能带来的好处外，还有下文所示的其他好处。

为了从根本上解决安全团队的低效问题，高效团队会将信息安全 (InfoSec) 目标整合到日常工作中，团队可以实现更高水平的软件交付，并以更好的性能构建更安全的系统，这种想法称为“左移”。说白了，安全左移就是在软件开发生命周期的较早阶段，解决各种安全问题。因为，越早检查到安全漏洞，企业修复漏洞的成本就越低。

2. DevSecOps 的实施

DevSecOps 的实施可以从以下几个方面入手：

1) 组织(Organization)

火车跑得快，全靠车头带，组织的作用在任何一次转型中都是非常重要的。组织可以将如下实践加入到产品的全生命周期开发过程中：
文化建设：打造开发，运维，安全团队共担责任、相互信任、不推诿的文化。团队之间，团队内部都能形成大家认可和遵守的公约。比如，代码层面的漏洞由开发团队负责，基础设施的漏洞由运维负责等，这样团队之间安全责任比较明确。而针对于团队内部，比如开发团队，可以约定每一个开发人员提交代码之前必须要借助于安装在IDE中的安全插件，完成本地代码扫描和测试才能提交代码。

团队管理：组建规模合适的团队(比如two pizza team)，团队与团队之间的沟通要方便，快捷。这里所说的沟通，不仅指开发内部团队的沟通，运维团队内部的沟通，安全团队内部的沟通，更重要的开发，运维，安全这种跨部门团队之间的沟通。可以用实时通讯工具，如slack等实现团队内、跨团队的协同工作。

报告共享：与安全相关的报告，不管是成功案例还是失败案例，都应该各个团队共享，通过学习案例来改进系统设计，强化实施和增强事件响应能力。比如代码扫描报告，测试覆盖报告，镜像扫描报告等。

组织培训：对于安全来讲，意识比任何事情都重要。对于大多数从事软件开发的人员来讲，安全的认知仅限于代码层面，公司法规，安全审计，权限管理等都从未考虑。通过组织安全培训，可以让每个人明确安全的范围到底有多大，每个人担负的责任有哪些。

2) 流程(Process)

流程的设计可以遵循以下几点：
1) 流程意味着标准化，流程的制定应该由多团队共同参与，明确各个团队所承担的安全责任，以及对应阶段中的一些安全阈值设定，比如有高危漏洞，CI/CD Pipeline 就要终止，阻止代码的提交(持续集成阶段)或者上线(测试阶段)，只有高危漏洞解决了，才能继续往下走；如果测试覆盖率低于80%，就不可以部署此版本到生产线；已有漏洞的解决，在迭代内以50%的速率递减等等。这种适合多个团队的流程，方便管理的同时，也便于推广。

2) 如果能够自动化的，应该采用相应的工具来尽可能的实现自动化，以此来减少人工干预。比如可能由安全人员来手动执行的静态安全测试(SAST)，动态安全测试(DAST)，由测试人员手动执行的压力测试等，可以进行自动化改造，最好是融入到CI/CD Pipeline中。以期做到持续测试。

3) 流程应该高度透明，比如测试可以看到开发在代码提交前是否执行了单元测试，安全团队可以看到开发在代码提交之前是否执行了敏感信息检测，代码静态扫描等，还有覆盖率的阈值设置及结果都应该是公开透明的。这种透明，不是为了让各自找证据用来甩锅，而是要培养团队之间的相互信任。完全的可见性会驱动全面的信任。

4) 要将安全加入流程，形成端到端的安全交付流程，不是一蹴而就的。可以以小步开始，比如先在持续集成加入诸如代码扫描，敏感信息检测步骤，然后循序渐进，在持续测试，持续交付，持续部署，持续运维，持续监控中加入相应的安全步骤(后面章节会介绍)。每个步骤都应该形成一个闭环，通过反馈来做到持续改进。这种改进可以按照迭代的方式来进行。

3) 技术和工具(Technology & Tools)

技术和工具从来都是文化落地实践的最有力手段，也是一个企业的安生立命之本，优秀的技术和工具能够缩短软件开发周期，提高开发效率。同时这些技术和工具会进一步促进文化的发展。

可以将一些新兴的技术融入到现有流程，比如可以借助人工智能AI(人工智能)和ML(机器学习)，来帮助人们解决安全问题。AI和ML，可以通过对大量数据的深度学习和分析，发现既有漏洞中的假阳性漏洞，还能发现潜在漏洞。比如通过对log中大量404，400的分析，来确定是真的遭受到了恶意攻击还是应用程序自身或者外围子系统出现了异常。AI和ML的操作是自动、连续并且持续的。在某种程度上，能够减少团队的一些工作量。

有数据统计，现在能自动修复的漏洞数量不及发现漏洞数量的1%，借助于AI和ML，在2023年这种比例要达到10%以上。

也可以让既有的工具在DevSecOps模式中，发挥重要作用。其实，任何文化或者技术的落地，都可以从上述三个方面入手，分别对应的是”人，流程，工具”，也就是常说的PPT模型(People，Process，Tool)。

从业务角度更容易推动安全工作、科技工作，因为老板关注的是业务

3. 构建DevSecOps能力的最佳实践方案

分析

尽早确定 DevSecOps 是否适合某个特定的项目。
DevOps 作为一种方法论，它强调协作、敏捷性和快速迭代。然而，有些应用程序受限于隐私、法规和强制监管。这让开发流程与合规问题绑定在一起了，使得对产品的更改变得更加麻烦。在金融服务、医疗保健和制造业等一些垂直行业中，政府监管限制了对某些部分的生产环节可以采取的措施。例如：就像药品制造商生产环境变化后需要让FDA重新认证一样，某些软件更新后需要重新认证。由于这是一个昂贵、耗时的过程，会使生产系统在一段时间内处于脱机状态，因此这些认证往往会在其它停机时间窗口中提前安排。

然而，即使在受到严格监管的行业中，并非每个环节都受到这些限制。 实际上，一般来说，受限制或受监管系统的数量只占整个系统的小部分。DevSecOps 通常非常适合快速创新和迭代，在面向客户时也存在很大优势。

虽然 DevOps 对于安全风险管理者来说可能特别具有挑战性，但是当业务风险可以接受时，应该尽一切努力这样做。安全风险管理领导者有责任预先识别这些系统，然后与开发人员一起定义界限，以便在 DevOps 方法可能不太适合某些法规或安全需求的情况下指导项目。
相信企业有充分的理由采用DevOps，比如为了尽可能支持产品上市速度和提高发布质量等。在“DevOps报告状态”中，Gartner的CEB研究团队进行的一项调查显示，39%的IT领导者发现DevOps在一定程度上帮助满足了业务需求，61%的人说DevOps提供了广泛的帮助。对于安全风险管理负责人来说，重点应该是如何尽可能地使其工作。为那些不会带来不可接受风险的项目，寻找促进安全发展的方法。不做会对业务构成风险的决策，并与相关人员进行相关的沟通。
建议
① 与相关人员协商，确定DevSecOps可能不适合指导的时间。
② 在设定组建团队之前，将开发方法与项目的约束限制相匹配。
③ 严格监管或法律强制的地方并不适合DevSecOps，但是面对客户和合作伙伴的接口通常是很好的候选者。
通过将现有的安全开发工具扩展到整个生命周期，使其适应DevOps过程。

DevSecOps流程的各个阶段在较高层次上，可拆分为10个熟悉的细分步骤（参见图2）。

传统软件开发生命周期的许多安全工具仍将适用于DevSecOps，尽管它们运行的速度和频率可能非常不同。在某些情况下，当供应商没有修改其功能以适合自动化时(例如，API支持)，需要购买新工具以解决差距。
前置：DevSecOps中常常使用的一个短语，前置直接映射出战略方针，即将更多的测试转移到图2的左边，也就是在产品生命周期中越早越好。安全主管应该从计划开始，将重点放在用于早期测试和自动化检测的技术上，并将重点放在开发人员可以快速采取的可操作的小步骤上。

计划

计划很重要，解决安全和技术债务也很重要。确定在接下来的几个scrums中要解决的安全问题，并将它们添加到工作列表中。调查什么样安全需求需要开始解决，以及现在是否应该开始编写基础代码。在这个阶段，安全培训、威胁建模和工具培训这些事情也需要解决。您可以选择在接下来的几次scrum中支持一部分开发人员，让他们在团队其它成员在处理问题时进行培训。然后，在下一个计划周期中，将它们进行更改，直到所有的开发人员都能跟上进度。
即时响应是DevSecOps的一个关键要素，众所周知，Bug越早被发现，修复的成本就越低也越容易。在生命周期的接下来的几个阶段，Gartner强调前置哲学——即支持开发人员在这个过程中使用工具, 来获得清晰的、可操作的信息，并尽早获得反馈。
我们还建议已经接受过一些安全培训的开发人员，来回答基本安全问题，发现问题并作为IT安全的接口。

创建

强调向左移位的前置理念，支持直接在开发人员的集成开发环境(IDE)中集成相关安全工具和解决方案。许多安全工具供应商提供了一个“安全拼写检查器”，可以捕获常见的安全错误，并提供修复方案。但是，要小心避免无用的警告或无意的建议，这会无意慢慢让开发人员忽略该工具。为了避免这些问题，基于IDE的安全测试工具常常需要牺牲覆盖面来减少误报，而不像对整个系统进行静态分析测试那样识别许多问题。IDE插件并不能代替全面的静态分析测试。但是，根据DevSecOps的理念，它们可以在前期捕获简单的错误。
创建阶段的其它关键活动包括威胁建模、安全架构审核(针对跨多个迭代版本的新组件或更大的项目)和开源审查。所有这些活动都可以从具备安全能力的开发者那儿得到极大的便利。

验证

此处的 DevSecOps 扫描可以分为两大类：(1)扫描已知/重用代码中的已知漏洞和错误配置；(2)扫描自定义代码中的未知漏洞。在现代的DevOps开发中，应用程序中的大部分代码是“组装”的，而不是开发的，并且大部分代码是从开源和第三方库、框架和组件中重用的。首先扫描这些已知的漏洞和已知的错误配置将解决大多数风险。

可以在下载组件时使用具有修复功能的软件组合分析解决方案来强制执行组织的开源软件代码，从而可以主动进行验证，开发人员可以在项目开始时利用已经被验证的不存在问题的组件库。同时，在其它项目中也可以自动执行。

对于自定义代码的扫描，可以将传统的静态和动态应用程序安全测试工具(SAST和DAST)与SCA一起应用，以帮助理解项目对底层开源代码(如Struts)的依赖。随着DevOps广泛的应用，SAST供应商开始提供可以在几分钟内而不是几个小时内完成“快速扫描”，静态分析扫描仅查找最常见的错误。WhiteHat Scout就是一个典型的例子。这并不能满足对全面扫描的需求，全面扫描仍应定期运行。但更轻，更快的扫描才可作为DevOps组织的一部分，而不会对产品产生较重的影响。

交互式应用安全测试(IAST)是验证阶段的关键技术。IAST是DAST的一种改进形式，应用程序从内部进行检测，同时从外部执行扫描。IAST是在运行的代码上执行的，可以集成到整个DevOps过程中。在IAST中，代码经过检测，以便在测试或攻击时生成可用于提高安全性或响应攻击的数据。运行时应用程序自保护(RASP)是IAST产生的一种后置“右移”技术。虽然由于性能和兼容性问题，组织一直不愿意在运行时部署RASP，但这些问题在开发过程中不太突出（图3的左侧）。

注意，大多数IAST实现都需要应用程序在运行时进行检测(Java、.NET、PHP、Ruby、Python、Node)，并不是所有的供应商都支持所有的平台，所以IAST不可能在所有的应用程序上都能使用，更传统的DAST可能需要使用(假设它可以完全自动化，并且对开发人员透明地执行)。

验证阶段也是培训开发人员安全意识的好阶段，这些开发人员已接受过一些安全培训。 在安全培训中，可以训练开发人员阅读安全工具测试结果的能力，使之成为开发人员技能包的一部分。这有助于培训开发人员，让他们具备判断关键或高危安全问题以及低优先级问题（或误报）。让他们对发布产品的整体安全态势有更好的感觉，并能够提出在以后的scrum中需要解决的安全问题。

验证阶段的其他活动还包括应用协议和输入的模糊测试、应用程序漏洞相关(AVC)和移动应用程序安全测试(MAST)。

试运行

支持像IAST这样的解决方案，能够测试代码，并查看它对已知攻击以及模糊测试和chaos - monkey测试的反应。攻击是不确定性的，所以投入多少时间取决于你自己，但这恰恰是一种克服测试偏见和僵化思维的测试。当认为代码已经准备好时，应将其签入发布分支签名并加盖时间戳。这将有助于发布的完整性检查。Peach是开源性测试工具中很好的模糊测试工具。

模糊测试工具在应用于DevOps时具有独特的机会。与传统的测试不同的是，由于它是基于随机性的，所以没有具体的建议来决定要做多少。一个不确定的测试可能会运行数周而且永远不会发现漏洞，或者它可能会在第一次尝试中遇到漏洞，这些都没有办法提前知道。但是，因为DevOps强调迭代开发，所以代码通过这种测试运行的频率远远超过像瀑布这样的方法开发的代码。因为随机测试迭代地累积结果，所以随着时间的推移，这实际上通过更多次数的测试。

发布

检查时间戳签名并部署到CI / CD中。我们设想将在DevSecOps环境中使用多个签名，以反映不同类型测试的成功完成。例如，SCA完成的签名，用于IAST的另一个签名以及完整漏洞扫描的签名。如果未确认其已满足所需的安全性和合规性检查，则不允许将代码发布到生产环境中。

后置右移：强调不需要人工干预的持续监控和自动化工具。正如在开发过程中一样，我们强调了前置左移哲学，因为在这个周期中，更容易快速地纠正错误。
现在我们转向后置右移姿势，将焦点转移到攻击面。我们依靠技术来检测和保护应用程序免受威胁，以及应用程序“出错自动关闭”以尽可能保护其数据完整性。我们还需要有关现有网络环境的威胁情报信息，并希望将有关攻击，尝试将其反馈到流程中，以帮助我们了解下一个周期。
从应用程序中获取有关其环境的信息，以通知开发人员并将其转化为可操作的安全性改进，例如重新确定培训优先级，添加安全要求或根据此智能扩充威胁模型。

防护

在实例化配置时保证代码是我们所想要的，并且符合要发布到生产中的所有要求。常见的安全控制包括应用程序控制（白名单），强制服务器工作负载运行在指定机器上。此方法是工作负载安全的基础，应被视为工作负载保护的主要控制机制。纵深防御（DND）（DDoS防护等）也适用于此处。对于网络流量，通过部署身份检测和防御系统（IDPS），用户和实体行为分析（UEBA）或越来越多的下一代防火墙（NGFW）等其它技术能够观察连接或用户的行为并确定意图实现主动保护。

检测

安全负责人必须承认，并非所有漏洞都会在开发中被识别出来，而且有些漏洞将不可避免地进入生产阶段。任何应用程序开发方法（包括DevOps）都是如此，因此，无论开发方法如何，都需要对运行中系统架构问题进行快速检测。这里的应用程序依赖于RASP等技术，这些技术允许应用程序在受到攻击时通过自我保护或采用安全失败机制进行响应。

响应

现有的应用安全响应技术很多，但通常分为三类：
（1）依靠现有纵深防御保护应用程序。例如，许多网络硬件提供商将提供DDoS保护作为其路由器和交互机的一部分。这可以是响应威胁的好方法，前提是您已完成基本威胁建模，以使现有防御与您的应用程序相匹配。
（2）依靠更积极的技术，如RASP或WAF，可以检测应用程序正在经历的攻击类型，并设置适当的防御、警告或者记录攻击行为。RASP与IAST密切相关，IAST测试应该让应用程序知道用于成功保护自身的各种响应机制。
（3）依靠更加被动的响应，如应用程序加固，代码混淆和API网关。
任何情况下，来自攻击面的威胁情报对于采取正确防御措施，以及让开发团队了解有关应用程序在真实环境中响应情况都至关重要。确保能够通过安全信息和事件管理（SIEM），安全编排或监视，确保存在一个链路可以将信息返回“计划阶段”，使得开发人员根据信息调整系统，这一点至关重要。对该信息的响应可能是事件响应，运营调整或简单的安全技术债务。无论如何，它需要纳入整个开发流程。

预测

利用从检测和响应阶段收到的可视化和远程通信信息，我们希望能够借此预测系统需要构建的新对策。例如，不寻常的Web路径遍历模式表明攻击者可能正在利用尚未修补的潜在漏洞。
这需要从攻击面收集信息和分析数据，并反馈到产品计划阶段。这种可视化和大数据能力还可以用于支持后续类似项目的威胁建模和安全需求收集活动。此外，STIX和TAXII等标准越来越被认为是组织之间、执法部门和政府机构之间共享情报的有效方式。

第三方威胁情报库也成为此阶段的关键部分。例如，在Struts等广泛使用的框架中发现新漏洞时，此类信息可帮助开发在工作流程中优先处理修复漏洞。如果漏洞至关重要且受影响的应用程序/服务也至关重要，那么开发可以使用更新库或框架解决该问题，并确定新的自动发布的优先级。

自适应

将安全实践应用到 DevOps 中通常要分阶段进行，并且不可避免地会发现需要改进地方或漏洞。通过获取系统及其设备已收到的所有信息，并将其用于下一轮要求，包括关键事件的Scrum级别和不太紧急问题的规划级别等。
这还可能涉及某种程度的数据分析或数据缩减技术，以使信息成为可操作的活动。随着时间的推移，应用安全测试解决方案需要进行重新配置和改进，以更好地支持程序。这些解决方案会产生的大量研究结果往往会压倒安全和开发团队，因此需要对解决方案进行调整。
例如，需要调整SAST以关注更高价值的情报，并尽量抑制误报漏报等情况发生。持续的反馈和开发应成为安全团队的口头禅，它将使用收集的报警信息和统计数据以及相关人员的反馈信息来改进安全实践流程和工具，以便更好地支持未来的项目。

建议：

• 计划：威胁建模，安全需求收集和安全培训
• 创建：IDE安全插件
• 验证：SAST / DAST / SCA / IAST
• 预生产：Chaos Monkey，模糊测试，代码签名，IAST
• 发布：签名验证，完整性检查
• 预防：纵深防御措施
• 检测：RASP，渗透测试，UEBA
• 响应：RASP / WAF应用程序加固和代码混淆
• 预测：CVA，IoC / TI STIX TAXII
• 适应：技术债务/事件响应（IR）

  4. 自动化应用安全测试工具

  实施DevSecOps的关键挑战和第一要素是：“安全测试工具和安全控制过程能够很好的适应开发人员，而不是背道而驰”。安全团队想要将安全测试或安全控制成功的融入在DevOps中的前提是：不要试图改变程序员和测试人员的工作方法，也不要去增加他们额外的工作负担。否则你将破坏DevOps的协作性和敏捷性，注定会成为众矢之的，最终无法落地

如今，应用安全工具越来越早地出现在软件开发生命周期（SDLC）中。最理想情况下，它们会与组织的构建工具绑定，若存在有漏洞的部件，构建就会失败，或者至少会通知相关漏洞部件的发布经理。

对于开发经理和首席安全官（CSO）来说，这样的日常做法能满足六个 DevOps 安全要求中的五项：自动化、速度、覆盖率、检测与修复。
但第六个要求“预防”呢？这正是未来最佳实践要发挥作用的地方：让开发人员去防止有漏洞的开源部件进入到代码中。为此目的，安全主管应采取如下步骤：

1. 定义需自动实施的开源策略。 理想情况下，可利用公司的SCA工具设置任何策略，包括安全漏洞严重性、许可团队、漏洞级别及入库年限。
2. 要求开发人员只下载安全部件。 使用浏览器扩展，在开发人员欲下载有漏洞的开源部件时，发出警告。
3. 利用集体智慧 ， 采用同类公司已实施过的策略 ， 包括类似垂直行业（如健康和金融服务）开发者实施的策略。还可以利用相同规模组织实施过的策略。学习他人经验，占据主动，拒安全漏洞于代码之外。

   开源的安全工具

   | 工具名称 | 作用 | 作用阶段 | 地址 | | —- | —- | —- | —- | | git-secrets | 代码中敏感信息检测 | 编码阶段 | https://github.com/awslabs/git-secrets | | sonarqube | 代码质量检测 | 编码阶段，构建阶段 | https://www.sonarqube.org/ | | SAST/DAST相关工具 | SAST/DAST检测 | 编码阶段，测试阶段，运维阶段 | https://www.gartner.com/doc/reprints?id=1-6JR0995&ct=190419&st=sb | | vault | 敏感数据管理 | 任意阶段 | https://www.vaultproject.io/ | | Clair/Xray/Anchore | 镜像扫描 | 构建阶段中镜像打包环节 | Clair: https://github.com/quay/clair
   Xray: https://github.com/atom-archive/xray
   Anchore: https://anchore.com/ | | Terraform | 管理基础设施，基础设施即代码 | 部署阶段 | https://www.terraform.io/ |

5. DevSecOps 检查清单

Ledge提供DevSecOps检查清单，可以作为参考：
地址：https://devops.phodal.com/checklists/devsecops
数据来源于新思科技（Synopsys）的 《Building your DevSecOps pipeline:5 essential activities 》
下图列述了DevSecOps流水线的五个关键节点，每一个节点的用途，优势，关键推动因素和用例：

DevSecOps 检查清单列表
以下内容主要参考@hylerrix 大佬翻译的DevSecOps检查清单，发现部分翻译过于生硬，无法准确表达原文意思，鄙人斗胆重新翻译和总结清单列表，如果有所不足，请及时斧正，我将不胜感激。
DevSecOps 清单主要目的:
让开发人员专注于缺陷修复
利用IDE中的安全组件为研发人员的编码提供安全指导，在项目研发初期匹配源代码分析策略
促使组织在软件开发生命周期中安全左移
协助安全团队维护合规并集中的持续跟踪残余安全风险
* 允许 DevSecOps 团队集成检测工具链，降低安全成本

主要清单列表

• 预提交检查：将源码更改提交到源码库之前查找并修复常见的安全问题

  • 使用IDE中SAST组件进行扫描，在程序编码过程中为研发人员提供安全编码指导
  • 威胁建模，安全需求分析
  • 架构风险分析
  • 手动代码审查
  • 项目配置文件审查
  • 通过电子邮件通知应用程序安全团队或软件安全组（SSG），研发人员已经提交核心代码

• 提交时检查：生成并执行基本的自动化应用测试，测试结果快速反馈给提交变更的开发人员

  • 编译并构建源代码代码
  • 运行SAST工具：静态应用程序安全检测（SAST）
  • 自动化安全测试并收集指标
  • 构建被破坏时向相关团队发出警报

• 构建时检查：执行应用程序的高级自动化测试。这包括更深层次的 SAST、开源组件管理、安全测试、基于风险的安全测试、使用 PGP 签名软件并存储到软件仓库当中。

  • 使用更全面的 SAST 规则集进行扫描：例如 OWASP Top 10
  • SCA 供应链风险检测
  • 基于风险自动化安全测试并收集关键指标
  • 构建失败时及时提示相关团队

• 测试时检查：从制品库中选择最新最优版本进行构建，并将其部署到类生产或测试环境中，所有测试，包括功能、集成、性能、高级 SAST 和 DAST，都在此版本上执行。

  • 使用全量的 SAST 规则集进行扫描
  • 配置 DAST 规则并使用 DAST 工具对目标系统进行测试
  • 恶意代码检测
  • 模糊测试
  • 配置并自动化将制品库中最新最优版本进行部署，部署完成后进行自动化扫描、收集关键指标
  • 构建失败时及时提示相关团队

• 部署时检查：提供持续的保障，确保对生产环境的更改不会引起安全问题

  • 部署前
    • 自动化配置管理
    • 自动化配置运行环境
  • 部署后
    • 持续监控，自动收集应用安全指标
    • 指定安全扫描计划
    • 定期进行漏洞扫描
    • 协助安全运营SRC
    • 构建应急响应流程
    • 持续为DevSecOps团队提供威胁预警

6. DevSecOps CI/CD 实践案例

1. 基于云平台的一些安全工作

可以按照下图所示的模型来展开，基于云平台，容器交付模式下应用程序的安全工作，这也是个人实际工作的经验总结：

应用程序：应用程序是IT最核心的产物，也是价值的真正体现。安全是贯穿在应用程序的整个生命周期中的。常用的包括威胁建模，SAST，DAST，IAST，渗透测试。当然还有包括代码风格检测，性能、功能测试、压力测试等其他手段。从源码到产品，从静态到动态，都有相应安全手段。

SAST(Static Application Security Testing): 也称为白盒测试，通过分析应用的源码，字节码，二进制文件来发现安全漏洞，一般在软件的开发，测试阶段进行。

DAST(Dynamic Application Security Testing): 在应用处于运行状态时，通过模拟外部攻击，查看应用程序应对攻击的反应来确定，是否存在漏洞。一般在软件的测试或者维护阶段进行。

IAST(Interactive Application Security Testing)：兼具SAST和DAST特点的一种安全测试手段，也是这几年比较流行的一种方法，IAST还能够对于一些软件框架进行安全检测。

镜像 & 容器：可以说容器技术的发展极大的促进了云计算的发展，容器交付模式也大大缩短了应用程序开发周期。对于镜像，可以通过镜像扫描来扫描出镜像漏洞；镜像签名可以防止镜像被恶意篡改；制作没有漏洞的基础镜像，确保多个项目应用的基础镜像是安全的。最小权限确保了应用程序所在的容器是以非root权限运行的。

一般来说，一些镜像仓库都会带有镜像扫描功能，比如JFrog，阿里的ACR。也可以根据自己的需要利用开源产品搭建，比如Clair，Xray，Anchore，Trivy等。

云平台：云平台的安全是最大的安全，如果云平台不安全，那么在上面进行再多安全操作和防护都是没有意义的。在租用云平台的时候，必须要理清楚租用的云平台的网络，数据，租户管理等等，是否能达标公司要求的安全标准。

此外，像认证授权，漏洞管理，安全合规，敏感信息管理等安全手段适用于所有层次的工作。

2. 嵌入安全的CI/CD Pipeline

不同层面的不同手段，可以在软件开发的不同阶段展开，如下图：

上面讲到的安全左移(Security Shifting Left) 在上面的图中就比较容易理解了，相比于以前将安全滞后的开发模式，安全的发起往往在测试阶段，甚至更靠后；而现在在一开始的计划阶段就引入安全机制，比如在设计的时候就采用威胁建模方式，来识别、量化和解决与应用程序相关的安全风险；编码阶段可以利用IDE的一些安全插件来完成代码扫描。这样漏洞能尽早发现，反馈能尽早获取，漏洞也能尽早修复。

参考：

• git-secrets——从源头把控，防止敏感信息泄漏
• DevSecOps Secret Data 管理之 Vault—— 以更安全的方式管理Secret Data
• Kaniko——以一种更安全可靠的方式在Kubernetes平台上构建容器镜像
• https://www.synopsys.com/software-integrity/polaris.html【Polaris Software Integrity Platform】
• https://www.synopsys.com/blogs/software-security/devsecops-pipeline-checklist/【Building your DevSecOps pipeline: 5 essential activities】
• https://mp.weixin.qq.com/s/s6P7Ucv1V2oWknfkvucMOw【5个关键SAST活动，构建你的DevSecOps流水线 | IDCF】
• https://devops.phodal.com/checklists/devsecops【 DevSecOps 检查清单】
• https://devops.phodal.com/home【ledge home】
• https://www.redhat.com/zh/topics/devops/what-is-devsecops【DevSecOps 和 DevOps 有什么区别 ?】