DevSecOps 成熟度模型 2024

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一次安全测试的实施。需要考虑的层（SCA）：云提供商（如果可能获得洞察） 运行时，例如 Kubernetes 节点 基础镜像和容器镜像 应用程序 需要考虑的层（SAST/DAST）：云提供商 运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和传达按严重性级别处理的各组件（例如应用程序）的漏洞数量，确保与服务等级协议（SLA）保持一致。该比率应按团队、产品、应用程序、代码库和/或服务进行分解。此分析应至少每季度进行一次。风险：未能传达多少应用程序根据漏洞严重性遵守服务级别协议（SLA）可能导致关键安全问题的修复延迟，从而增加被利用的风险并可能对组织造成损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现没有反应或反应延迟可能导致发现被利用。衡量和沟通按严重程度处理的组件（如应用程序）漏洞数量是否符合服务水平协议。这是针对整个组织进行的，目前不需要拆分到团队/产品/应用程序。至少每季度进行一次。风险：如果不传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险以及对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。标准：衡量和沟通针对不同严重程度的组件（如应用程序）漏洞处理情况是否符合服务级别协议（SLA）。此操作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动依赖于至少一次安全测试的实施。需要考虑的层（SCA）：云提供商（如果可能获得洞察） 运行时，例如 Kubernetes 节点 基础镜像和容器镜像 应用程序 需要考虑的层（SAST/DAST）：云提供商 运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和传达按严重性级别处理的组件（如应用程序）的漏洞数量，确保与服务水平协议（SLA）保持一致。该比率应按团队、产品、应用程序、仓库和/或服务进行细分。此分析应至少每季度进行一次。风险：未能传达多少应用程序根据漏洞的严重性遵守服务级别协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险和对组织可能造成的损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现的问题没有反应或反应延迟可能导致这些问题被利用。衡量和沟通每个组件（如应用程序）按严重性处理的漏洞数量是否符合服务等级协议（SLA）。此操作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。风险：如果不传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险以及对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未解决的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。标准：按严重性对组件（如应用程序）的漏洞进行测量和沟通。至少每季度一次。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动依赖于至少一个安全测试的实施。需要考虑的层（SCA）：云提供商（如果可能获得洞察）运行时，例如 Kubernetes 节点基础镜像和容器镜像应用层需要考虑 SAST/DAST：云提供商运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和沟通按严重性级别处理的组件（如应用程序）的漏洞数量，确保与服务水平协议（SLA）保持一致。该比率应按团队、产品、应用程序、仓库和/或服务进行细分。此分析应至少每季度进行一次。风险：未能传达多少应用程序根据漏洞严重性遵守服务级别协议（SLA）可能导致关键安全问题的修复延迟，从而增加被利用的风险并可能对组织造成损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现的问题没有反应或反应延迟可能导致这些问题被利用。衡量和沟通每个组件（如应用程序）按严重性处理的漏洞数量是否符合服务等级协议（SLA）。此操作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。风险：未能传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能导致关键安全问题的修复延迟，从而增加被利用的风险和对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未解决的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。标准：按严重性对组件（如应用程序）中的漏洞进行测量和沟通，并根据层级（如应用/基础设施）进行划分。至少每季度一次。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动依赖于至少一个安全测试实现。需要考虑的层（SCA）：云提供商（如果可能获取洞察）运行时，例如 Kubernetes 节点基础镜像和容器镜像应用层需要考虑 SAST/DAST：云提供商运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未解决的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未解决的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和沟通按严重性级别处理的各组件（例如应用程序）的漏洞数量，确保与服务等级协议（SLA）保持一致。该比率应按团队、产品、应用程序、代码库和/或服务进行分解。此分析应至少每季度进行一次。风险：未能根据漏洞的严重性传达有多少应用程序遵守服务级别协议（SLA），可能导致关键安全问题的修复延迟，从而增加被利用的风险和对组织可能造成的损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现的问题没有反应或反应延迟可能导致这些问题被利用。衡量和沟通每个严重性等级的组件（如应用程序）漏洞处理情况是否符合服务等级协议（SLA）。此工作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。风险：如果不传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险以及对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未处理的漏洞可能被攻击者利用，从而导致潜在的安全漏洞和数据丢失。标准：衡量和传达每个严重性等级的组件（如应用程序）处理的漏洞数量，确保与服务水平协议（SLA）保持一致。该比率应按团队、产品、应用程序、代码库和/或服务进行细分。此分析应至少每季度进行一次。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动依赖于至少一次安全测试的实施。需要考虑的层（SCA）：云提供商（如果可能获得洞察）运行时，例如 Kubernetes 节点基础镜像和容器镜像应用层需要考虑 SAST/DAST：云提供商运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和传达按严重性级别处理的组件（如应用程序）的漏洞数量，确保与服务水平协议（SLA）保持一致。该比率应按团队、产品、应用程序、仓库和/或服务进行细分。此分析应至少每季度进行一次。风险：未能传达多少应用程序根据漏洞的严重性遵守服务级别协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险和对组织可能造成的损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现的问题没有反应或反应延迟可能导致这些问题被利用。衡量和沟通每个严重性等级的组件（如应用程序）漏洞处理情况是否符合服务等级协议（SLA）。此工作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。风险：如果不传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险以及对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未解决的漏洞可能会被攻击者利用，导致潜在的安全漏洞和数据丢失。标准：发现的创建和响应统计数据（例如，平均解决时间）。这也被称为_平均解决时间_。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一次安全测试的实施。需要考虑的层（SCA）：云提供商（如果可能获得洞察） 运行时，例如 Kubernetes 节点 基础镜像和容器镜像 应用程序 需要考虑的层（SAST/DAST）：云提供商 运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和传达按严重性级别处理的各组件（例如应用程序）的漏洞数量，确保与服务等级协议（SLA）保持一致。该比率应按团队、产品、应用程序、代码库和/或服务进行分解。此分析应至少每季度进行一次。风险：未能传达多少应用程序根据漏洞严重性遵守服务级别协议（SLA）可能导致关键安全问题的修复延迟，从而增加被利用的风险并可能对组织造成损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现没有反应或反应延迟可能导致发现被利用。衡量和沟通按严重程度处理的组件（如应用程序）漏洞数量是否符合服务水平协议。这是针对整个组织进行的，目前不需要拆分到团队/产品/应用程序。至少每季度进行一次。风险：如果不传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险以及对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。标准：衡量和沟通针对不同严重程度的组件（如应用程序）漏洞处理情况是否符合服务级别协议（SLA）。此操作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能削弱产品团队的有效性，这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动依赖于至少一次安全测试的实施。需要考虑的层（SCA）：云提供商（如果可能获得洞察） 运行时，例如 Kubernetes 节点 基础镜像和容器镜像 应用程序 需要考虑的层（SAST/DAST）：云提供商 运行时，例如Kubernetes 基础镜像和容器镜像应用风险：未能按严重性和层次（应用/基础设施）传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。风险：如果不衡量与补丁相关的平均修复时间（MTTR），就很难识别补丁过程中的延迟。未处理的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。测量和传达按严重性级别处理的各组件（例如应用程序）的漏洞数量，确保与服务等级协议（SLA）保持一致。该比率应按团队、产品、应用程序、代码库和/或服务进行分解。此分析应至少每季度进行一次。风险：未能根据漏洞的严重性传达有多少应用程序遵守服务级别协议（SLA），可能导致关键安全问题的修复延迟，从而增加被利用的风险和对组织可能造成的损害。发现的创建和响应统计数据（例如平均解决时间）。这也被称为平均解决时间。风险：对发现的问题没有反应或反应延迟可能导致这些问题被利用。衡量和沟通每个组件（如应用程序）按严重性处理的漏洞数量是否符合服务等级协议（SLA）。此操作针对整个组织进行，目前无需按团队/产品/应用程序细分。至少每季度进行一次。风险：如果不传达有多少应用程序根据漏洞的严重性遵守服务水平协议（SLA），可能会导致关键安全问题的修复延迟，从而增加被利用的风险以及对组织的潜在损害。从补丁可用到按照服务级别协议（SLA）在生产环境中部署补丁的时间的测量与沟通，至少每季度进行一次。每个组件/项目/团队的平均补丁时间都会进行可视化。风险：如果不测量与补丁相关的平均解决时间（MTTR），很难识别补丁过程中的延误。未解决的漏洞可能被攻击者利用，导致潜在的安全漏洞和数据丢失。标准：测量和沟通从补丁可用到在生产环境中部署的时间，并符合服务级别协议（SLA），至少每季度进行一次。平均补丁时间按组件/项目/团队进行可视化展示。