◎2025云安全联盟-保留所有权利。您可以下载、存储、在计算机上显示、查看、打印并链接到云安全联盟https://cloudsecurityalliance.org但须遵守以下规定：(a)草案仅可用于个人、信息、非商业用途；(b)不得以任何方式修改或更改草案；(c)不得重新分发草案；(d)不得删除商标、版权或其他声明。在遵循中华人民共和国著作权法相关条款情况下合理使用本文内容，使用时请注明引用于云安全联盟大中华区。
目标
云安全联盟的DevSecOps工作组(WG)在“DevSecOps的六个支柱”1中发布了高级别指南，倡导采用新的安全方法。这六个支柱被认为是任何希望实施DevSecOps的组织需要重点关注的领域，其中一个支柱是”支柱6:测量、监测、报告和行动”。
支柱6的目标是促进和展示DevSecOps安全状况的确切测量。这将使安全和数字领导者能够确定其安全实践的有效性，以及安全如何融入软件开发生命周期。
目标读者
本文件的目标读者包括从事信息安全和信息技术管理和业务职能的人员。其中包括CISO、CIO、CTO以及参与以下职能领域的个人：平台工程、DevOps、产品团队、架构、信息安全、治理和合规。
使数据可观察
如果一个系统具备有效且可见的系统状态数据，那么它就是可观察的，这对于追根溯源至关重要。一个系统现状的可观察性测量基于其生生成的数据，如日志、指标和跟踪状态。可观测性旨在了解整体环境中发生的情况，以便检测和解决问题，从而保持系统的高效和可靠性。组织采用可观察性来帮助检测和分析运营、软件开发生命周期、应用程序安全和最终用户体验中事件的影响程度。
日志、指标、分布式跟踪和用户体验的测量是实现可观测性成功的关键支柱：
·日志：特定时间发生的离散事件的结构化或非结构化文本记录
●指标：是指计数或度量的值，通常在一段时间内进行计算或聚合。指标可以
各种来源，包括基础设施、主机、服务、云平台和外部来源
·分布式跟踪：事务或请求在应用程序中流动的活动，并显示服务如何连接，
代码级别的详细信息
●用户体验：在应用程序上，甚至在生产前环境中，添加具体的、由外向内用
角的数字化体验，扩展传统的远程可观测性。
脆弱性的可观测性
一旦产品团队具备基于正确工具和工作流程的扫描机制，如静态应用程序安全测试(SAST)、动态应用程序安全检测(DAST)和软件组成分析(SCA)等，识别脆弱性将十分简单。而挑战始于团队持续性开展扫描、修正和报告。
随着时间的推移，脆弱性积压可能会增加，在某些情况下甚至会增加到数以万计，直到变得难以管理和补救。有效的脆弱性管理程序应该在开发生命周期的早期发现并修复漏洞，以减少其平台/产品的总体风险暴露。脆弱性的可观察性要求识别以下三个属性。
1.平均识别时间
MTTI是识别脆弱性所花费的时间。较高的MTTI表明，在开发生命周期后期发现的脆弱性，将增加补救成本和将问题引入生产环境的风险。通过及早识别脆弱性，开发人员可以防止可利用脆弱性引入生产环境。
在图2中，识别时间为脆弱性暴露窗口的开始日期(1月10日)和识别所述脆弱性的日期(1月16日),因此，识别所需时间为7天。对数百个脆弱性进行识别的时间会有所不同，MTTL是所有漏洞识别值的平均值。
2.平均补救时间
MTTR指示识别后修复脆弱性所花费的平均时间。MTTR有助于跟踪脆弱性是否被识别，是否被解析器团队“遗忘”。与MTTI一样，MTTR可以根据严重性和接受风险的脆弱性数量进行跟踪
图2中，补救时间是识别日期(1月16日)和补救日期(2月10日)的差值，因此，补救所需时间为26天。与MTTI一样，对数百个脆弱性进行补救的时间不同，MTTR是所有漏洞补救值的平均值。
3.发展速度与脆弱性趋势相对应
开发速度是否超过了修复脆弱性的能力?跟踪这一趋势有助于确定开发团队是否在开发和运营过程中难以跟上脆弱性补救的步伐，以及补救是否与发展速度保持同步。MTTI/MTTR可以根据发展速度和严重程度评分进行跟踪。这可以帮助确定开发团队和安全团队在脆弱性管理中是否存在脱节。
在图2中，脆弱性暴露窗口(1月10日-2月10日)跨越了两个发布窗口。此值将有助于提供上下文信息，以帮助证明MTTI和MTTR值的正确性。
本文来自知之小站
PDF完整报告已分享至知识星球，微信扫码加入立享4万+最新精选报告
（星球内含更多专属精选报告.其它事宜可联系zzxz_88@163.com）
