6.7 在DevOps和DevSecOps中的应用

随着云和云原生架构的出现并继续流行，另一个趋势发生了：从传统的瀑布式软件开发到DevOps时代，或者最近的DevSecOps时代的转变。在不进行哲学辩论的情况下，DevOps可以概括为一套弥合软件开发和操作之间鸿沟的实践，或者在DevSecOps、软件开发、安全和IT操作的情况下。这场运动可以追溯到21世纪初，比如 Patrick Debois，Andrew Shafer，Gene Kim和Jez Humble，他们对生态系统做出了贡献。这与云计算的发展相吻合，组织也越来越多地使用云原生技术，通过敏捷和DevOps方法来促进业务结果。为了更好地理解DevOps，我们推荐诸如《DevOps Handbook (2nd edition, IT Revolution Press, 2021) 》或《 The Phoenix Project (5th Anniversary edition, IT Revolution Press, 2018)》。

本章其他章节中提到的许多技术，如cloud、SaaS、CI/CD、Kubernetes、containers和infrastructure as code，都在DevSecOps的成功旅程和实现中发挥了作用。在软件供应链安全和DevSecOps的背景下，一个健壮的工具生态系统已经出现。快速浏览一下CNCF场景（https:// landscape.cncf.io）就可以看到在CI/CD、自动化和配置、调度和编排等领域的蓬勃发展，所有这些都在现代DevSecOps环境中扮演着重要的角色。值得强调的是，尽管工具和技术促进了成功的DevOps转换，但DevOps不是工具或技术；它是一种方法和一套实践。已经采用了许多工具来支持DevOps，而一些常见的方法，如CI/CD，已经允许集成工具来应对软件供应链的挑战。

Syft和Grype等工具通常用于工具链中，以便创建SBOMs，并扫描这些SBOMs，以寻找与在部署到生产环境之前通过工具链的软件组件相关的漏洞。DevOps使用源代码管理（SCM）和Git存储库、CI/CD管道、声明性部署的GitOps风格等等。所有这些工具和方法都已经融合起来，以支持从源代码到运行时的迭代软件交付。它们还使团队和组织能够利用工具获得源代码、容器映像、不安全的IaC或Kubernetes配置中涉及的组件，最终形成了云本地部署架构，每个组件都有自己的软件供应链问题。

像NIST这样的组织已经开始请求DevSecOps的实践可以帮助识别、评估和减轻软件供应链的风险(www.nccoe.nist.gov/sites/default/files/2022-07/dev-sec-ops-projectdescription-draft.pdf)。如白皮书《Software Supply Chain and DevOps Security Practices》中所述，该观点旨在为安全的DevOps环境提供基于风险的建议。它还寻求与其他NIST的指导方针相一致，如SSDF和800-161/C-SCRM。本指南采用了一种非常以CI/CD管道为中心的方法，将软件供应链安全集成到DevSecOps环境中。

敏捷和DevOps的一个基本方面是远离传统的瀑布式软件开发，而是专注于更多的迭代和增量的软件交付。有些人可能会认为，敏捷的增量性质和DevOps可能会促进管理软件供应链的安全问题。随着组织逐步生产和发布软件，工具链可用于识别软件组件、关联漏洞、聚合这些指标，并授权组织做出与软件供应链问题相关的了解风险的决策。使用DevSecOps工具和在SDLC中强调左移安全或更早的安全性，可以在引入运行时环境之前识别出易受攻击的软件组件。许多人声称，从成本的角度来看，这种方法更有效，但它也降低了利用的可能性，因为如果该漏洞及早被捕获并补救，就不能在生产过程中被恶意行为者利用。

DevSecOps不仅提供了捕获SDLC早期脆弱软件组件的机会，并提供了更好的透明度，而且高能力的DevSecOps团队能够更好地应对软件供应链问题和事件。研究支持这些说法，最著名的是由谷歌运营的DevOps Research and Assessment (DORA) 团队。在《2022 Accelerate State of DevOps Report》中，DORA团队发现，部署前安全扫描等实践在发现脆弱的依赖关系方面是有效的，这导致生产应用程序中的漏洞更少（https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf）。

由于DORA团队多年来进行了他们的研究，他们创建了特定的指标，现在被认为是DORA指标。他们用于衡量软件开发团队绩效的四个关键指标如下：

部署频率：一个组织成功地发布到生产环境中的频率
变更提前期：一个承诺投入生产所需的时间
变更失败率：导致生产过程中失败的部署的百分比
服务恢复时间：一个组织从生产失败中恢复过来需要多长时间，这也通常被称为平均恢复时间（MTTR）

这四个指标支持两个关键主题：部署频率的速度和更改的提前时间、故障率的稳定性和恢复服务的时间。这些指标有助于衡量团队以业务/任务需求的速度发布软件的能力，同时也能确保这些发布不会影响系统的弹性。一开始认为快速移动的团队是稳定的似乎是违反直觉的，但正如行业专家指出的那样，在不影响稳定性的情况下，正是软件开发和交付的实践帮助这些团队能够做到这一点。那些在生产中不频繁发布软件的队伍往往而且需要更长的时间完成产品，并且经常难以应对变化以及无法从故障中恢复系统。在这种情况下，高表现力的DevOps团队可以被认为是已经将上述经验内化成了肌肉记忆。