关于DevSecOps，你应该知道这些

一、什么是DevSecOps

软件的开发从来都不是某个部门或者团队的单打独斗，为了联合开发和运维，DevOps诞生了；同样地，为了联合安全和运维，SecOps诞生了；三人为众力量大，于是开发、运维、安全强强联手，就诞生了DevSecOps。

对比DevOps的概念(在抽丝剥茧DevOps一文中有详解)，可以将DevSecOps理解为:

DevSecOps 描述了一个组织的文化和具体实践，这些文化和实践能够打破开发、安全、运维部门之间的壁垒，使得开发、运维和安全能够通过通力协作和敏捷开发来提高工作效率，实现软件的更快速、更安全交付。

二、DevOps不香了吗

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

其实，安全一直以来都是IT行业的重要一环，但是大家通常都很少提及安全这块儿，原因是什么呢？

• 滞后型：在以前的开发模式中，安全往往是置于软件开发的最后阶段，在半年甚至一年发布一个版本的时候，这种模式的弊端并没有显得太突兀。就像凤凰项目一样，安全团队甚至有好几个月的时间去完成安全工作。
• 甩锅型：我是开发，安全与我无关；我是测试，安全与我无关；我是安全，漏洞是开发引入的，测试没有测试出来，安全与我无关。
• 狭隘型: 安全问题只有一种：被黑客利用漏洞攻击了。其余的配置错误，敏感信息泄漏，权限管理混乱，都不是安全问题，只是因为不小心。
• 侥幸型: 全世界这么多软件，就算被攻击，怎么会轮到我呢？
• 势利型: 增加安全必然增加成本，雇佣专业的安全人员，选用专业的安全工具，进行专业的安全测试。然而，能给我带来的收益有多少？

在市场变化如此之快的今天，加之企业上云已成历史之趋。据Gartner调查，利用漏洞的平均时间，已经从以前的45天缩短到了如今的15天。这也就意味着只有两周左右的时间留给团队来修复系统。所以前那种留给安全团队足够的时间去解决安全问题的时代已经不复存在了，如果还本着上述思路去做产品，很容易造成在网络上”裸奔”的局面。

安全问题必须从一开始就着手。不光要跑得快，还要跑得安全，否则就像开车，超速还不系安全带，结果真的很可能就是”开车一时爽，亲人两行泪”。这也就是为什么现在要把安全融入到DevOps，完成DevOps到DevSecOps的转型。

三、DevSecOps 更香

3.1 DevSecOps 的最大特点

DevSecOps 相比于DevOps最大的一个特点就是: 安全。安全融入和安全左移是两个主要方面：

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

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

3.2 DevSecOps 的好处

1) 风险可控

在产品设计之初就引入安全机制，在产品全生命周期的都实施风险管控，漏洞管理，安全检测。可控的风险能增加产品上线的信心和保证产品的质量。这也是软件开发所一直追求的。

2) 降低成本，提高效益

在产品开发甚至计划阶段就引入安全机制，能够做到早检测，早修复。就像新冠病毒一样，早发现，早治疗，早康复，避免了病症加重带来的救治压力与死亡风险的增加。与此同时，安全的产品总是受欢迎的，也会带来更多的客户。虽然在初期，不会在短期内看到明显的效果，但是DevSecOps是个长期的目标，从长远看，是能够做到降低成本，提高效益的。

测试领域有一个原理：在需求阶段发现并修复一个缺陷或问题如果如需要花费一美分，那么在开发阶段修复同样的问题则需要花费十美分；在测试阶段话花费一美元，在生产环境则需要十美元。

可以看出在软件开发生命周期中，越靠后，修复缺陷的成本就越高。

3) 安全事故的恢复时间缩短

不同于以往，发现漏洞时，需要在每套环境上对漏洞逐个修复。如今采用不可变基础设施的时候，直接对部署环境所对应的镜像做修复之后，重新生成多套安全的环境(这里面的不可变基础设施以及包含的pet/cattle的模型，会在后续的基础设施即代码，也即Infrastructure as Code 中会详细介绍)。

根据Red Hat的统计数据，他们的客户在不采用DevSecOps模式时，在生产环境上通过动态扫描发现漏洞后，修复漏洞的平均时间是174天，但是采用DevSecOps模式后，时间变为92天；如果是开发阶段就用静态扫描发现漏洞，不采用DevSecOps模式的时候，修复的平均时间是113，而采用DevSecOps模式后，时间变为52天。

4) 团队协作、安全意识、责任意识的提高

在DevSecOps 模型中，安全不再仅仅是安全团队的工作，而是人人为安全负责。开发，运维，安全团队需要通力协作来解决已知安全问题，并积极发现潜在的安全问题。

3.3 DevSecOps 的实施

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

1) 组织(Organization)

火车跑得快，全靠车头带，组织的作用在任何一次转型中都是非常重要的。组织可以将如下实践加入到产品的全生命周期开发过程中：

• 文化建设：打造开发，运维，安全团队共担责任、相互信任、不推诿的文化。团队之间，团队内部都能形成大家认可和遵守的公约。比如，代码层面的漏洞由开发团队负责，基础设施的漏洞由运维负责等，这样团队之间安全责任比较明确。而针对于团队内部，比如开发团队，可以约定每一个开发人员提交代码之前必须要借助于安装在IDE中的安全插件，完成本地代码扫描和测试才能提交代码。
• 团队管理：组建规模合适的团队(比如two pizza team)，团队与团队之间的沟通要方便，快捷。这里所说的沟通，不仅指开发内部团队的沟通，运维团队内部的沟通，安全团队内部的沟通，更重要的开发，运维，安全这种跨部门团队之间的沟通。可以用实时通讯工具，如slack等实现团队内、跨团队的协同工作。
• 报告共享：与安全相关的报告，不管是成功案例还是失败案例，都应该各个团队共享，通过学习案例来改进系统设计，强化实施和增强事件响应能力。比如代码扫描报告，测试覆盖报告，镜像扫描报告等。
• 组织培训：对于安全来讲，意识比任何事情都重要。对于大多数从事软件开发的人员来讲，安全的认知仅限于代码层面，公司法规，安全审计，权限管理等都从未考虑。通过组织安全培训，可以让每个人明确安全的范围到底有多大，每个人担负的责任有哪些。

2) 流程(Process)

流程的设计可以遵循以下几点：

• 流程意味着标准化，流程的制定应该由多团队共同参与，明确各个团队所承担的安全责任，以及对应阶段中的一些安全阈值设定，比如有高危漏洞，CI/CD Pipeline 就要终止，阻止代码的提交(持续集成阶段)或者上线(测试阶段)，只有高危漏洞解决了，才能继续往下走；如果测试覆盖率低于80%，就不可以部署此版本到生产线；已有漏洞的解决，在迭代内以50%的速率递减等等。这种适合多个团队的流程，方便管理的同时，也便于推广。
• 如果能够自动化的，应该采用相应的工具来尽可能的实现自动化，以此来减少人工干预。比如可能由安全人员来手动执行的静态安全测试(SAST)，动态安全测试(DAST)，由测试人员手动执行的压力测试等，可以进行自动化改造，最好是融入到CI/CD Pipeline中。以期做到持续测试。
• 流程应该高度透明，比如测试可以看到开发在代码提交前是否执行了单元测试，安全团队可以看到开发在代码提交之前是否执行了敏感信息检测，代码静态扫描等，还有覆盖率的阈值设置及结果都应该是公开透明的。这种透明，不是为了让各自找证据用来甩锅，而是要培养团队之间的相互信任。完全的可见性会驱动全面的信任。
• 要将安全加入流程，形成端到端的安全交付流程，不是一蹴而就的。可以以小步开始，比如先在持续集成加入诸如代码扫描，敏感信息检测步骤，然后循序渐进，在持续测试，持续交付，持续部署，持续运维，持续监控中加入相应的安全步骤(后面章节会介绍)。每个步骤都应该形成一个闭环，通过反馈来做到持续改进。这种改进可以按照迭代的方式来进行。

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

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

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

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

也可以让既有的工具在DevSecOps模式中，发挥重要作用。具体的实践细节可以参考下面即将讲述的第四部分。

其实，任何文化或者技术的落地，都可以从上述三个方面入手，分别对应的是”人，流程，工具”，也就是常说的PPT模型(People，Process，Tool)。

四、DevSecOps CI/CD 实践案例

4.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等。

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

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

4.2 嵌入安全的CI/CD Pipeline

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

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

4.3 一些开源的安全工具

五、路漫漫其修远兮，吾将上下而求索

DevOps的发展已过十多年，但是安全的发展却一直伴随着IT行业的发展。在DevOps中融入安全本就不是一蹴而就的事情，需要软件开发生命周期内的所有人都参与进来。绝对安全是不存在的，也是做不到的，但是我们可以用持续改进的方式去避免更多的由人祸引发的安全事故。我相信人类终将战胜这次疫情，也相信，我们有能力让我们的产品变得更加安全！

参考资料

https://devops.com/the-state-…

https://www.recordedfuture.co…

https://medium.com/@Joachim86…

https://docs.microsoft.com/en…

https://www.redhat.com/en/top…

https://www.recordedfuture.co…

https://www.plutora.com/blog/…

https://www.gartner.com/doc/r…

https://devops.com/devops-and…

https://www.kiuwan.com/blog/t…

来源：CIO Talk