DevOps与DevSecOps有何区别？

[[407274]]

DevOps与DevSecOps就是滥用与误用之下造成不少负面影响的典型案例。自2009年被首次提出以来，DevOps所涵盖的内容已经发生过多次迭代，其中的负面含义往往源自交流背景中种种不切实际的乌托邦元素、以及难以真正落地的理想假设。尽管不少组织坚称自己以DevOps为中心，但却几乎没多少人能真正准确地做出定义。没有正确实践作为前提，DevOps向团队及企业做出的承诺也将无从谈起。

DEVOPS与DEVSECOPS之间有何区别?

DevOps的实现依赖于五大核心组件： 敏捷框架、 一次构建/随处运行的开发方法、一切即代码、自动化、沟通与协作。

在全面普及之后，DevOps能够加快部署速度、降低故障率并增强恢复能力。而这一切都将帮助团队乃至企业打造出周期更短、适应性更强、质量更好的产品。但这也给我们提出了新的问题——如何把安全考量融入进去?DevSecOps的重点，正在于以符合安全要求的方式扩展DevOps核心原则。

理解DevSecOps的一种重要方法，在于拆分DevOps核心组件并审视适合在哪里插入安全要素。

(1) 敏捷框架——敏捷方法仍然是当今软件开发生命周期(SDLC)的主要内容。与瀑布式开发方法相反，敏捷开发更强调短周期加小变化的组合，确保组织能够针对客户反馈做出快速反应。

然而，敏捷框架面临着安全隐患。运营反馈从何而来?是否符合安全要求?这类框架在加快开发周期方面确实表现不错，但却又常常受制于运营与安全要求。开发人员希望将运营与安全工作交给支持性工具负责，自己则快速行动、一路奋勇向前。

总而言之，敏捷专注于提升开发人员的行动速度，也取得了不错的效果;但其中的重点只有开发本身，一切运营与安全元素都成为事后才考虑的元素。

(2) 一次构建、随处运行——容器技术让SDLC更上一层楼。作为一项真正具有颠覆性的技术，容器使得开发人员能够独立于运营资源之外进行编码、构建、运行以及测试。如今，由于开发人员不必分神设置运营环境，他们可以将更多精力集中在测试、安全与扩展方面。利用容器技术，一切都可由Dockerfile所容纳并实现随处运行。在提交最终镜像之前，开发人员根本不需要接触运营工作;但在整个过程中，运营仍然始终存在、在不知不觉中为开发者提供支持。

虽然存在这种开发与运营之间的隔绝，容器本身仍然是一项重大成就，而容器的起效又离不开编排工具的引导。

到这里，我们要请出下一位重量级嘉宾——Kubernetes。

Kubernetes使组织得以高效管理、扩展、观察并接入容器。它将Dockerfile的需求抽象为可以管理及扩展的明确对象。这种声明式抽象要求开发人员与运营人员开展沟通，进而有效运用Kubernetes。随着时间推移，双方的交流将逐渐升级、最终将安全问题纳入进来。

(3) 自动化——那么，安全或者运营团队又该如何要求、或者说约束开发人员?

通过在不影响开发速度的情况下向开发人员提供直接反馈，自动化成为实现DevSecOps的关键所在。单元测试、代码分析与镜像扫描已经成为可轻松被添加至持续集成(CI)管道的常见工具，即时向开发人员通报必要修改。在开发团队的协作下，这些变更可以快速被集成至现有管道当中。运营与安全团队应该明白，他们越早提供自动化反馈机制，开发人员就能越早适应这种新的协作模式。

这一点对安全团队来说极为重要。在组织当中，安全团队往往被视为一种“令人心烦”的存在，因为这帮家伙总在强调根本不可能实现的所谓“100%安全系统”。但行之有效的DevSecOps可不是这么简单粗暴。

借助新的工具与最佳实践，安全团队可以为开发人员提供稳定且安全的基础镜像，由此不断提升代码质量。安全团队还可以在管道中引入自动检查机制，监控一切包含权限提升行为的YAML文件、未匹配网络策略的命名空间或者存在漏洞及风险的容器镜像。

(4) 一切即代码——Kubernetes及其他编程语言的声明性质，极大提高了基础设施与应用程序的可重用性与可理解性。YAML文件将帮助各团队准确理解容器如何才能发挥预期作用。时钟时间、卷挂载以及secret注入等一切行为都可通过这个文件及注释进行观察。这种方法还让代码成功呈现为文档的形式，以供随时进行版本控制并实现迭代变更。

但即使有了最新、最好的工具，如果无法正确记录和编目具体问题，一切努力仍然可能是徒劳的。没有清晰的文档，将很难跨团队分享经验教训。而在尝试新的管道配置时，各团队掌握的经验教训很可能对其他团队有着决定性的指导作用。因此，请使用代码与版本控制系统充分展示变更内容，并允许各方据此开展讨论。否则随着单一团队的快速推进，知识共享体系将土崩瓦解，各团队间再难开展充分交流。

(5) 沟通与协作——如果团队和个人间不进行充分沟通，那么一切代码、应用程序与安全变更都将毫无意义。而IT部门中最常忽视的一大沟通要点，在于对意图的明确解释。

DevOps与DevSecOps之所以难以发挥其全部潜力，一大核心原因就是相关行动的意图往往未被各方正确理解。安全团队并不是要阻碍开发工作，他们只是在完成自己的本职工作并保证应用程序安全。而开发团队虽然也关心安全性，但他们面前的头号难题永远是如何在限期之内让新功能顺利上线。

组织必须努力弥合各团队之间的差距，专注于吸取教训，鼓励合理的尝试失败，并设定出切合实际的后续目标。从文化角度来看，这种变化通常由高层自上而下推动。在重视这种方法的组织当中，开发、运营及安全团队会乐于讨论哪些意图较合理、哪些不合理，并愿意站在对方的立场上考虑问题。

DEVSECOPS将向何处去?

总而言之，DevSecOps向我们提出了以下几项重点要求：

• 要求在快速迭代的软件开发生命周期中建立嵌入式自动安全检查机制
• 可重用的各开发环境间具有同类型的安全控制机制
• 版本控制CI管道
• 以组织或团队职能范围为边界进行管道变更，借此改善事件后的安全调查流程
• 完善的说明文档，最好以声明式方法实现安全即代码
• 鼓励创新，并接纳由此带来的失败文化

请注意，本文没有明确指定任何具体工具。DevSecOps代表的是一种文化变革，其背后代表的思维方式转变不限于任何特定工具。当然，大家也应尽可能采用支持协作解决问题的工具，包括保证其具有良好的可移植性、可观察性并提供简单易懂的说明文档。最重要的，还有获得团队的支配以建立起可跨团队共享的上下文素材。

结合种种成功案例与理论层面的巨大潜能，相信DevSecOps这波不断发展的浪潮终将成为我们手中的有力武器。