DevSecOps 成熟度模型 2024

使用单元测试来测试重要的安全相关功能，如身份验证和授权。风险：由于代码变更，漏洞风险增加。实施必要的安全相关集成测试。例如用于身份验证和授权。在复杂的微服务环境中，由于代码变更，漏洞风险增加。每次部署后都会在生产环境中进行集成测试。风险：在部署过程中可能发生错误，导致系统、系统的一部分或某个功能不可用。通过单元测试和集成测试实施与安全相关的测试。包括对库的测试，以防它们尚未经过测试。风险：在复杂的微服务环境中，由于不重要组件的代码更改，漏洞数量正在增加。标准：使用单元测试来测试重要的安全相关功能，如身份验证和授权。

使用单元测试来测试重要的安全相关功能，如身份验证和授权。风险：由于代码变更，漏洞风险增加。实施必要的安全相关集成测试。例如用于身份验证和授权。风险：在复杂的微服务环境中，代码变更会导致漏洞增加。每次部署后都会在生产环境中进行集成测试。风险：在部署过程中可能发生错误，导致系统、系统的一部分或某个功能不可用。通过单元测试和集成测试实施与安全相关的测试。包括对库的测试，如果这些库尚未被测试过。风险：由于在复杂的微服务环境中对不重要组件的代码更改，漏洞正在增加。标准：实施关键的安全相关集成测试。例如用于身份验证和授权的测试。

使用单元测试来测试重要的安全相关功能，如身份验证和授权。风险：由于代码变更，漏洞风险增加。实施必要的安全相关集成测试。例如用于身份验证和授权。风险：在复杂的微服务环境中，代码变更会导致漏洞增加。每次部署后都会在生产环境中进行集成测试。风险：在部署过程中可能发生错误，导致系统、系统的一部分或某个功能不可用。通过单元测试和集成测试实施与安全相关的测试。包括对库的测试，以防它们尚未经过测试。风险：由于在复杂的微服务环境中对不重要的组件进行了代码更改，漏洞正在增加。标准：每次部署后都会针对生产环境执行集成测试。

使用单元测试来测试重要的安全相关功能，如身份验证和授权。风险：由于代码变更，漏洞风险增加。实施必要的安全相关集成测试。例如用于身份验证和授权。在复杂的微服务环境中，由于代码变更，漏洞风险增加。每次部署后都会在生产环境中进行集成测试。风险：在部署过程中可能发生错误，导致系统、系统的一部分或某个功能不可用。通过单元测试和集成测试实施与安全相关的测试。包括对库的测试，以防它们尚未经过测试。风险：由于复杂微服务环境中非重要组件的代码更改，漏洞风险正在上升。标准：通过单元测试和集成测试实现与安全相关的测试。包括对库的测试，以防它们尚未被测试。

安全测试的发现必须进行分类处理，并将结果进行持久化/记录，以： - 防止在后续测试中重复分析已知问题 - 跟踪已接受的风险与误报 - 支持团队之间的一致决策 在此成熟度水平上，一个简单的跟踪系统就足够了——工具只需区分“已分类处理”和“未分类处理”的发现，无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间都会出现误报，所有漏洞可能会被忽略。特别是如果测试是自动化并每日运行的。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级简单框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优点：确保发现结果在提交给产品团队之前的准确性和相关性 减少误报，节省开发团队的时间和精力 可能在评估漏洞的严重性和影响方面提供专业意见 由安全工程师验证发现的缺点：需要足够数量的熟练安全工程师，这对某些组织可能是一个挑战 如果安全工程师被验证任务压得太重，可能会减慢流程 对于软件组成分析发现（已知漏洞），我作为安全人员...英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中误报的维护会带来高工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性的漏洞不可见。标准：误报已被抑制，因此在下次测试中不会再次出现。大多数安全工具都有抑制误报的功能。可能使用漏洞管理系统。

安全测试的发现必须进行分级处理，并将结果保存/记录，以便： - 防止在后续测试中对已知问题进行重复分析 - 跟踪已接受的风险与误报情况 - 促进各团队之间的一致决策 在这一成熟度水平上，一个简单的跟踪系统就足够了——工具只需区分“已分级处理”和“未分级处理”的发现，无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间都会出现误报，可能会忽略所有漏洞。特别是，如果测试是自动化并每天运行的。高或更高严重级别的漏洞会被添加到质量门槛中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地可视化。风险：组件的安全级别不可见。因此，提升安全性的动机不足。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优点：确保发现的准确性和相关性，在其传递给产品团队之前减少误报，从而节省开发团队的时间和精力可能在评估漏洞的严重性和影响时提供专业知识层面由安全工程师验证发现的缺点：需要足够数量的熟练安全工程师，这对某些组织可能是一个挑战如果安全工程师被验证任务压得太重，可能会减慢流程对于软件组成分析的发现（已知漏洞），我作为安全人员...英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题管理系统中跟踪（例如 Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能比较困难。此外，检查漏洞管理系统可能并非开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部 vs.外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能对来自不同工具的相同发现进行关联。每个组件/项目/团队的发现都以可视化方式呈现。风险：没有提供不同工具的漏洞关联，以便对每个组件/项目/团队的整体安全水平进行概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性漏洞不可见。标准：高严重性或更高的漏洞已被添加到质量门控中。

安全测试的发现必须进行分类处理，并将结果进行持久化/记录，以： - 防止在后续测试中对已知问题进行重新分析 - 跟踪已接受的风险与误报 - 实现各团队之间的一致决策 在这个成熟度水平上，一个简单的跟踪系统就足够了——工具只需要区分“已分类处理”和“未分类处理”的发现，而无需复杂的分类。有些工具将此称为“抑制”发现。处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理 风险：由于每次测试过程中可能出现误报，所有漏洞可能会被忽略。尤其是当测试自动化并每天运行时。严重性高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级简单框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优缺点 优点： - 在发现内容传递给产品团队之前，确保其准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能用不同工具对相同的发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得各组件/项目/团队整体安全水平的概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性漏洞不可见。标准：漏洞可以简单可视化。

安全测试的发现必须进行分级处理，并将结果保存/记录，以便： - 防止在后续测试中对已知问题进行重复分析 - 跟踪已接受的风险与误报情况 - 促进各团队之间的一致决策 在这一成熟度水平上，一个简单的跟踪系统就足够了——工具只需区分“已分级处理”和“未分级处理”的发现，无需复杂分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间可能出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地可视化。风险：组件的安全级别不可见。因此，提升安全性的动机不足。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优缺点 优点： - 确保在结果到达产品团队之前的准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中误报的维护会带来高工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性的漏洞不可见。标准：根据应用程序的可访问性，实施一个简单的基于风险的漏洞修复优先级框架。

安全测试的发现必须进行分类处理，并将结果进行持久化/记录，以： - 防止在后续测试中对已知问题进行重新分析 - 跟踪已接受的风险与误报 - 实现各团队之间的一致决策 在这个成熟度水平上，一个简单的跟踪系统就足够了——工具只需要区分“已分类处理”和“未分类处理”的发现，而无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间可能出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地可视化。风险：组件的安全级别不可见。因此，提升安全性的动机不足。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对发现的问题被忽视。由安全工程师验证发现的优缺点 优点： - 确保在结果到达产品团队之前的准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题管理系统中跟踪（例如 Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能比较困难。此外，检查漏洞管理系统可能并非开发者的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部 vs.外部) 法规遵从 其他相关因素 风险：未定义应用的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性漏洞不可见。标准：将发现整合到开发过程中。例如，将发现添加到产品团队的待办事项中。

安全测试的发现必须进行分类优先处理，并将结果保存/记录，以便：- 防止在后续测试中对已知问题进行重新分析 - 跟踪已接受的风险与误报 - 实现各团队之间的一致决策 在这个成熟度水平上，一个简单的跟踪系统就足够了——工具只需要区分“已分类处理”和“未分类处理”的发现，而无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间都会出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级简单框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对发现的问题被忽视。由安全工程师验证发现的优缺点 优点： - 确保在结果到达产品团队之前的准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性的漏洞不可见。标准：漏洞在团队的问题追踪系统中跟踪（例如 Jira）。

安全测试的发现必须进行分级处理，并将结果保存/记录，以便： - 防止在后续测试中对已知问题进行重复分析 - 跟踪已接受的风险与误报情况 - 促进各团队之间的一致决策 在这一成熟度水平上，一个简单的跟踪系统就足够了——工具只需区分“已分级处理”和“未分级处理”的发现，无需复杂分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间可能出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级简单框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对发现的问题被忽视。由安全工程师验证发现的优点：确保发现结果在提交给产品团队之前的准确性和相关性 减少误报，节省开发团队的时间和精力 可能在评估漏洞的严重性和影响方面提供专业意见 由安全工程师验证发现的缺点：需要足够数量的熟练安全工程师，这对某些组织可能是一个挑战 如果安全工程师被验证任务压得太重，可能会减慢流程 对于软件组成分析发现（已知漏洞），我作为安全专业人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题管理系统中跟踪（例如 Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能比较困难。此外，检查漏洞管理系统可能并非开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部 vs.外部) 法规遵从 其他相关因素 风险：未定义应用的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中误报的维护会带来高工作量。此外，不可能用不同工具对相同的发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得各组件/项目/团队整体安全水平的概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性的漏洞不可见。标准：定义保护要求以及根据组件（如应用程序）漏洞的严重性进行相应的处理，这些要求与服务水平协议（SLA）一致。这是对整个组织执行的，并不需要分解到团队/产品/应用程序层面（至少目前不需要）。至少每季度进行一次。

安全测试的发现必须进行分级处理，并将结果保存/记录，以便： - 防止在后续测试中对已知问题进行重复分析 - 跟踪已接受的风险与误报情况 - 促进各团队之间的一致决策 在这一成熟度水平上，一个简单的跟踪系统就足够了——工具只需区分“已分级处理”和“未分级处理”的发现，无需复杂的分类。有些工具将此称为“抑制”发现结果。处理误报的示例工具：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间可能出现误报，所有漏洞可能会被忽略。特别是如果测试是自动化并每日运行的情况下。严重性为高或更高的漏洞会被加入质量门控。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级简单框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对发现的问题被忽视。由安全工程师验证发现的优缺点 优点： - 确保在结果到达产品团队之前的准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）等。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞已被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中误报的维护会带来高工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性漏洞不可见。标准：中等严重性漏洞被加入到质量门控中。

安全测试的发现必须进行分级处理，并将结果保存/记录，以便： - 防止在后续测试中对已知问题进行重复分析 - 跟踪已接受的风险与误报情况 - 促进各团队之间的一致决策 在这一成熟度水平上，一个简单的跟踪系统就足够了——工具只需区分“已分级处理”和“未分级处理”的发现，无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间都会出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地可视化。风险：组件的安全级别不可见。因此，提升安全性的动机不足。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优点：确保发现结果在提交给产品团队之前的准确性和相关性 减少误报，节省开发团队的时间和精力 可能在评估漏洞的严重性和影响方面提供专业意见 由安全工程师验证发现的缺点：需要足够数量的熟练安全工程师，这对某些组织可能是一个挑战 如果安全工程师被验证任务压得太重，可能会减慢流程 对于软件组成分析发现（已知漏洞），我作为安全人员...英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队 优点： 通过立即通知产品团队潜在漏洞，加快处理流程； 赋能产品团队迅速采取措施解决安全问题。 缺点： 增加产品团队的工作负担，可能导致挫败感。 风险： 如果不将漏洞处理纳入开发流程，可能导致产品团队忽略发现的问题。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能用不同工具对相同的发现进行关联。各组件/项目/团队的发现是可视化的。风险：没有提供不同工具漏洞的关联，以便概览各组件/项目/团队的整体安全水平。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性的漏洞不可见。标准：在一个工具中汇总漏洞可以减少标记误报的工作量。

安全测试的发现必须进行分类优先处理，并将结果保存/记录，以便：- 防止在后续测试中对已知问题进行重新分析 - 跟踪已接受的风险与误报 - 实现各团队之间的一致决策 在这个成熟度水平上，一个简单的跟踪系统就足够了——工具只需要区分“已分类处理”和“未分类处理”的发现，而无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间可能出现误报，所有漏洞可能会被忽略。特别是如果测试是自动化并每日运行的情况下。严重性为高或更高的漏洞会被加入质量门控。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的漏洞修复优先级简单框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对发现结果的忽视。由安全工程师验证发现的优缺点 优点： - 在发现内容传递给产品团队之前，确保其准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中误报的维护会带来高工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性漏洞不可见。标准：每个组件/项目/团队的发现情况可视化。

安全测试的发现必须进行分类优先处理，并将结果保存/记录，以便： - 防止在后续测试中对已知问题进行重新分析 - 跟踪已接受的风险与误报 - 实现各团队之间的一致决策 在这个成熟度水平上，一个简单的跟踪系统就足够了——工具只需要区分“已分类处理”和“未分类处理”的发现，而无需复杂的分类。有些工具将此称为“抑制”发现结果。处理误报的示例：- OWASP 依赖检查 - 使用 VEX 的 Kubescape - OWASP DefectDojo 风险接受和误报处理风险：由于每次测试期间可能出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地可视化。风险：组件的安全级别不可见。因此，提升安全性的动机不足。根据应用程序的可访问性，实施一个简单的基于风险的漏洞修复优先级框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优缺点 优点： - 确保在结果到达产品团队之前的准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（SCA）发现的已知漏洞，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题系统中跟踪（例如：Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能会很困难。此外，检查漏洞管理系统可能不是开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部与外部）。外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞会被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运营和开发人员能够重现漏洞。这增强了对漏洞的理解，因此修复的质量更高。风险：漏洞描述对于运营和开发人员来说难以理解。所有漏洞都已添加到质量门控中。风险：低严重性漏洞不可见。标准：漏洞包括测试程序，使运营和开发人员能够重现漏洞。这有助于加深对漏洞的理解，从而提高修复的质量。

安全测试的发现必须进行分类优先处理，并将结果保存/记录，以便：- 防止在后续测试中对已知问题进行重新分析 - 跟踪已接受的风险与误报 - 实现各团队之间的一致决策 在这个成熟度水平上，一个简单的跟踪系统就足够了——工具只需要区分“已分类处理”和“未分类处理”的发现，而无需复杂的分类。有些工具将此称为“抑制”发现结果。用于处理误报的示例：- OWASP 依赖检查 - Kubescape 与 VEX - OWASP DefectDojo 风险接受与误报处理风险：由于每次测试期间都会出现误报，所有漏洞可能会被忽略。尤其是当测试是自动化并每日运行时。严重性为高或更高的漏洞会被添加到质量门控中。风险：高或更高严重性的漏洞不可见。漏洞只是简单地进行可视化。风险：组件的安全级别不可见。因此，没有提升安全性的动力。根据应用程序的可访问性，实施一个基于风险的简单漏洞修复优先级框架。风险：来自自动化测试工具的安全发现数量过多。这可能导致对这些发现被忽视。由安全工程师验证发现的优缺点 优点： - 确保在结果到达产品团队之前的准确性和相关性 - 减少误报，节省开发团队的时间和精力 - 可能在评估漏洞的严重性和影响方面提供专业知识 缺点： - 需要足够数量的熟练安全工程师，这对于一些组织可能具有挑战性 - 如果安全工程师被验证任务过载，可能会减慢流程 对于软件组成分析（已知漏洞）的发现，我作为安全人员…英语由于缺乏对应用程序的深入了解，很难分析这是误报还是正报。直接将发现推送给产品团队的优缺点： 优点： - 通过立即通知产品团队潜在漏洞，加快处理流程 - 使产品团队能够迅速采取措施解决安全问题 缺点： - 增加产品团队的工作负担，可能导致挫败感 风险： - 如果未将漏洞处理整合到开发过程中，可能导致产品团队忽视这些发现。漏洞会在团队的问题管理系统中跟踪（例如 Jira）。风险：读取构建服务器的控制台输出以查找漏洞可能比较困难。此外，检查漏洞管理系统可能并非开发人员的日常任务。应用程序的保护要求应考虑：数据重要性、应用程序可访问性（内部 vs.外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞已被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运维和开发人员能够重现漏洞。这增强了对漏洞的理解，从而修复质量更高。风险：漏洞描述对于运维和开发人员来说难以理解。所有漏洞都已被纳入质量门控。风险：低严重性漏洞不可见。标准：所有漏洞都已添加到质量关卡中。

使用能够执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 未被执行。因此，客户端动态组件的覆盖范围有限，可能导致安全风险和未被发现的漏洞。进行简单扫描以获取安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似 REST 的 URL 参数、JSON 格式的参数或 base64 编码的参数）。顺序操作由漏洞扫描器按定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如。登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务与服务之间的通信已被记录并检查。风险：服务与服务之间的通信未被覆盖。标准：使用执行动态内容（如JavaScript）的爬虫，例如通过Selenium。

使用执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 没有被执行。因此，客户端动态组件的覆盖范围有限，可能导致安全风险和未被检测到的漏洞。进行简单扫描以获取安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似 REST 的 URL 参数、JSON 格式的参数或 base64 编码的参数）。顺序操作由漏洞扫描器按定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如。登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务到服务的通信已被转储并检查。风险：服务到服务的通信未被覆盖。标准：执行简单扫描以获得安全基线。如果测试在10分钟内完成，它应成为构建和部署流程的一部分。

使用执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 没有被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。执行一次简单扫描以获取安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似 REST 的 URL 参数、JSON 格式的参数或 base64 编码的参数）。顺序操作由漏洞扫描器按定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如。登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务与服务之间的通信已被转储并检查。风险：服务与服务之间的通信未覆盖。标准：将身份验证集成到服务中使用的所有角色中。

使用能够执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 未被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。进行简单扫描以获得安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似REST的URL中的参数、JSON格式的参数或base64编码的参数）。顺序操作由漏洞扫描器按照定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务到服务的通信已被转储并检查。风险：服务到服务的通信未被覆盖。标准：隐藏的端点正在被检测并包含在漏洞扫描中。

使用能够执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 未被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。进行简单扫描以获得安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未设置。未提供快速反馈。服务中使用的所有角色的身份验证集成。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似REST的URL中的参数、JSON格式的参数或base64编码的参数）。顺序操作由漏洞扫描器按照定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务间通信被转储并检查。风险：服务间通信未覆盖。标准：定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。

使用能够执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 未被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。进行简单扫描以获得安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似REST的URL中的参数、JSON格式的参数或base64编码的参数）。顺序操作由漏洞扫描器按照定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务到服务的通信已被转储和检查。风险：服务到服务的通信未被覆盖。标准：按定义的顺序由漏洞扫描器定义并检查顺序操作。

使用能够执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 未被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。进行简单扫描以获得安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。所有服务中使用的角色认证集成。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似 REST 的 URL 参数、JSON 格式的参数或 base64 编码的参数）。顺序操作由漏洞扫描器按定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如。登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务与服务之间的通信已被转储并检查。风险：服务与服务之间的通信未被覆盖。标准：使用多个爬虫和扫描器可以增强覆盖范围和漏洞检测。

使用执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 没有被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。执行一次简单扫描以获取安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似REST的URL中的参数、JSON格式的参数或base64编码的参数）。顺序操作由漏洞扫描器按照定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务与服务之间的通信已被转储和检查。风险：服务与服务之间的通信未被覆盖。标准：使用覆盖工具检查应用程序中没有遗漏的路径。

使用执行动态内容（如 JavaScript）的爬虫，例如通过 Selenium。风险：扫描过程中服务的部分内容未被覆盖，因为 JavaScript 没有被执行。因此，客户端动态组件的覆盖范围有限，可能导致潜在的安全风险和未被发现的漏洞。执行一次简单扫描以获取安全基线。如果测试在10分钟内完成，它应作为构建和部署过程的一部分。 风险：进行的安全测试不足。简单的漏洞未被发现，缺失的安全配置（例如头信息）未被设置。未提供快速反馈。与服务中使用的所有角色集成身份验证。风险：由于未执行登录，扫描过程中服务的部分内容未被覆盖。隐藏的端点被检测到并包含在漏洞扫描中。风险：服务的隐藏端点未被跟踪。定义了特殊参数和特殊编码，以便被使用的漏洞扫描器进行模糊测试。风险：服务的部分内容未被覆盖。例如，特殊格式或编码的参数不能被检测为参数（例如，类似 REST 的 URL 参数、JSON 格式的参数或 base64 编码的参数）。顺序操作由漏洞扫描器按定义的顺序进行定义和检查。风险：像工作流这样的顺序操作（例如。登录 -> 把产品放入购物篮 使用多个爬虫和扫描器可以提高覆盖率和发现漏洞的能力。风险：每个漏洞扫描器的检测能力不同。仅使用一个扫描器可能会遗漏一些漏洞。使用覆盖率工具检查应用程序中是否有未覆盖的路径。风险：服务的某些部分仍未被测试覆盖。服务与服务之间的通信已被转储并检查。风险：服务与服务之间的通信未被覆盖。标准：服务与服务之间的通信已被转储并检查。

在工具的帮助下，对意外暴露的集群的网络配置进行测试。为了识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域名，并根据结果执行端口扫描。风险：尚未进行标准网络分段和防火墙设置，导致集群管理端口对全世界开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。在工具的帮助下，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，导致存在漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 之类的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致账户被接管。对生产系统或接近生产的系统进行负载测试。风险：由于系统和应用程序可以处理的请求数量未知，意外负载可能会导致可用性受到影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，尤其是秘密，可能仍然有效，但会暴露信息。作为攻击者，我入侵系统，收集凭证并尝试使用它们。标准：借助工具测试意外暴露的集群的网络配置。为识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域，然后基于结果进行端口扫描。

在工具的帮助下，对意外暴露的集群的网络配置进行测试。为了识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域名，并根据结果执行端口扫描。风险：尚未执行标准网络分段和防火墙设置，导致集群管理端口对全世界开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间的分段）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。在工具的帮助下，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固操作，导致出现漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 之类的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致账户被接管。对生产系统或接近生产的系统进行负载测试。风险：由于系统和应用程序可以处理的请求数量未知，意外负载可能会导致可用性受到影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，特别是密钥，可能仍然有效，但正在暴露信息。作为攻击者，我会入侵系统，收集凭证并尝试使用它们。标准：需要进行集群内部测试。实施精细化的网络分段（包括同一命名空间内的 Pod 之间）。

在工具的帮助下，对意外暴露的集群的网络配置进行了测试。为了识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域名，并根据结果执行端口扫描。风险：未进行标准的网络分段和防火墙设置，导致集群管理端口对全世界开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间的分段）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。借助工具对虚拟环境的配置进行测试。风险：未对云环境执行标准加固操作，导致存在漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 之类的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致账户被接管。对生产系统或接近生产的系统进行负载测试。风险：由于系统和应用程序可以处理的请求数量未知，意外负载可能会导致可用性受到影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，特别是机密，可能仍然有效，但会暴露信息。作为攻击者，我入侵系统，收集凭证并尝试使用它们。标准：借助工具测试虚拟环境的配置。

在工具的帮助下，对意外暴露的集群的网络配置进行了测试。为了识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域名，并根据结果进行端口扫描。风险：未进行标准的网络分段和防火墙设置，导致集群管理端口对全世界开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间的分段）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。在工具的帮助下，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固操作，导致出现漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 之类的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致账户被接管。对生产系统或接近生产的系统进行负载测试。风险：由于系统和应用程序可以处理的请求数量未知，意外负载可能会导致可用性受到影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，特别是密钥，可能仍然有效，但会暴露信息。作为攻击者，我会入侵系统，收集凭证并尝试使用它们。标准：组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。

借助工具，测试了无意暴露集群的网络配置。为了识别集群，可能需要使用OWASP Amass等工具识别所有子域，并根据结果进行端口扫描。风险：尚未进行标准的网络分段和防火墙，导致全球集群管理端口开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间的分段）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。借助工具对虚拟环境的配置进行测试。风险：未执行云环境的标准加固操作，导致存在漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致账户被接管。对生产系统或接近生产的系统进行负载测试。风险：由于系统和应用程序可以处理的请求数量未知，意外负载可能会导致可用性受到影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，尤其是机密信息，可能仍然有效，但会暴露信息。作为攻击者，我入侵系统，收集凭证并尝试使用它们。标准：进行自动暴力攻击。特别建议使用像“admin”和员工用户ID这样的标准账户。

在工具的帮助下，对意外暴露的集群的网络配置进行了测试。为了识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域名，并根据结果执行端口扫描。风险：尚未执行标准网络分段和防火墙设置，导致集群管理端口对全世界开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间的分段）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。在工具的帮助下，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，导致出现漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 这样的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致账户被接管。对生产系统或接近生产的系统进行负载测试。风险：由于系统和应用程序可以处理的请求数量未知，意外负载可能会导致可用性受到影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，特别是秘密，可能仍然有效，但会暴露信息。作为攻击者，我入侵系统，收集凭证并尝试使用它们。标准：对生产系统或接近生产的系统进行负载测试。

在工具的帮助下，对意外暴露的集群的网络配置进行测试。为了识别集群，可能需要使用像 OWASP Amass 这样的工具识别所有子域名，并根据结果执行端口扫描。风险：尚未进行标准网络分段和防火墙设置，导致集群管理端口对全世界开放。需要进行集群内部测试。精细化的网络分段集成（也包括同一命名空间内的 Pod 之间的分段）。风险：Pod 的网络分段错误或缺失，使攻击者更容易访问数据库并提取或修改数据。借助工具对虚拟环境的配置进行测试。风险：未对云环境执行标准加固操作，导致存在漏洞。组件必须列入白名单。需要对 Docker 基础设施（例如集群）进行定期扫描，以验证仅使用标准化的基础镜像。风险：使用未经批准的组件。可能会进行自动暴力攻击。特别推荐使用诸如“admin”和员工用户 ID 之类的标准账户。风险：组件中的弱密码，如应用程序或系统中的弱密码，尤其是特权账户的弱密码，可能导致该账户被接管。对生产系统或接近生产的系统进行了负载测试。风险：由于系统和应用程序能够处理的请求数量未知，意外负载可能会导致可用性受影响。对未使用资源的测试有助于识别未使用的资源。风险：未使用的资源，尤其是机密，可能仍然有效，但会暴露信息。作为攻击者，我攻破系统，收集凭证并尝试使用它们。标准：测试未使用的资源有助于识别未使用的资源。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估计被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在子维度“基础设施静态深度”中重复，但它同样适用于基础设施。风险：自动创建的依赖关系 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复内容。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析，以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会有意外行为。标准：对服务器端组件（例如后端/中间件）已知漏洞进行测试。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动依赖的拉取请求被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码的凭证和变量、敏感信息）。自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或晦涩的代码可能会有意想不到的行为。标准：修复时间的测试（例如基于自动拉取请求关闭的平均时间）。此活动在“基础设施的静态深度”子维度中没有重复，但同样适用于基础设施。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在子维度“基础设施静态深度”中不会重复，但它同样适用于基础设施。风险：自动创建的依赖项 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复内容。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会有意想不到的行为。标准：测试 `libyear`，它能很好地反映补丁管理的有效性。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽略，导致生产环境工件中存在已知漏洞。测试 `libyear`，它可以很好地了解补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码规范插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复，但它同样适用于基础设施。风险：自动创建的依赖关系 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能出现意外行为。标准：使用OpenAPI、AsyncAPI或SOAP等接口描述语言设计以合同为先的API，并使用特定工具验证规范。检查应集成开发环境（IDE）和CI/CD流水线。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽略，导致生产环境工件中存在已知漏洞。测试 `libyear`，它可以很好地了解补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成在 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复，但它同样适用于基础设施。风险：自动创建的依赖项 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码的凭证和变量、敏感信息）。自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析，以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会有意想不到的行为。标准：通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估计被利用的可能性。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽视，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码中的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在子维度“基础设施静态深度”中重复，但它同样适用于基础设施。风险：自动依赖的拉取请求被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会导致意外的行为。标准：将质量和代码检查插件集成到交互式开发环境（IDE）中。执行提交前检查，以防止将机密信息和其他安全问题提交到源代码中。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽略，导致生产环境工件中存在已知漏洞。测试 `libyear`，它可以很好地了解补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动创建的依赖项 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码的凭证和变量、敏感信息）。自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会有意外行为。标准：通过前端的软件成分分析对组件已知漏洞进行测试。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估计被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码规范插件与交互式开发环境（IDE）集成。实施提交前检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动创建的依赖项 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会产生意外的行为。标准：对前端重要部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽视，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码规范插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在子维度“基础设施静态深度”中不会重复，但它同样适用于基础设施。风险：自动依赖的拉取请求被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有的漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会产生意外的行为。标准：对中间件的重要部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽略，导致生产环境工件中存在已知漏洞。测试 `libyear`，它能很好地体现补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的组件软件组成分析（SCA）对已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动创建的依赖关系 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有的漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复内容。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或模糊的代码可能会有意想不到的行为。标准：补丁部署时间测试。此活动在子维度“基础设施的静态深度”中没有重复，但同样适用于基础设施。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽略，导致生产环境工件中存在已知漏洞。测试 `libyear`，它可以很好地了解补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施提交前检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动创建的依赖关系 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会产生意外的行为。 标准：对中间件和前端的所有部分使用静态分析工具。 静态分析例如使用字符串匹配算法和/或数据流分析。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽视，导致生产环境工件中存在已知漏洞。测试 `libyear`，它可以很好地了解补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成在 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码规范插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动创建的依赖关系 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码的凭证和变量、敏感信息）。自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析，以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会有意外的行为。标准：使用多种静态工具来发现更多漏洞。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动不会在“基础设施静态深度”子维度中重复，但它同样适用于基础设施。风险：自动依赖的 PR 被忽视，导致生产制品中存在已知漏洞。使用静态分析工具对中间件和前端的所有部分进行分析。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具可能无法发现所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析，以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或模糊的代码可能会有意想不到的行为。标准：收集未使用的代码，然后手动删除未使用的代码。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估计被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复，但它同样适用于基础设施。风险：自动依赖的 PR 被忽视，导致生产制品中存在已知漏洞。使用静态分析工具对中间件和前端的所有部分进行分析。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有的漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 对源代码的风格指南合规性进行分析，以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或模糊的代码可能会有意想不到的行为。标准：自动检测并手动移除源代码中的重复部分。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动生成的依赖项拉取请求可能被忽略，导致生产工件中存在已知漏洞。测试 `libyear`，它能很好地展示补丁管理的效果。风险：运行中的工件中的漏洞可能存在较长时间，并可能被利用。设计以合同为先的 API，使用接口描述语言如 OpenAPI、AsyncAPI 或 SOAP，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施提交前检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的软件组成分析对组件已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在子维度“基础设施静态深度”中不会重复，但它同样适用于基础设施。风险：自动依赖的拉取请求被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码增加了攻击面（使用硬编码的凭证和变量、敏感信息）。自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或混淆的代码可能会有意外行为。标准：对所有使用的组件进行静态分析。

对服务器端组件（例如后端/中间件）已知漏洞进行测试。风险：服务器端组件可能存在漏洞。补丁响应时间测试（例如基于自动 PR 的平均关闭时间）。此活动不会在“基础设施静态深度”子维度中重复，但同样适用于基础设施。风险：自动依赖项的 PR 被忽略，导致生产环境工件中存在已知漏洞。测试 `libyear`，它可以很好地了解补丁管理的效果。风险：运行中的工件中的漏洞存在时间过长，可能被利用。使用接口描述语言（如 OpenAPI、AsyncAPI 或 SOAP）设计契约优先的 API，并使用特定工具验证规范。检查应集成到 IDE 和 CI/CD 流水线中。风险：创建不安全或不合规的 API。通过使用过去的数据（CISA KEV）或预测模型（EPSS）来估算被利用的可能性。风险：如果没有适当的优先排序，组织可能会在低风险漏洞上浪费时间和精力，而忽视关键漏洞。将质量和代码检查插件与交互式开发环境（IDE）集成。实施预提交检查，以防止将敏感信息和其他安全问题提交到源代码中。风险：创建和开发的代码可能包含代码异味和质量问题。通过前端的组件软件组成分析（SCA）对已知漏洞进行测试。风险：客户端组件可能存在漏洞。对前端重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：前端源码的重要部分存在漏洞。对中间件重要部分使用了静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。风险：中间件源代码中的重要部分存在漏洞。补丁部署时间测试。此活动在“基础设施静态深度”子维度中不会重复，但它同样适用于基础设施。风险：自动创建的依赖关系 PR 被忽略，导致生产工件中存在已知漏洞。对中间件和前端的所有部分使用静态分析工具。静态分析例如使用字符串匹配算法和/或数据流分析。 风险：前端或中间件的源代码部分存在漏洞。使用多个静态分析工具以发现更多漏洞。风险：每个漏洞分析工具都有不同的优势。仅使用一个分析工具，可能会发现不到所有的漏洞。收集未使用的代码，然后手动删除未使用的代码。风险：死代码会增加攻击面（使用硬编码凭证和变量、敏感信息）。 自动检测并手动删除源代码中的重复代码。风险：源代码中的重复可能影响应用程序的稳定性。对所有使用的组件进行静态分析。风险：使用的组件如库和遗留应用程序可能存在漏洞。 分析源代码对风格指南的遵守情况可以确保源代码格式规则得到遵守（例如缩进、循环等）。风险：不清晰或模糊的代码可能会有意外行为。标准：分析源代码是否符合样式指南，确保源代码的格式化规则得到遵守（例如缩进、循环等）。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查不安全的配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到攻击正在发生。检查组件中的恶意软件（例如。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗凭证冒充维护者。检查生产环境中容器的新镜像。风险：当镜像有新版本可用时，可能会修复安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中已有的漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发行说明可能会有所帮助。针对基础设施的软件组成分析可能有用，但通常颗粒过细。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：测试代码、容器镜像及历史记录中的密钥。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像年龄。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全的配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到可能发生的攻击。检查组件中是否存在恶意软件（例如。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 GitHub 项目并阅读发布说明可能会有所帮助。基础设施的软件组成分析可能有帮助，但通常过于细化。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：测试虚拟化环境的部署配置以查找不安全的配置。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查是否存在不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全配置。检查日志中的关键字。风险：未意识到可能发生的攻击。检查组件中是否存在恶意软件（例如）。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有帮助。基础设施的软件组成分析可能有用，但通常粒度太细。风险：基础设施组件（如容器镜像）中的已知漏洞可能被利用。标准：检查生产环境中容器的镜像版本或创建时间。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全的配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到可能发生的攻击。检查组件中是否存在恶意软件（例如）。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有所帮助。基础设施的软件组成分析可能有助，但通常过于细致。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：测试虚拟化环境的未加固配置。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到攻击正在发生。检查组件中的恶意软件（例如。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已知的漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有所帮助。基础设施的软件组成分析可能有帮助，但通常过于细化。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：借助工具测试虚拟环境的配置。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到攻击正在发生。检查组件中的恶意软件（例如。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已知的漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署不安全的制品，从而增加被利用的风险。订阅 Github 项目并阅读版本说明可能会有帮助。基础设施的软件组成分析可能有用，但通常颗粒过细。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：测试虚拟化环境中未安全配置的定义。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到攻击正在发生。检查组件中的恶意软件（例如。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗凭证冒充维护者。检查生产环境中容器的新镜像。风险：当镜像有新版本可用时，它可能修复安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有所帮助。用于基础设施的软件组成分析可能有帮助，但通常过于细粒度。风险：基础设施组件（如容器镜像）中的已知漏洞可能被利用。标准：检查日志中的关键字。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查不安全的配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全的配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到可能发生的攻击。检查组件中是否存在恶意软件（例如）。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署不安全的制品，从而增加被利用的风险。订阅 Github 项目并阅读发行说明可能有帮助。基础设施的软件组成分析可能有帮助，但通常过于细致。风险：基础设施组件（如容器镜像）中的已知漏洞可能被利用。评估标准：检查组件中的恶意软件（例如容器镜像、虚拟机基础镜像、库）。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查不安全的配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全的配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到可能发生的攻击。检查组件中是否存在恶意软件（例如）。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中已有的漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有帮助。基础设施的软件组成分析可能有用，但通常粒度过细。风险：基础设施组件（如容器镜像）中的已知漏洞可能被利用。标准：检查生产环境中容器的新镜像。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查是否存在不安全配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全的配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到可能发生的攻击。检查组件中是否存在恶意软件（例如）。容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有所帮助。对基础设施进行软件组成分析可能有效，但通常过于细致。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：待办

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查不安全的配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到攻击正在发生。检查组件中的恶意软件（例如容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已存在的已知漏洞。该过程涉及将基础设施扫描中的现有漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 GitHub 项目并阅读发布说明可能会有所帮助。基础设施的软件组成分析可能有帮助，但通常过于细化。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。

测试代码、容器镜像和历史记录中的机密。风险：存储在 git 历史记录、容器镜像或代码中的机密不应存在，因为它们可能被未授权的人员访问。测试虚拟化环境的部署配置以检查不安全的配置。风险：部署配置（例如 Kubernetes 部署资源）可能包含不安全的配置。检查生产环境中容器的镜像版本。风险：生产环境中的老旧容器镜像表明未进行补丁管理，因此可能存在漏洞。测试虚拟化环境中的不安全配置。风险：虚拟化环境（例如通过容器镜像）可能包含不安全的配置。借助工具，对虚拟环境的配置进行测试。风险：未对云环境执行标准加固措施，可能导致漏洞。测试虚拟化环境的定义以检查不安全配置。风险：虚拟化环境的定义（例如通过 Dockerfile）可能包含不安全的配置。检查日志中的关键字。风险：未意识到攻击正在发生。检查组件中的恶意软件（例如容器镜像、虚拟机基线镜像、库）。风险：第三方可能包含恶意软件。可能是由于维护者的原因（例如：镜像名称拼写错误导致使用了错误的镜像），或者是攻击者利用被盗的维护者凭证进行的攻击。检查生产环境中容器的新镜像。风险：当镜像有新版本时，新版本可能修复了安全漏洞。这种做法确保新部署的容器或虚拟机镜像不会重新引入或延续当前基础设施中已知的漏洞。该过程涉及将基础设施扫描中存在的漏洞数据与更新镜像中的组件和依赖项进行交叉核对。通过持续将已知的安全问题与新镜像版本进行关联，组织可以在将潜在易受攻击的镜像部署到生产环境之前主动降低风险。风险：未能将基础设施中的已知漏洞与新镜像版本进行关联，可能导致无意间部署了不安全的工件，从而增加被利用的风险。订阅 Github 项目并阅读发布说明可能会有所帮助。基础设施的软件组成分析可能有助，但通常过于细致。风险：基础设施组件（如容器镜像）中的已知漏洞可能会被利用。标准：测试基础设施组件中的已知漏洞。通常，应对操作系统软件包中已知漏洞的唯一方法是接受风险并等待补丁。当补丁可用时需要尽快应用，因此这一活动依赖于“镜像的最大使用寿命”。

所使用工具的强度没有修改以节省时间。风险：时间压力和无知可能导致对测试强度的错误预测。在每次推送和/或指定间隔自动执行安全测试。风险：将源代码推送到版本控制系统后，任何延迟收到缺陷反馈都会使开发人员更难修复它们。不必要的测试将被停用。例如，如果服务使用的是 Mongo 数据库而没有 MySQL 数据库，动态扫描就不需要测试 SQL 注入。风险：由于工具涵盖了各种不同的漏洞测试，它们可能无法匹配所使用的组件。因此，它们需要更多的时间和资源，同时反馈循环也会耗费过多时间。进行高测试强度且低置信度阈值的深度扫描。风险：强度过小或置信度过高可能导致漏洞不可见。制定并应用了一个考虑每次扫描/强度所需时间的测试方案。动态分析比静态分析需要更多时间。动态扫描根据测试强度可能在每次提交、每晚、每周或每月进行一次。风险：扫描可能使用过低或过高的测试强度。标准：所使用工具的强度没有进行调整以节省时间。

所使用工具的强度没有修改以节省时间。风险：时间压力和无知可能导致对测试强度的错误预测。在每次推送和/或在设定的间隔自动执行安全测试。风险：将源代码推送到版本控制系统后，任何接收缺陷反馈的延迟都会使开发人员更难以修复。未使用的测试被停用。例如，如果服务使用的是 Mongo 数据库而没有 MySQL 数据库，动态扫描就不需要测试 SQL 注入。风险：由于工具涵盖了各种不同的漏洞测试，它们可能无法匹配所使用的组件。因此，它们需要更多的时间和资源，同时反馈循环也会耗费过多时间。进行高测试强度且低置信度阈值的深度扫描。风险：强度过小或置信度过高可能导致漏洞不可见。制定并应用了一个考虑每次扫描/强度所需时间的测试方案。动态分析比静态分析需要更多时间。动态扫描根据测试强度可能在每次提交、每晚、每周或每月执行一次。风险：扫描可能使用过低或过高的测试强度。标准：进行高测试强度且低置信度阈值的深度扫描。

所使用工具的强度没有修改以节省时间。风险：时间压力和无知可能导致对测试强度的错误预测。在每次推送和/或在设定的间隔自动执行安全测试。风险：将源代码推送到版本控制系统后，任何接收缺陷反馈的延迟都会使开发人员更难以修复。未使用的测试被停用。例如，如果服务使用的是 Mongo 数据库而没有 MySQL 数据库，动态扫描就不需要测试 SQL 注入。风险：由于工具涵盖了各种不同的漏洞测试，它们可能无法匹配所使用的组件。因此，它们需要更多的时间和资源，同时反馈循环也会耗费过多时间。进行高测试强度且低置信度阈值的深度扫描。风险：强度过小或置信度过高可能导致漏洞不可见。制定并应用了一个考虑每次扫描/强度所需时间的测试方案。动态分析比静态分析需要更多时间。动态扫描根据测试强度的不同，可以在每次提交、每晚、每周或每月进行一次。风险：扫描可能使用过低或过高的测试强度。标准：在每次推送时和/或在指定间隔自动执行安全测试。

所使用工具的强度没有修改以节省时间。风险：时间压力和无知可能导致对测试强度的错误预测。在每次推送和/或指定间隔自动执行安全测试。风险：将源代码推送到版本控制系统后，任何延迟收到缺陷反馈都会使开发人员更难修复它们。不必要的测试将被停用。例如，如果服务使用的是 Mongo 数据库而没有 MySQL 数据库，动态扫描就不需要测试 SQL 注入。风险：由于工具涵盖了各种不同的漏洞测试，它们可能与所使用的组件不匹配。因此，它们需要更多时间和资源，同时反馈循环也会耗费过多时间。进行高测试强度且低置信度阈值的深度扫描。风险：强度过小或置信度过高可能导致漏洞不可见。制定并应用了一个考虑每次扫描/强度所需时间的测试方案。动态分析比静态分析需要更多时间。动态扫描根据测试强度，可能在每次提交、每晚、每周或每月执行一次。风险：扫描可能使用过低或过高的测试强度。标准：不必要的测试会被禁用。例如，如果服务使用的是 Mongo 数据库而不是 MySQL 数据库，动态扫描就不需要测试 SQL 注入。

所使用工具的强度没有修改以节省时间。风险：时间压力和无知可能导致对测试强度的错误预测。在每次推送和/或指定间隔自动执行安全测试。风险：将源代码推送到版本控制系统后，任何延迟收到缺陷反馈都会使开发人员更难修复它们。不必要的测试将被停用。例如，如果服务使用的是 Mongo 数据库而没有 MySQL 数据库，动态扫描就不需要测试 SQL 注入。风险：由于工具涵盖了各种不同的漏洞测试，它们可能与所使用的组件不匹配。因此，它们需要更多时间和资源，同时反馈循环也会耗费过多时间。进行高测试强度且低置信度阈值的深度扫描。风险：强度过小或置信度过高可能导致漏洞不可见。制定并应用了一个考虑每次扫描/强度所需时间的测试方案。动态分析比静态分析需要更多时间。动态扫描根据测试强度的不同，可能会在每次提交、每个夜间、每周或每月进行一次。风险：扫描可能使用的测试强度过低或过高。标准：创建并应用一个考虑每次扫描所需时间/强度的测试方案。动态分析比静态分析需要更多时间。动态扫描根据测试强度，可能在每次提交、每晚、每周或每月进行一次。

沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一种安全测试的实施。风险：未能按严重程度传达漏洞数量可能会削弱产品团队的有效性。这可能导致对发现的问题被忽视。沟通可以以简单的方式进行，例如在构建过程中基于文本的沟通。此活动至少依赖于一次安全测试的实施。需要考虑的层（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），至少每季度进行一次。平均补丁时间按组件/项目/团队进行可视化展示。