从DevOps到DevSecOps的进化之路
本帖最后由 FYIRH 于 2022-4-13 16:36 编辑维基百科上，DevOps（Development和Operations的组合词）是指一种重视软件开发人员（Dev）和IT运维技术人员（Ops）之间沟通合作的文化、运动或惯例。通过自动化软件交付和架构变更的流程，使构建、测试、发布软件能够更加快捷、频繁和可靠。
现在，即使对了解过DevOps甚至是已经在使用这种研发模式的人来说，也难以定义到底什么是DevOps。有些观点认为，DevOps区别于传统的瀑布模式，基于敏捷模式，并将敏捷思想和实践从开发扩展到运维（也有激进的观点认为它完全不同于这两种研发模式），是一种新的思维模式和行动方法。
一、DevOps发展简史
在2008年举办的敏捷大会上，Patrick Debois和Andrew Clay Shafer首次提议讨论了“敏捷基础架构”这个话题。在第二年的敏捷大会上，两名Flickr员工做了题为“10+ Deploys per Day: Dev and Ops Cooperation at Flickr”（“每天10次部署”）的演讲，这可以看作开创了我们现在所说的DevOps的概念。
之后它激发着Patrick在同年10月于比利时根特市举办了第一届DevOpsDays，这代表着DevOps推广的开始。
从那以后，DevOps借助DevOpsDays在全球范围内传播，并于2019年达到顶峰—全球有80座城市在2019年举办了DevOpsDays。2019年10月28日到30日，全球各个国家和城市的DevOps活动组织者和推广者齐聚比利时根特市，举办了DevOpsDays十周年庆典。
相比欧美国家，DevOpsDays进入中国相对较晚，2017年3月18日北京举办了第一届中国DevOpsDays，并于接下来几年陆续在上海和深圳也分别举办了DevOpsDays峰会。
由于DevOpsDays对中国DevOps行业的影响，2018年7月22日，中国DevOps社区成立，并迅速发展到全国18个城市，通过本地化的DevOps Meetup等小型活动在各个城市继续推广DevOps。
除了DevOpsDays，另一个标志性事件是Alanna Brown在2012年起草了第一版年度 《DevOps现状报告》。从2012年起，这份年度报告就被DevOps业界和从业人士作为了解DevOps现状的参考以及DevOps发展方向的风向标。
另外，2013年Gene Kim出版了小说体的《凤凰项目》一书，通过描述一家正在经历DevOps转型的企业，生动形象地向读者介绍了转型过程中的思想碰撞，以及各种问题和相关的解决方法。
2016年，Gene Kim联合Jez Humble、Patrick Debois和John Wills合力出版了DevOps业界最具权威的经典著作：《DevOps实践指南》。图1-1给出了DevOps 10多年的发展历程。
（图1-1 DevOps发展史）
二、DevOps理念
DevOps的目标是提升整个研发效能，进行更便捷、更快速、更可靠的交付，从而提高产品竞争优势。DevOps模糊了以往研发模式中开发、测试、运维等岗位和角色的界限，加强了他们之间的协作，甚至鼓励将各个角色从传统的专家团队的组织结构，重新编制成全功能团队，用以加强协作（如图1-2所示）。
（图1-2 DevOps组织结构转变）
技术层面上，则通过流水线和一系列自动化机制、成熟可伸缩的基础设施（如云）等，使开发人员获得更高的效能，从而更加频繁且快速地将代码变为产品，并从这种快速中获得持续不断的反馈和验证，以获得更高的可靠性。
为了能够达到DevOps的目标：更便捷、更频繁地进行更可靠的交付，除了思维模式和文化以外，DevOps也需要一些技术和工具来支撑。也是得益于一些基础设施和工具的发展和成熟，才使得越来越多的公司能够践行DevOps。
从目前业界的最佳实践来看，DevOps技术和理念主要包括几个关键的要素：
[*]持续集成（Continuous Integration，CI）
[*]持续交付（Continuous Delivery，CD）
[*]微服务（Microservice）
[*]自动化测试
[*]基础设施即代码（Infrastructure as Code，隐含了虚拟化、容器、自动编排、配置即代码等技术和理念）
[*]监控和日志（Monitoring and Logging）等
业界围绕DevOps已经形成了一系列的工具集合和解决方案。
最终，通过文化意识的改变和自动化工具的使用，DevOps能够带来的价值也是很明显的，包括：
[*]更快的研发交付速度、更快的产品创新和尝试速度；
[*]有效地管理了更大规模的系统，并能够提供更可靠的质量；
[*]从文化角度，深化了研发各角色之间的协作。
不仅仅是互联网行业，包括很多传统的金融、零售、制造等行业也在尝试DevOps。
在如图1-3所示的传统模式下，在整个研发流程（需求、开发和测试）完成之后和上线前需要进行安全评审，以保证应用的安全性。因此，简单来说，整个软件开发的交付周期就是研发时长加上安全评估的时长。
（图1-3 从传统模式到DevOps模式）
在DevOps模式下，我们通过自动化、敏捷开发、团队协作、微服务设计等DevOps理念和技术手段，提高了研发效能。研发阶段的时长缩短了，从而也减少了整个交付周期的时长，提高了交付速度和效率。
然而，由于传统的DevOps模式没有考虑安全，因此上线前的安全评审时长并没有改变。从图1-3可以清晰地看出，在DevOps成熟的情况下，团队继续提高研发效能的瓶颈已经不在研发阶段，而是在上线前的安全评审阶段。
那么，如何在DevOps模式下进一步改进研发效能，提高交付效率呢？另外，从安全的角度考虑，瀑布模式下的传统应用安全模式（比如SDL）已经无法跟上DevOps模式下越来越快的交付速度了，因此需要摸索出一套适合不停迭代和快速交付的全新应用安全模式的方法论。
三、从DevOps到DevSecOps
上一节我们用一个图简单描述了从传统研发模式到DevOps模式的转变。然而，传统DevOps主要考虑速度和质量，并没有考虑信息安全。所以，在DevOps比较成熟的情况下，信息安全就变成了研发效能继续改进的瓶颈。
DevSecOps的最终目的就是通过安全左移到开发测试团队，使安全评审阶段的时长变短，从而进一步缩短交付周期（如图1-4所示）。并且它可以在更早的阶段发现并修复安全漏洞，从而减少上线前发现安全漏洞的返工成本。
（图1-4 从DevOps模式到DevSecOps模式）
DevSecOps是Gartner在2012年就提出的概念，其原始术语是DevOpsSec。2017年RSA峰会之后，DevSecOps开始成为世界热门话题。DevSecOps延续了DevOps的理念，其设计与执行仍然处于Agile的框架之下。
DevSecOps的目标是将安全嵌入到DevOps的各个流程中（需求、架构、开发、测试等），从而实现安全的左移，让所有人为安全负责，将安全性从被动转变为主动，最终让团队可以更快、更安全地开发出质量更好的产品。
所谓安全左移，在实践中就是为了让团队对他们开发的内容负责，通过将安全等工作（比如测试安全）从部署前的安全评审阶段左移到更早的阶段，从而更早、更快地发现并解决安全问题，而不是等到几天后部署时才发现，或者几个月后再发出渗透测试报告。
DevSecOps的出现并非偶然，它是软件持续交付演进的必然产物。在这种新型软件交付模式下，安全行为会散落在软件交付的各个阶段，而安全的职责也会落在各个阶段的参与者身上，而不再是主责落在安全团队身上。
DevSecOps可以给研发效能提供诸多好处，主要表现在以下三个方面（见图1-5）：
（图1-5 DevSecOps相比DevOps的好处）
[*]交付更快
DevSecOps通过自动化安全工具扫描，无感地左移了部分传统模式中在上线前最后阶段进行的安全扫描工作，使整个交付周期变得更短，交付速度因此变得更快。
比如在图1-5中，由于安全评审阶段时长的减少（T7），交付周期从DevOps模式下的T1，变成了DevSecOps模式下的“T1–T7”。
[*]节省成本
DevSecOps由于在SDLC前期阶段发现并且修正安全隐患和漏洞，避免了传统模式中在上线前最后阶段进行安全扫描发现高危安全漏洞后进行的返工，从而从流程上节省了成本。
比如在图1-5中，在上线前发现高危安全漏洞返工修复安全漏洞后，整个开发、测试和安全评审流程又要重新走一遍，因此额外消耗的成本就是T2时间下的人力。
在DevSecOps模式下，由于安全左移到了开发或者测试阶段，因此，如果高危安全漏洞在开发阶段被发现，那么额外耗费的人力也仅仅是开发时长T4下的人力，节省下来的是“T2–T4”时长下的人力。
而如果高危安全漏洞是在测试阶段被发现的，那么返工额外消耗的人力就是“T4 + T5”下的人力，因此节省下来的就是“T2–T4–T5”下的人力。
[*]控制风险
DevSecOps减少了开发团队对安全部门/团队的依赖，通过安全左移让开发团队具备发现和修正部分安全隐患和漏洞的能力。
另外，在传统模式下，安全部门/团队往往扮演“警察”的角色为企业的安全提供保障，因此有时会因为安全隐患或者风险从而阻止或者延迟开发团队交付上线。基于这种关系，因为大家的目的不同，开发团队和安全团队的关系往往并不是那么融洽，有时甚至会产生矛盾。
然而，DevSecOps的目的是通过将安全左移最终让所有人为安全负责。因此，将不再有安全“警察”的角色来监督开发团队，而是开发团队为自己开发的产品的安全性负责。
虽然DevSecOps是DevOps演进的必然结果，但是在DevSecOps实践落地的过程中，仍然面临来自技术、流程、人和文化诸多方面的困难和挑战（如图1-6所示）。其中技术挑战主要来源于两个方面：
[*]由于DevSecOps是一个全新的概念，因此市场上可选择的开源和商用工具并不太多。
[*]现有的很多DevSecOps工具也并不成熟（比如误报率、专业性要求高等问题），所以也增加了DevSecOps工具在推广和使用过程中的难度。
（图1-6 实现DevSecOps的挑战）
相比来自技术的挑战，人和文化方面的挑战则影响更大。对于程序员来说，他们的主要工作是写代码，所以很多程序员可能缺乏相关的安全意识，并且简单地认为安全不是他们的职责，而是安全团队的职责。
美国威胁检测公司Threat Stack针对北美大中小企业200多名安全、开发和运维专业人员的一项调查和报告表明，DevSecOps仍然停留在理论阶段。造成这种情况的主要原因一是信息安全知识和能力并没有得到普及，二是缺少高层的支持，业务领导者甚至对此并不鼓励。
报告中指出，只有27%的运维团队和18%的开发团队配备了安全专家；超过44%的开发人员没有接受过任何安全编码的培训；42%的运维人员没有接受过基本安全实践方面的培训。
因此，就算有些开发人员有安全方面的意识，但他们可能不具备安全编码和修复安全漏洞的能力，所以需要相关的安全培训。然而，信息安全毕竟是一门独立的学科，因此也增加了程序员的学习成本。
最后，与DevOps刚出现时一样，作为一个全新的概念，DevSecOps的理念还没有得到普及，因此很多时候得不到高级管理层的支持。
报告中也指出，52%的公司承认会削减安全措施，以便在截止日期前完成业务目标。68%的受访企业CEO不允许因为安全问题让业务交付变慢。从这个报告可以看出，如果没有管理层自上而下的支持，DevSecOps的推动会非常缓慢，甚至停滞不前。
针对以上种种挑战，DevSecOps也给出了对应的最佳实践（见图1-7），以便进一步在企业里进行推广。比如在技术层面，DevSecOps最佳实践强调自动化信息安全，甚至将安全扫描进一步左移到IDE阶段，更早发现并修复问题，从而节省成本。
（图1-7 DevSecOps最佳实践）
另外，安全指标也可以作为质量门禁，用来保障交付的安全性。人和文化层面强调持续培训和安全意识的培养，以及DevSecOps负责人和开发团队里DevSecOps“专家”等新角色的定义。流程层面强调定期的代码审查、红蓝对抗，通过DevSecOps度量发现研发过程中的瓶颈，以及评估DevSecOps改进的效果。（转自大数据DT，作者周纪海 周一帆 等）
页:
[1]