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.外部）监管合规 其他相关因素 风险：未定义应用程序的保护要求可能导致错误的优先级排序、关键安全问题修复延迟，从而增加被利用的风险及对组织的潜在损害。中等严重性的漏洞已被纳入质量门控。风险：中等严重性的漏洞不可见。对于已知漏洞，建议有一个评估漏洞可利用性的流程。为了实施安全文化，包括培训、办公时间和安全冠军有助于在大规模集成安全扫描。这些活动有助于理解为什么某个漏洞可能是关键的并需要处理。风险：每个工具中错误警报的维护会增加工作量。此外，不可能对来自不同工具的相同发现进行关联。各组件/项目/团队的发现是可视化的。风险：无法将不同工具的漏洞进行关联，以获得每个组件/项目/团队的整体安全水平概览。漏洞包括测试程序，使运维和开发人员能够重现漏洞。这增强了对漏洞的理解，从而修复质量更高。风险：漏洞描述对于运维和开发人员来说难以理解。所有漏洞都已被纳入质量门控。风险：低严重性漏洞不可见。标准：所有漏洞都已添加到质量关卡中。