DevSecOps六大支柱：测量、监控、报告和行动

DevSecOps工作组的官网地址是 https://cloudsecurityalliance.org/research/working-groups/devsecops/ ©2025云安全联盟‒保留所有权利。您可以下载、存储、在计算机上显⽰、查看、打印并链接到云安全联盟https://cloudsecurityalliance.org但须遵守以下规定：(a)草案仅可⽤于个⼈、信息、⾮商业⽤途；(b)不得以任何⽅式修改或更改草案；(c)不得重新分发草案；(d)不得删除商标、版权或其他声明。在遵循中华人民共和国著作权法相关条款情况下合理使用本文内容，使用时请注明引用于云安全联盟大中华区。 主要作者DanGora 贡献者 审稿人 RolandMJuliannaTchebotarevaTimothyThatcherUdithWCSA分析师 JoshBuker CSA全球员工 致谢 中文版翻译专家 翻译组成员： 高亚楠伏伟任卜宋博贺志生江澎林艺芳谢绍志王彪 审校组成员： 李岩王彪 （以上排名不分先后） 英文版编写专家 主要作者： DanGoraRoupeSahans 贡献者： AlexBrownDanielParkinMichaelRoca 审阅者： RolandMJuliannaTchebotarevaTimothyThatcherUdithW CSA分析师： JoshBuker CSA全球员工： ClaireLehnert 在此感谢以上专家及单位。如译文有不妥当之处，敬请读者联系CSAGCR秘书处给予雅正！联系邮箱research@c-csa.cn；国际云安全联盟CSA公众号。 目录 致谢.....................................................................4前言.....................................................................8介绍.....................................................................8目标...................................................................9目标读者...............................................................9使数据可观察.............................................................9脆弱性的可观测性......................................................101.平均识别时间......................................................102.平均补救时间......................................................113.发展速度与脆弱性趋势相对应........................................11安全架构观察..........................................................124.威胁量............................................................125.计量控制..........................................................136.计量安全措施......................................................137.威胁模型燃尽......................................................138.采用安全模型......................................................149.威胁场景与网络风险映射............................................14事件响应的可观察性....................................................1710.平均检测时间（Meantimetodetect MTTD）........................1711.平均遏制时间（Meantimetocontain MTTC）.......................1712.平均恢复时间（MeantimetorestorenormalityMTTRN）...............18团队间的成熟度比较......................................................19团队“Alpha”-低成熟度和效能......................................19团队“Beta”-中等成熟度和效能.....................................19团队“Charlie”-高成熟度和效能.....................................20三个团队之间的安全可观察性............................................20 跨团队的漏洞可观察性................................................20跨团队的安全架构可观察性............................................22跨团队的事件响应可观测性............................................25通过报告提高............................................................28原则-使数据可访问和可观察.........................................28原则-突出改进机会.................................................29原则-突出变化,推动持续改进........................................30原则-鼓励沟通和协作...............................................30应用这些报告原则....................................................31报告路线图............................................................31结论....................................................................33附录A：软件生命周期分解................................................33附录B:衡量.............................................................35参考资料................................................................40 前言 云安全联盟和SAFECode都致力于改善软件安全成状况。2019年8月发表的论文《DevSecOps的六个支柱》提供了高端方法论和成功实施解决方案，作者们使用这些方法和解决方案可以快速构建软件，并最小化安全相关错误数量。这六个支柱是: 支柱1：集体责任（2020年2月20日发布） 支柱2：协作与集成（2024年2月21日发布） 支柱3：务实的实现（2022年12月14日发布） 支柱4：建立合规与发展的桥梁（2022年2月8日发布） 支柱5：自动化（2020年7月6日发布） 支柱6：测量、监控、报告和行动（2024年5月发布） 支撑这些支柱的成功解决方案是云安全联盟和SAFECode一系列更详细的联合出版物。本文是六个后续出版物的最后一篇。 介绍 DevSecOps举措的实施和维护可能需要几个月到几年的时间。在考虑人员、流程和工具的大规模变化时，持续测量DevSecOps的成功和失败是关键的差异化因素。“你无法管理你不能测量的事物”这句话十分正确，没有可操作的测量标准和可观察性去测量绩效，就无法理解进步，无法复制成功，也无法意识到失败。 测量、监测、报告和行动的能力是任何成功的安全计划的基本特征，以支持有效的决策。在本文中，我们探讨: 使数据可观察:将安全数据和指标转化为可观察的数据 基于场景的修正:安全可观察性概念应用于高绩效和低绩效场景案例 通过报告改进:安全可观察性报告的起点 目标 云安全联盟的DevSecOps工作组(WG)在“DevSecOps的六个支柱”1中发布了高级别指南，倡导采用新的安全方法。这六个支柱被认为是任何希望实施DevSecOps的组织需要重点关注的领域，其中一个支柱是"支柱6:测量、监测、报告和行动"。 支柱6的目标是促进和展示DevSecOps安全状况的确切测量。这将使安全和数字领导者能够确定其安全实践的有效性，以及安全如何融入软件开发生命周期。 目标读者 本文件的目标读者包括从事信息安全和信息技术管理和业务职能的人员。其中包括CISO、CIO、CTO以及参与以下职能领域的个人:平台工程、DevOps、产品团队、架构、信息安全、治理和合规。 使数据可观察 如果一个系统具备有效且可见的系统状态数据，那么它就是可观察的，这对于追根溯源至关重要。一个系统现状的可观察性测量基于其生生成的数据，如日志、指标和跟踪状态。可观测性旨在了解整体环境中发生的情况，以便检测和解决问题，从而保持系统的高效和可靠性。组织采用可观察性来帮助检测和分析运营、软件开发生命周期、应用程序安全和最终用户体验中事件的影响程度。 日志、指标、分布式跟踪和用户体验的测量是实现可观测性成功的关键支柱: 日志:特定时间发生的离散事件的结构化或非结构化文本记录 指标:是指计数或度量的值，通常在一段时间内进行计算或聚合。指标可以来自各种来源，包括基础设施、主机、服务、云平台和外部来源 分布式跟踪:事务或请求在应用程序中流动的活动，并显示服务如何连接，包括代码级别的详细信息 用户体验:在应用程序上，甚至在生产前环境中，添加具体的、由外向内用户视角的数字化体验，扩展传统的远程可观测性。 脆弱性的可观测性 一旦产品团队具备基于正确工具和工作流程的扫描机制，如静态应用程序安全测试(SAST)、动态应用程序安全检测(DAST)和软件组成分析(SCA)等，识别脆弱性将十分简单。而挑战始于团队持续性开展扫描、修正和报告。 随着时间的推移，脆弱性积压可能会增加，在某些情况下甚至会增加到数以万计，直到变得难以管理和补救。有效的脆弱性管理程序应该在开发生命周期的早期发现并修复漏洞，以减少其平台/产品的总体风险暴露。脆弱性的可观察性要求识别以下三个属性。 1.平均识别时间 MTTI是识别脆弱性所花费的时间。较高的MTTI表明，在开发生命周期后期发现的脆弱性，将增加补救成本和将问题引入生产环境的风险。通过及早识别脆弱性，开发人员可以防止可利用脆弱性引入生产环境。 在图2中，识别时间为脆弱性暴露窗口的开始日期(1月10日)和识别所述脆弱性的日期(1月16日)，因此，