DevOps、DevSecOps、ShiftLeft、SecurityPosture、CloudNative……当您谈论现代应用程序开发生命周期时，您总是会听到这些术语。它们在用作解释复杂过程的框架时是积极的，但在误用或滥用时是有害的。无论是有意还是无意的误用，用户在面对这些流行语时往往无法理解其背后的真正含义。DevOps和DevSecOps是滥用和误用的典型案例，已造成许多负面影响。自2009年首次提出以来，DevOps所涵盖的内容经历了多次迭代，其负面内涵往往来自于沟通背景中各种不切实际的乌托邦元素，以及难以真正实现的理想假设。尽管许多组织坚持以DevOps为中心，但很少有人能真正准确地定义它。没有适当的实践，DevOps对团队和企业的承诺将无从谈起。DEVOPS和DEVSECOPS之间有什么区别？DevOps的实施依赖于五个核心组件：敏捷框架、一次构建/随处运行的开发方法、一切都是代码、自动化、通信和协作。当DevOps普及时，它可以加快部署速度、降低故障率并增强弹性。而这一切都将帮助团队乃至公司创造出周期更短、适应性更强、质量更好的产品。但这也给我们提出了新的问题——如何将安全方面的考虑融入其中？DevSecOps的重点是以满足安全要求的方式扩展DevOps的核心原则。理解DevSecOps的一个重要方法是分解核心DevOps组件并查看在何处插入安全元素是合适的。(1)敏捷框架-敏捷方法仍然是当今软件开发生命周期(SDLC)的主要内容。与瀑布式开发方法相反，敏捷开发强调短周期和小变化的结合，确保组织能够快速响应客户的反馈。然而，敏捷框架面临着安全风险。运营反馈从何而来？是否符合安全要求？此类框架在加快开发周期方面做得很好，但通常受到操作和安全要求的限制。开发人员希望在快速行动和开拓进取的同时，将操作和安全性交给支持工具。总而言之，Agile专注于提高开发人员的行动速度也取得了不错的效果；但重点仅在于开发本身，所有运营和安全要素都已成为事后的想法。(2)构建一次，随处运行——容器技术将SDLC提升到一个新的水平。作为一项真正具有颠覆性的技术，容器使开发人员能够独立于运营资源进行编码、构建、运行和测试。现在，由于开发人员不必担心设置操作环境，他们可以更专注于测试、安全性和扩展性。使用容器技术，一切都可以包含在一个Dockerfile中并在任何地方运行。在提交最终图像之前，开发人员根本不需要接触操作；但在整个过程中，运营部门仍然在不知不觉中为开发人员提供支持。尽管开发和运营之间存在这种隔离，但容器本身仍然是一项重大成就，没有编排工具的指导，容器就无法工作。至此，我们就要请来下一位重量级嘉宾——Kubernetes。Kubernetes使组织能够有效地管理、扩展、观察和插入容器。它将Dockerfile的要求抽象为可以管理和扩展的显式对象。这种声明式抽象需要开发人员与运维人员进行沟通才能有效地使用Kubernetes。随着时间的推移，双方的交流会逐渐升级，最终包括安全问题。(3)自动化——那么安全或运营团队如何要求或约束开发人员？通过在不影响开发速度的情况下向开发人员提供直接反馈，自动化成为启用DevSecOps的关键。单元测试、代码分析和图像扫描已成为常用工具，可以轻松添加到持续集成(CI)管道中，即时通知开发人员必要的更改。在开发团队的协作下，这些更改可以快速集成到现有管道中。运营和安全团队应该明白，他们越早提供自动反馈机制，开发人员就能越早适应这种新的协作模型。这对于安全团队来说极其重要。在组织中，安全团队往往被视为一个“令人不安”的存在，因为这些家伙总是强调所谓的“100%安全系统”是不可能实现的。但有效的DevSecOps并不是那么简单粗暴。借助新工具和最佳实践，安全团队可以为开发人员提供稳定安全的基础镜像，从而不断提高代码质量。安全团队还可以在管道中引入自动检查机制，以监控任何包含提权行为的YAML文件、不匹配网络策略的命名空间或存在漏洞和风险的容器镜像。(4)一切皆代码——Kubernetes和其他编程语言的声明性特性极大地提高了基础设施和应用程序的可重用性和可理解性。YAML文件将帮助团队准确了解容器将如何按预期运行。所有的时钟时间、卷挂载、秘密注入等行为都可以通过这个文件和注释来观察。这种方法还允许成功地记录代码，以便随时进行版本控制和迭代更改。但即使使用最新最好的工具，未能正确记录和分类特定问题仍然是徒劳的。如果没有明确的文档，就很难在团队之间分享经验教训。在尝试新的管道配置时，每个团队吸取的教训可能对其他团队具有决定性意义。因此，使用代码和版本控制系统来充分展示更改并允许基于它们进行讨论。否则，随着单个团队的快速推进，知识共享体系将分崩离析，团队之间也难以充分沟通。(5)沟通和协作——如果团队和个人之间没有充分的沟通，所有的代码、应用程序和安全更改都是毫无意义的。IT部门最常忽视的沟通要点之一是对意图的清晰解释。DevOps和DevSecOps难以充分发挥其潜力的一个核心原因是，各方往往没有正确理解所涉及行动的意图。安全团队并没有试图阻碍开发，他们只是在做自己的工作并确保应用程序安全。虽然开发团队也很关心安全问题，但摆在他们面前的头号问题始终是如何让新功能在截止日期前顺利上线。组织必须努力弥合团队之间的差距，专注于吸取教训，鼓励合理的失败，并设定切合实际的后续目标。从文化的角度来看，这种变化通常是自上而下推动的。在重视这种方法的组织中，开发、运营和安全团队愿意讨论哪些意图是合法的，哪些不是，并且愿意设身处地为对方着想。DEVSECOPS将何去何从？总之，DevSecOps对我们提出了以下几个关键需求：需要在快速迭代的软件开发生命周期中建立嵌入式自动安全检查机制。可重用的开发环境具有同类型的安全控制机制版本控制CI管道根据组织或团队的职能范围改变管道，从而改进事件后的安全调查流程完善的文档，最好将安全实施为以声明方式编写代码鼓励创新并拥抱由此产生的失败文化请注意，本文并未明确指定任何特定工具。DevSecOps代表的是一种文化变革，其背后的思维转变并不局限于任何特定的工具。当然，大家也应该尽可能采用支持协同解决问题的工具，包括保证良好的可移植性、可观察性，以及提供通俗易懂的文档。最重要的是，获得团队的控制权以构建可以在团队之间共享的上下文材料。结合各种成功案例和理论层面的巨大潜力，相信DevSecOps不断发展的浪潮终将成为我们手中的有力武器。
