共计 6243 个字符，预计需要花费 16 分钟才能阅读完成。
一、什么是 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 一些开源的平安工具
| 工具名称 | 作用 | 作用阶段 | 地址 |
|---|---|---|---|
| git-secrets | 代码中敏感信息检测 | 编码阶段 | https://github.com/awslabs/gi… |
| sonarqube | 代码品质检测 | 编码阶段、构建阶段 | https://www.sonarqube.org/ |
| SAST/DAST 相干工具 | SAST/DAST 检测 | 编码阶段、测试阶段、运维阶段 | https://www.gartner.com/doc/r… |
| vault | 敏感数据治理 | 任意阶段 | https://www.vaultproject.io/ |
| Clair/Xray/Anchore | 镜像扫描 | 构建阶段中镜像打包环节 | Clair: https://github.com/quay/clair 和 Xray: https://github.com/atom-archi… 和 Anchore: https://anchore.com/ |
| Terraform | 治理基础设施，基础设施即代码 | 部署阶段 | https://www.terraform.io/ |
五、路漫漫其修远兮，吾将上下而求索
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
作者：马景贺
5 月每周四晚 8 点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址
- 0506 朱少民《如何最大化软件测试效力》
- 0513 陈琦《数据驱动测试》
- 0520 陈霁《没错，去 QA 是提高质量最无效的办法！》
- 0527 施慧斌《DevOps 实际之继续测试》