OWASP 软件保证成熟度模型 2.0

安全基本原则的收益集可供产品团队使用 活动 在设计过程中，产品团队的技术人员会使用一份简短的安全原则清单。通常，安全原则包括纵深防御、保护最薄弱环节、使用安全默认设置、安全功能设计简洁、故障安全、安全性与可用性的平衡、以最小权限运行、避免通过模糊手段实现安全等。对于外围接口，团队会在整体系统的背景下考虑每一项原则，并确定可以添加哪些功能来加强每个接口的安全性。将这些功能限制在仅比功能性需求的正常实现成本额外增加少量努力的范围内。对于任何更大的改动，应进行记录，并安排在未来版本中实现。在此流程之前，对每个产品团队进行安全意识培训，并引入更多熟悉安全的员工以协助设计决策。好处：为产品团队提供可复用的安全服务。活动：识别具有安全功能的共享基础设施或服务。这些通常包括单点登录服务、访问控制或权限服务、日志记录和监控服务或应用级防火墙。收集和评估可重用的系统，汇总出这样的资源清单，并按照它们实现的安全机制进行分类。考虑每个资源时，要思考产品团队为什么想要与之集成，即使用共享资源的好处。如果每个类别中存在多个资源，请选择并标准化每个类别中的一个或多个共享服务。由于未来的软件开发将依赖这些服务，请仔细评估每个服务，以确保了解基础安全状态。对于每个选定的服务，为产品团队创建设计指南，以便他们了解如何与系统集成。通过培训、指导、指南和标准提供指导。建立一套最佳实践，代表实施安全功能的可靠方法。您可以研究这些方法或购买它们，并且通常如果将它们定制以更适合您的组织，会更加有效。示例模式包括单点登录子系统、跨层委托模型、职责分离授权模型、集中式日志记录模式等。这些模式可以来源于特定的项目或应用程序，但请确保在整个组织的不同团队之间共享，以便高效且一致地应用适当的安全解决方案。为了增加这些模式的采用，将它们与共享的安全服务关联，或将它们实现到实际的组件解决方案中，以便在开发过程中可以轻松集成到应用程序中。支持组织内的关键技术，例如在使用不同开发堆栈的情况下。将这些解决方案视为实际应用程序，并在有问题或疑问时提供适当的支持。益处 充分了解中央提供的安全解决方案的质量和可用性。 活动 构建一套参考架构，选择并组合经过验证的一系列安全组件，以确保安全设计的合理性。参考平台在缩短审计和安全相关审核、提高开发效率以及降低维护成本方面具有优势。根据组织内和社区中的新见解，持续维护和改进参考架构。让架构师、高级开发人员以及其他技术相关人员参与参考平台的设计和创建。创建完成后，团队将持续提供支持和更新。参考架构可能会转化为一套软件库和工具，项目团队可以在其基础上构建软件。它们作为起点，标准化了以配置驱动、默认安全的安全方法。你可以通过在生命周期早期选择特定项目，并让具备安全意识的员工与他们合作，以通用方式构建安全功能，从而启动框架，这样这些功能就可以从项目中提取并在组织的其他地方使用。在关于架构、开发或运营的讨论中，持续监控贵组织现有安全解决方案中的弱点或漏洞。这可以作为改进现有参考架构的适用性和有效性的依据。标准：您有一个商定的安全原则清单 | 您将清单存放在一个可访问的位置 | 相关利益相关者理解安全原则

安全基本原则的收益集可供产品团队使用 活动 在设计过程中，产品团队的技术人员会使用一份简短的安全原则清单。通常，安全原则包括纵深防御、保护最薄弱环节、使用安全默认设置、安全功能设计简洁、故障安全、安全性与可用性的平衡、以最小权限运行、避免通过模糊手段实现安全等。对于边界接口，团队会在整体系统的背景下考虑每项原则，并确定可以添加哪些功能来加强每个接口的安全性。将这些功能限制在仅比功能需求的正常实现成本增加少量额外工作量的范围内。对于任何更大的事项，进行记录，并安排在将来的版本中实现。在此流程之前，对每个产品团队进行安全意识培训，并引入更多熟悉安全的员工以协助设计决策。好处：为产品团队提供可复用的安全服务。活动：识别具有安全功能的共享基础设施或服务。这些通常包括单点登录服务、访问控制或权限服务、日志记录和监控服务或应用级防火墙。收集和评估可重用的系统，汇总出这样的资源清单，并按照它们实现的安全机制进行分类。考虑每个资源时，要思考产品团队为什么想要与之集成，即使用共享资源的好处。如果每个类别中存在多个资源，请选择并标准化每个类别中的一个或多个共享服务。由于未来的软件开发将依赖这些服务，请仔细评估每个服务，以确保了解基础安全状态。对于每个选定的服务，为产品团队创建设计指南，以便他们了解如何与系统集成。通过培训、指导、指南和标准提供指导。建立一套最佳实践，代表实施安全功能的可靠方法。您可以自己研究这些实践或购买它们，并且如果将其定制以更符合您组织的具体情况，通常效果会更好。示例模式包括单点登录子系统、跨层委托模型、职责分离授权模型、集中日志记录模式等。这些模式可以来源于特定的项目或应用程序，但务必要在整个组织的不同团队之间共享，以便高效且一致地应用适当的安全解决方案。为了增加这些模式的采用，将它们与共享的安全服务关联，或将它们实现到实际的组件解决方案中，以便在开发过程中可以轻松集成到应用程序中。支持组织内的关键技术，例如在使用不同开发栈的情况下。将这些解决方案视为实际应用程序，在有问题或疑问时提供适当的支持。益处 中央提供的安全解决方案在质量和可用性方面实现全面透明。 活动 构建一套参考架构，选择并组合经过验证的一系列安全组件，以确保安全设计的合理性。参考平台在缩短审计和安全相关审查、提高开发效率以及降低维护开销方面具有优势。根据组织内和社区中的新见解，持续维护和改进参考架构。让架构师、高级开发人员以及其他技术相关人员参与参考平台的设计和创建。创建完成后，团队将持续提供支持和更新。参考架构可能会转化为一套软件库和工具，项目团队可以在其基础上构建软件。它们作为起点，标准化了以配置驱动、默认安全的安全方法。你可以通过在生命周期早期选择特定项目，并让具备安全意识的员工与他们合作，以通用方式构建安全功能，从而启动框架，这样这些功能就可以从项目中提取并在组织的其他地方使用。在关于架构、开发或运营的讨论中，持续监控贵组织现有安全解决方案中的弱点或漏洞。这可以作为改进现有参考架构的适用性和有效性的依据。标准：您有一份可重复使用的安全服务的记录清单，可供相关利益相关者使用 | 您已审查每个所选服务的基础安全状况 | 您的设计人员已接受培训，能够根据可用指南集成每个所选服务

安全基本原则的收益集可供产品团队使用 活动 在设计过程中，产品团队的技术人员会使用一份简短的安全原则清单。通常，安全原则包括纵深防御、保护最薄弱环节、使用安全默认设置、安全功能设计简洁、故障安全、安全性与可用性的平衡、以最小权限运行、避免通过模糊手段实现安全等。对于边界接口，团队会在整体系统的背景下考虑每项原则，并确定可以添加哪些功能来加强每个接口的安全性。将这些功能限制在仅比功能需求的正常实现成本增加少量额外工作量的范围内。对于任何更大的事项，记录下来，并安排在将来的版本中实现。在此流程之前，对每个产品团队进行安全意识培训，并引入更多熟悉安全的员工以协助设计决策。好处：为产品团队提供可复用的安全服务。活动：识别具有安全功能的共享基础设施或服务。这些通常包括单点登录服务、访问控制或权限服务、日志记录和监控服务或应用级防火墙。收集和评估可重用的系统，汇总出此类资源的清单，并按其所实现的安全机制进行分类。考虑每个资源时，要思考产品团队为何希望与之集成，即……使用共享资源的好处。如果每个类别中存在多个资源，请选择并标准化每个类别中的一个或多个共享服务。由于未来的软件开发将依赖这些服务，请仔细评估每个服务，以确保了解基础安全状态。对于每个选定的服务，为产品团队创建设计指南，以便他们了解如何与系统集成。通过培训、指导、指南和标准提供指导。建立一套最佳实践，代表实施安全功能的可靠方法。您可以研究这些方法或购买它们，并且通常如果将它们定制以更适合您的组织，会更加有效。示例模式包括单点登录子系统、跨层委托模型、职责分离授权模型、集中日志记录模式等。这些模式可以来源于特定的项目或应用程序，但务必要在整个组织的不同团队之间共享，以便高效且一致地应用适当的安全解决方案。为了增加这些模式的采用，将它们与共享的安全服务关联，或将其实现为可以在开发过程中轻松集成到应用程序中的实际组件解决方案。支持组织内的关键技术，例如在不同的开发栈情况下。将这些解决方案视为实际应用程序，并在有问题或疑问时提供适当的支持。益处 充分了解中央提供的安全解决方案的质量和可用性。 活动 构建一套参考架构，选择并组合经过验证的一系列安全组件，以确保安全设计的合理性。参考平台在缩短审计和安全相关审核、提高开发效率以及降低维护成本方面具有优势。根据组织内和社区中的新见解，持续维护和改进参考架构。让架构师、高级开发人员以及其他技术相关人员参与参考平台的设计和创建。创建完成后，团队将持续提供支持和更新。参考架构可能会转化为一套软件库和工具，项目团队可以在其基础上构建软件。它们作为起点，标准化了以配置驱动、默认安全的安全方法。你可以通过在生命周期早期选择特定项目，并让具备安全意识的员工与他们合作，以通用方式构建安全功能，从而启动框架，这样这些功能就可以从项目中提取并在组织的其他地方使用。在关于架构、开发或运营的讨论中，持续监控贵组织现有安全解决方案中的弱点或漏洞。这可以作为改进现有参考架构的适用性和有效性的依据。标准：您拥有一份或多份已批准的参考架构文档，并可供利益相关者使用 | 您基于洞察和最佳实践不断改进参考架构 | 您提供一套组件、库和工具来实现每个参考架构

理解在开发过程中关键安全需求的好处 活动 对软件项目的功能需求进行审查。通过推理软件项目提供的服务或数据所期望的机密性、完整性或可用性，识别与该功能相关的安全需求（即期望）。需求应说明目标（例如个人数据在注册过程中应安全传输和存储，但不包括实现目标的具体措施（例如，“使用 TLSv1.2 进行安全传输”）。同时，应从攻击者的角度审查功能，以了解其可能被滥用的方式。通过这种方式，您可以识别当前软件项目的额外保护需求。安全目标可以与您需要添加到应用程序中的特定安全功能相关（例如，“始终识别应用程序的用户”），也可以与整个应用程序的质量和行为相关（例如，“确保个人数据在传输过程中得到妥善保护”），这不一定会导致新功能。遵循编写安全需求的良好实践。使它们具体、可衡量、可操作、相关且有时间限制（SMART）。注意不要添加过于通用而与实际应用无关的要求（例如，应用程序应防护 OWASP 前十）。虽然这些要求可能是正确的，但并不能为讨论增添价值。安全需求与其他类型需求的利益对齐 活动 安全需求可以来源于其他途径，包括政策和法律法规、应用程序中的已知问题，以及来自指标和反馈的情报。在这一阶段，必须通过分析这些需求的不同来源，系统地获取安全需求。确保从这些来源获得适当的输入，以帮助需求的获取。例如，组织访谈或头脑风暴会议（例如，在政策和立法的情况下），分析历史日志或漏洞系统。在各个应用程序中使用结构化的安全需求表示法，并采用适当的形式方法，使其能够与项目中其他（功能性）需求的规范方式良好整合。这可能意味着，例如，扩展分析文档、编写用户故事等。在规定需求时，确保在产品开发过程中考虑到这些需求非常重要。建立一个机制来刺激或迫使项目团队在产品中满足这些需求。例如，为需求标注优先级，或影响需求的处理以强制实施足够的安全需求（同时平衡其他非功能性需求）。优势 在您的组织中高效且有效地处理安全需求 活动 建立一个安全需求框架，帮助项目为其项目获取适当且完整的需求集合。该框架考虑了不同类型的需求和需求来源。它应适应组织的习惯和文化，并在需求的提取和形成过程中提供有效的方法和指导。该框架帮助项目团队提高需求工程的效率和效果。它可以提供常见需求的分类以及一些可重复使用的需求。请记住，虽然无脑复制无效，但拥有潜在相关需求以供推理这一事实通常是有益的。该框架还对需求的质量提供了明确指导，并规范了如何描述它们。例如，对于用户故事，具体的指导可以说明在完成定义、准备定义、故事描述和验收标准中应描述什么。标准：团队从功能需求以及客户或组织关注中得出安全需求 | 安全需求是具体的、可测量的且合理的 | 安全需求符合组织基准

理解在开发过程中关键安全需求的好处 活动 对软件项目的功能需求进行审查。通过考虑软件项目所提供的服务或数据所期望的机密性、完整性或可用性，识别与该功能相关的安全需求（即期望）。需求应说明目标（例如个人数据在注册过程中应安全传输和存储，但不包括实现目标的具体措施（例如，“使用 TLSv1.2 进行安全传输”）。同时，应从攻击者的角度审查功能，以了解其可能被滥用的方式。通过这种方式，您可以识别当前软件项目的额外保护需求。安全目标可以与您需要添加到应用程序中的特定安全功能相关（例如，“始终识别应用程序的用户”），也可以与整个应用程序的质量和行为相关（例如，“确保个人数据在传输过程中得到妥善保护”），这不一定会导致新功能的产生。遵循编写安全需求的良好实践。使它们具体、可衡量、可执行、相关且有时间限制（SMART）。注意不要添加过于通用而与实际应用无关的要求（例如，应用程序应防护 OWASP 前十）。虽然这些要求可能成立，但它们并不能增加讨论的价值。安全需求与其他类型需求的利益对齐 活动 安全需求可以来源于其他途径，包括政策和法律法规、应用程序中的已知问题，以及来自指标和反馈的情报。在这一阶段，必须通过分析这些需求的不同来源，系统地获取安全需求。确保从这些来源获得适当的输入，以帮助需求的获取。例如，组织访谈或头脑风暴会议（例如，在政策和立法的情况下），分析历史日志或漏洞系统。在各个应用程序中使用结构化的安全需求表示法，并采用适当的形式方法，使其能够与项目中其他（功能性）需求的规范方式良好整合。这可能意味着，例如，扩展分析文档、编写用户故事等。在规定需求时，确保在产品开发过程中考虑到这些需求非常重要。建立一个机制来刺激或迫使项目团队在产品中满足这些需求。例如，对需求进行优先级标注，或影响需求的处理以确保足够的安全性（同时在其他非功能性需求之间保持平衡）。优势 在您的组织中高效且有效地处理安全需求 活动 建立一个安全需求框架，帮助项目为其项目获取适当且完整的需求集合。该框架考虑了不同类型的需求和需求来源。它应适应组织的习惯和文化，并在需求的提取和形成过程中提供有效的方法和指导。该框架帮助项目团队提高需求工程的效率和效果。它可以提供常见需求的分类以及一些可重复使用的需求。请记住，虽然无脑复制无效，但拥有潜在相关需求以供推理这一事实通常是有益的。该框架还对需求的质量提供了明确指导，并规范了如何描述它们。例如，对于用户故事，具体的指导可以解释在完成定义、准备定义、故事描述和验收标准中应描述的内容。标准：在将政策和指导应用于产品开发时，安全需求会考虑特定领域的知识 | 在需求定义过程中会有领域专家参与 | 您有一个商定的安全需求结构化标注方法 | 开发团队有专门负责审查安全需求和结果的安全负责人

理解在开发过程中关键安全需求的好处 活动 对软件项目的功能需求进行审查。通过推理软件项目提供的服务或数据所期望的机密性、完整性或可用性，识别与该功能相关的安全需求（即期望）。需求应说明目标（例如个人数据在注册过程中应安全传输和存储，但不包括实现目标的具体措施（例如，“使用 TLSv1.2 进行安全传输”）。同时，应从攻击者的角度审查功能，以了解其可能被滥用的方式。通过这种方式，您可以识别当前软件项目的额外保护需求。安全目标可以与您需要添加到应用程序中的特定安全功能相关（例如，“始终识别应用程序的用户”），也可以与整个应用程序的质量和行为相关（例如，“确保个人数据在传输过程中得到妥善保护”），这不一定会导致新功能的产生。遵循编写安全需求的良好实践。使它们具体、可衡量、可执行、相关且有时间限制（SMART）。注意不要添加过于通用而与实际应用无关的要求（例如，应用程序应防护 OWASP 前十）。虽然这些要求可能成立，但它们并不能增加讨论的价值。安全需求与其他类型需求的利益对齐 活动 安全需求可以来源于其他途径，包括政策和法律法规、应用程序中的已知问题，以及来自指标和反馈的情报。在这一阶段，必须通过分析这些需求的不同来源，系统地获取安全需求。确保从这些来源获得适当的输入，以帮助需求的获取。例如，组织访谈或头脑风暴会议（例如，在政策和立法的情况下），分析历史日志或漏洞系统。在各个应用程序中使用结构化的安全需求表示法，并采用适当的形式方法，使其能够与项目中其他（功能性）需求的规范方式良好整合。这可能意味着，例如，扩展分析文档、编写用户故事等。在规定需求时，确保在产品开发过程中考虑到这些需求非常重要。建立一个机制来刺激或迫使项目团队在产品中满足这些需求。例如，为需求标注优先级，或影响需求的处理以强制实施足够的安全需求（同时平衡其他非功能性需求）。优势 在您的组织中高效且有效地处理安全需求 活动 建立一个安全需求框架，以帮助项目为其项目引导出适当且完整的需求集合。该框架考虑了不同类型的需求和需求来源。它应适应组织的习惯和文化，并在需求的提取和形成过程中提供有效的方法和指导。该框架帮助项目团队提高需求工程的效率和效果。它可以提供常见需求的分类以及一些可重复使用的需求。请记住，虽然无脑复制是无效的，但拥有潜在相关的需求去思考通常是有益的。该框架还对需求的质量提供了明确指导，并规范了如何描述它们。例如，对于用户故事，具体的指导可以解释在完成定义、准备定义、故事描述和验收标准中应描述的内容。标准：为项目团队提供了安全需求框架 | 该框架按通用需求和基于标准的需求进行分类 | 该框架对需求的质量以及如何描述提供了明确的指导 | 该框架可适应特定的业务需求

收益 能够根据风险对应用程序进行分类 活动 使用一种简单的方法评估每个应用程序的风险，估算在发生攻击时它对组织可能造成的潜在业务影响。为实现这一目标，需要评估数据或服务在机密性、完整性和可用性方面受到破坏的影响。可以考虑使用一组5到10个问题来了解重要的应用特性，例如该应用是否处理财务数据，是否面向互联网，或者是否涉及隐私相关数据。应用风险概况可以告诉你这些因素是否适用，以及它们是否可能对组织产生重大影响。接下来，使用一种方案根据风险对应用进行分类。一个简单的定性方案（例如高/中/低），将这些特征转化为具体数值，通常是有效的。使用这些数值来表示并比较不同应用之间的风险非常重要。成熟且高度以风险为驱动的组织可能会使用更量化的风险方案。如果你的组织已经有一个有效的风险方案，不要再发明新的方案。 好处 对你应用组合的风险水平有充分的理解。 活动 该活动的目标是彻底了解组织内所有应用的风险水平，以便将软件保障活动的精力集中在真正重要的地方。从风险评估的角度来看，基本的问题集不足以全面评估所有应用程序的风险。需要创建一种广泛且标准化的方法来评估应用程序的风险，其中包括评估其对信息安全（数据的机密性、完整性和可用性）的影响。除了安全性之外，您还需要评估应用程序的隐私风险。了解应用程序处理的数据以及可能相关的隐私违规情况。最后，研究该应用程序对组织内其他应用程序的影响（例如，该应用程序可能修改了在其他上下文中被视为只读的数据）。评估组织内的所有应用程序，包括所有现有和遗留的应用程序。利用业务影响分析量化和分类应用程序风险。简单的定性方案（例如高/中/低）不足以有效地在企业范围内管理和比较应用程序。基于这些信息，安全官利用分类来定义风险概况，以建立集中化的风险概况清单并管理责任。此清单为产品负责人、经理及其他组织利益相关者提供了应用程序风险水平的一致视图，以便为安全相关活动分配适当的优先级。好处 在应用分类发生变化时及时更新 活动 组织的应用组合会发生变化，以及应用所处的条件和约束（例如，由公司战略驱动）。定期审查风险清单，以确保对不同应用的风险评估正确无误。在企业范围内定期进行审查。此外，随着贵企业在软件保障方面的成熟，应鼓励团队持续质疑哪些环境变化可能会影响风险状况。例如，由于商业决策，内部应用可能变得可以通过互联网访问。这应促使团队重新进行风险评估，并相应更新应用程序的风险状况。在这一实践的成熟实施中，对团队进行培训并持续更新他们从这些风险评估中学到的经验教训和最佳实践。这将导致更好的执行效果以及更准确的应用风险画像。标准：存在达成一致的风险分类 | 应用团队理解风险分类 | 风险分类涵盖组织所面临的关键业务风险方面 | 组织对范围内的应用程序有清单

收益 能够根据风险对应用程序进行分类 活动 使用一种简单的方法评估每个应用程序的风险，估算在发生攻击时它对组织可能造成的业务影响。为实现这一目标，评估数据或服务在机密性、完整性和可用性方面遭受破坏的影响。可以考虑使用一组5到10个问题来了解重要的应用特性，例如该应用是否处理财务数据，是否面向互联网，或者是否涉及隐私相关数据。应用风险概况可以告诉你这些因素是否适用，以及它们是否可能对组织产生重大影响。接下来，使用一种方案根据风险对应用进行分类。一个简单的定性方案（例如高/中/低），将这些特征转化为具体数值，通常是有效的。使用这些数值来表示并比较不同应用之间的风险非常重要。成熟且高度以风险为驱动的组织可能会使用更量化的风险方案。如果你的组织已经有一个有效的风险方案，不要再发明新的方案。 好处 对你应用组合的风险水平有充分的理解。 活动 该活动的目标是彻底了解组织内所有应用的风险水平，以便将软件保障活动的精力集中在真正重要的地方。从风险评估的角度来看，基本的问题集不足以全面评估所有应用程序的风险。需要创建一种广泛且标准化的方法来评估应用程序的风险，其中包括评估其对信息安全（数据的机密性、完整性和可用性）的影响。除了安全性之外，还需要评估应用程序的隐私风险。了解应用程序处理的数据以及可能相关的隐私违规情况。最后，研究该应用程序对组织内其他应用程序的影响（例如，该应用程序可能修改在其他情况下被视为只读的数据）。评估组织内的所有应用程序，包括现有的和遗留的应用程序。利用业务影响分析量化和分类应用程序风险。简单的定性方案（例如高/中/低）不足以有效地在企业范围内管理和比较应用程序。基于这些信息，安全官利用分类来定义风险概况，以建立集中化的风险概况清单并管理责任。此清单为产品负责人、经理及其他组织利益相关者提供了应用程序风险水平的一致视图，以便为安全相关活动分配适当的优先级。好处 在应用分类发生变化时及时更新 活动 组织的应用组合会发生变化，以及应用所处的条件和约束也会变化（例如，由公司战略驱动）。定期审查风险清单，以确保对不同应用的风险评估正确无误。在企业范围内定期进行审查。此外，随着贵企业在软件保障方面的成熟，应鼓励团队持续质疑哪些环境变化可能会影响风险状况。例如，由于商业决策，某个内部应用可能会暴露在互联网上。这应促使团队重新进行风险评估，并相应更新应用的风险状况。在这一实践的成熟实施中，对团队进行培训并不断更新他们从这些风险评估中学到的经验教训和最佳实践。这将有助于更好地执行，并更准确地反映应用程序的风险状况。标准：应用风险概况符合组织的风险标准 | 应用风险概况涵盖对安全性和隐私的影响 | 您可以手动和/或自动验证风险概况的质量 | 应用风险概况存储在中央清单中

收益 能够根据风险对应用程序进行分类 活动 使用一种简单的方法评估每个应用程序的风险，估算在发生攻击时它对组织可能造成的业务影响。为实现这一目标，评估数据或服务在机密性、完整性和可用性方面遭受破坏的影响。可以考虑使用一组5到10个问题来了解重要的应用特性，例如该应用是否处理财务数据，是否面向互联网，或者是否涉及隐私相关数据。应用风险概况可以告诉你这些因素是否适用，以及它们是否可能对组织产生重大影响。接下来，使用一种方案根据风险对应用进行分类。一个简单的定性方案（例如高/中/低），将这些特征转化为具体数值，通常是有效的。使用这些数值来表示并比较不同应用之间的风险非常重要。成熟且高度以风险为驱动的组织可能会使用更量化的风险方案。如果你的组织已经有一个有效的风险方案，不要再发明新的方案。 好处 对你应用组合的风险水平有充分的了解。 活动 这个活动的目标是彻底了解组织内所有应用的风险水平，以便将软件保障活动的精力集中在真正重要的地方。从风险评估的角度来看，基本的问题集不足以全面评估所有应用程序的风险。需要创建一种广泛且标准化的方法来评估应用程序的风险，其中包括评估其对信息安全（数据的机密性、完整性和可用性）的影响。除了安全性之外，您还需要评估应用程序的隐私风险。了解应用程序处理的数据以及可能相关的隐私违规情况。最后，研究该应用程序对组织内其他应用程序的影响（例如，该应用程序可能修改了在其他上下文中被视为只读的数据）。评估组织内的所有应用程序，包括所有现有和遗留的应用程序。利用业务影响分析量化和分类应用程序风险。简单的定性方案（例如高/中/低）不足以有效地在企业范围内管理和比较应用程序。基于这些信息，安全官利用分类来定义风险概况，以建立集中化的风险概况清单并管理责任。此清单为产品负责人、经理和其他组织利益相关者提供了应用程序风险水平的一致视图，以便为安全相关活动分配适当的优先级。好处 在应用程序分类发生变化时及时更新 活动 组织的应用程序组合会发生变化，以及应用程序所处的条件和限制（例如，由公司战略驱动）。定期审查风险清单，以确保对不同应用程序的风险评估的正确性。在企业范围内定期进行审查。此外，随着贵企业在软件保障方面的成熟，应鼓励团队持续质疑哪些环境变化可能会影响风险状况。例如，由于商业决策，内部应用可能变得可以通过互联网访问。这应促使团队重新进行风险评估，并相应更新应用程序的风险状况。在这一实践的成熟实施中，对团队进行培训并不断更新他们从这些风险评估中学到的经验教训和最佳实践。这将有助于更好地执行，并更准确地反映应用程序的风险状况。标准：组织风险标准考虑历史反馈以改进评估方法 | 应用程序或业务环境的重大变化会触发对相关风险概况的审查

收益 对所有相关员工进行基本的安全意识教育 活动 为所有目前参与软件管理、开发、测试或审计的角色开展安全意识培训。目标是提高对应用程序安全威胁和风险的认识，了解安全最佳实践以及安全软件设计原则。培训可内部开发或外部采购。理想情况下，应当亲自进行培训，这样参与者可以作为团队进行讨论，但基于计算机的培训（CBT）也是一种选择。课程内容应涵盖与应用安全和隐私相关的各类主题，同时保持对非技术受众的可理解性。适用的概念是安全设计原则，包括最小特权、防御纵深、故障安全（安全）、完全中介、会话管理、开放设计和心理可接受性。此外，培训应包括对为提高应用程序安全性而制定的任何全公司范围的标准、政策和程序的参考。OWASP 十大漏洞应在高层次上进行涵盖。所有参与软件开发的员工和承包商都必须接受培训，并且需要有可审计的签字以证明合规性。可以考虑采用创新的培训方式（例如游戏化）以最大化培训效果并防止麻木化。相关员工角色根据其具体职位接受培训。活动：针对组织的角色和技术，开展讲师授课或计算机基础培训（CBT）安全训练，从核心开发团队开始。组织会根据各组的技术需求，为产品经理、软件开发人员、测试人员和安全审计员定制培训。产品经理接受与 SAMM 业务功能和安全实践相关的培训，重点是安全需求、威胁建模和缺陷跟踪。开发人员则接受他们所使用技术的编码标准和最佳实践培训，以确保培训能够直接有助于应用程序安全。他们对OWASP十大漏洞或与所使用技术和框架（例如移动端）相关的类似弱点有扎实的技术理解，并了解每个问题的最常见修复策略。测试人员接受培训，学习组织中使用的技术的不同测试工具和最佳实践，以及识别安全缺陷的工具。安全审计员接受关于软件开发生命周期、组织中使用的应用安全机制以及提交安全缺陷进行修复的流程的培训。安全冠军则接受来自软件开发生命周期各个阶段的安全主题培训。他们接受与开发人员和测试人员相同的培训，但也理解威胁建模和安全设计，以及可以集成到构建环境中的安全工具和技术。包括该流程成熟度等级 1 活动的所有培训内容，以及额外的特定角色和特定技术内容。去除培训中不必要的部分。理想情况下，为每项技术确定一名主题专家，协助采购或开发培训内容并定期更新。培训包括使用故意弱化的应用程序（如 WebGoat 或 Juice Shop）演示漏洞利用的过程。包括之前渗透测试的结果作为漏洞示例及已实施的修复策略。请渗透测试人员协助制定漏洞利用演示示例。所有参与软件开发的员工和承包商都必须接受培训，培训包括可审计的签署以证明合规性。在可能的情况下，培训还应包括测试，以确保理解，而不仅仅是合规。每年更新并提供培训，以涵盖组织、技术和趋势的变化。对培训参与者进行调查，以评估培训的质量和相关性。收集其他与其工作或环境相关的信息建议。在员工从事关键任务之前，确保所有员工具备足够的安全知识。活动：实施正式培训计划，要求所有参与软件开发生命周期的人员在入职过程中完成与其角色和技术相关的适当培训。根据应用程序的重要性和用户的角色，考虑在完成入职培训之前限制访问权限。虽然组织可能会从外部获取一些模块，但该计划由内部主持和管理，并包括超越一般安全最佳实践、特定于组织的内容。该项目有明确的课程安排，会检查参与情况，并测试理解和能力。培训包括行业最佳实践与组织内部标准的结合，包括针对组织使用的特定系统的培训。除了与安全直接相关的问题外，该组织还为该计划制定了其他标准，例如代码复杂性、代码文档、命名规范以及其他与流程相关的规范。本培训旨在尽量减少员工遵循组织外部实践所带来的问题，并确保代码风格和能力的持续性。为了便于跟踪进度并顺利完成每个培训模块，组织提供了一个学习管理平台或具有类似功能的其他集中门户。员工可以监控自己的进度，并且即使在完成初始培训后，也可以访问所有培训资源。每年至少审查一次因员工未遵守既定标准、政策、程序或安全最佳实践而产生的问题，以评估培训的有效性，并确保培训涵盖与组织相关的所有问题。定期更新培训，并对员工进行关于任何变化和最常见安全缺陷的培训。标准：培训是可重复的、一致的，并且对任何参与软件开发生命周期的人都可用 | 培训内容包括最新 OWASP Top 10 的相关内容，并涵盖最小特权、防御深度、安全失败、完整授权、会话管理、开放设计和心理可接受性等概念 | 培训要求参与者签字确认或承认 | 您已在过去 12 个月内审查过培训内容，并已完成任何必要的更新 | 所有新入职的相关员工必须在入职过程中完成培训 | 现有相关员工在内容新增/修订时必须完成培训，或者至少每 24 个月完成一次复训，以先到者为准

收益 对所有相关员工进行基本的安全意识教育 活动 为所有目前参与软件管理、开发、测试或审计的角色开展安全意识培训。目标是提高对应用程序安全威胁和风险的认识，了解安全最佳实践以及安全软件设计原则。培训可内部开发或外部采购。理想情况下，应当亲自进行培训，这样参与者可以作为团队进行讨论，但基于计算机的培训（CBT）也是一种选择。课程内容应涵盖与应用安全和隐私相关的各类主题，同时保持对非技术受众的可理解性。适用的概念是安全设计原则，包括最小特权、防御纵深、故障安全（安全）、完全检测、会话管理、开放设计和心理可接受性。此外，培训应包括对任何为提高应用程序安全性而制定的组织范围内的标准、政策和程序的参考。应在高层次上涵盖 OWASP 前十漏洞。所有参与软件开发的员工和承包商都必须接受培训，并需要提供可审计的签署以证明合规性。可以考虑采用创新的交付方式（例如游戏化）以最大化培训效果并防止麻木化。相关员工角色根据其特定职位接受培训。活动：根据组织的角色和技术，进行讲师指导或计算机基础培训（CBT）安全训练，从核心开发团队开始。组织会根据各组的技术需求，为产品经理、软件开发人员、测试人员和安全审计员定制培训。产品经理接受与 SAMM 业务功能和安全实践相关的培训，重点是安全需求、威胁建模和缺陷跟踪。开发人员则接受他们所使用技术的编码标准和最佳实践培训，以确保培训能够直接有助于应用程序安全。他们对OWASP十大漏洞或者与所使用的技术和框架相关的类似弱点（例如移动端）有扎实的技术理解，并了解每个问题的最常见修复策略。测试人员会接受用于组织中使用技术的不同测试工具和最佳实践的培训，以及识别安全缺陷的工具培训。安全审计员接受关于软件开发生命周期、组织中使用的应用安全机制以及提交安全缺陷进行修复的流程的培训。安全冠军则接受来自软件开发生命周期各个阶段的安全主题培训。他们接受与开发人员和测试人员相同的培训，但也理解威胁建模和安全设计，以及可以集成到构建环境中的安全工具和技术。包括该流程成熟度等级 1 活动的所有培训内容，以及额外的特定角色和特定技术内容。去除培训中不必要的部分。理想情况下，为每项技术确定一名主题专家，协助采购或开发培训内容并定期更新。培训包括使用故意弱化的应用程序（如 WebGoat 或 Juice Shop）演示漏洞利用的过程。包括之前渗透测试的结果作为漏洞示例及已实施的修复策略。请渗透测试人员协助制定漏洞利用演示示例。所有参与软件开发的员工和承包商都必须接受培训，培训包括可审计的签署以证明合规性。在可能的情况下，培训还应包括测试，以确保理解，而不仅仅是合规。每年更新并提供培训，以涵盖组织、技术和趋势的变化。对培训参与者进行调查，以评估培训的质量和相关性。收集其他与其工作或环境相关的信息建议。在员工从事关键任务之前，确保所有员工具备足够的安全知识。活动：实施正式培训计划，要求所有参与软件开发生命周期的人员在入职过程中完成与其角色和技术相关的适当培训。根据应用程序的重要性和用户的角色，考虑在完成入职培训之前限制访问。虽然组织可能从外部获取一些模块，但该项目是在内部进行的管理和推动，并包括超越一般安全最佳实践的组织特定内容。该项目有明确的课程安排，会检查参与情况，并测试理解和能力。培训包括行业最佳实践与组织内部标准的结合，包括针对组织使用的特定系统的培训。除了与安全直接相关的问题外，该组织还为该计划制定了其他标准，例如代码复杂性、代码文档、命名规范以及其他与流程相关的纪律。本培训旨在尽量减少员工遵循组织外部实践所带来的问题，并确保代码风格和能力的连续性。为了便于跟踪进度并顺利完成每个培训模块，组织提供了一个学习管理平台或具有类似功能的其他集中门户。员工可以监控自己的进度，并且即使在完成初始培训后，也可以访问所有培训资源。每年至少审查一次因员工未遵守既定标准、政策、程序或安全最佳实践而产生的问题，以评估培训的有效性，并确保培训涵盖与组织相关的所有问题。定期更新培训，并对员工进行关于任何变化和最常见安全缺陷的培训。标准：培训包括成熟度水平1的所有主题，并增加更具体的工具、技术和示范 | 培训是所有员工和承包商的强制性要求 | 培训包括内部专家和培训者的意见 | 培训包括对内部开发的工具和技术的演示 | 你使用反馈来改进并使未来的培训更有针对性

收益 对所有相关员工进行基本的安全意识教育 活动 为所有目前参与软件管理、开发、测试或审计的角色开展安全意识培训。目标是提高对应用程序安全威胁和风险的认识，了解安全最佳实践以及安全软件设计原则。培训可内部开发或外部采购。理想情况下，应当亲自进行培训，这样参与者可以作为团队进行讨论，但基于计算机的培训（CBT）也是一种选择。课程内容应涵盖与应用安全和隐私相关的各类主题，同时保持对非技术受众的可理解性。适用的概念是安全设计原则，包括最小特权、防御纵深、故障安全（安全）、完全检测、会话管理、开放设计和心理可接受性。此外，培训应包括对任何为提高应用程序安全性而制定的组织范围内的标准、政策和程序的参考。应在高层次上涵盖 OWASP 前十漏洞。所有参与软件开发的员工和承包商都必须接受培训，并需要提供可审计的签署以证明合规性。可以考虑采用创新的交付方式（例如游戏化）以最大化培训效果并防止麻木化。相关员工角色根据其特定职位接受培训。活动：根据组织的角色和技术，进行讲师指导或计算机基础培训（CBT）安全训练，从核心开发团队开始。组织会根据各组的技术需求，为产品经理、软件开发人员、测试人员和安全审计员定制培训。产品经理接受与 SAMM 业务功能和安全实践相关的培训，重点是安全需求、威胁建模和缺陷跟踪。开发人员则接受他们所使用技术的编码标准和最佳实践培训，以确保培训能够直接有助于应用程序安全。他们对OWASP十大漏洞或与所使用的技术和框架相关的类似弱点（例如移动端）有扎实的技术理解，并了解每个问题的最常见修复策略。测试人员会接受用于组织中使用技术的不同测试工具和最佳实践的培训，以及识别安全缺陷的工具的培训。安全审计员接受关于软件开发生命周期、组织中使用的应用安全机制以及提交安全缺陷进行修复的流程的培训。安全冠军则接受来自软件开发生命周期各个阶段的安全主题培训。他们接受与开发人员和测试人员相同的培训，但也理解威胁建模和安全设计，以及可以集成到构建环境中的安全工具和技术。包括该流程成熟度等级 1 活动的所有培训内容，以及额外的特定角色和特定技术内容。消除培训中不必要的部分。理想情况下，为每项技术确定一名主题专家，协助采购或开发培训内容并定期更新。培训包括使用故意弱化的应用程序（如 WebGoat 或 Juice Shop）演示漏洞利用的过程。包括之前渗透测试的结果作为漏洞示例及已实施的修复策略。请渗透测试人员协助制定漏洞利用演示示例。所有参与软件开发的员工和承包商都必须接受培训，培训包括可审计的签署以证明合规性。在可能的情况下，培训还应包括测试，以确保理解，而不仅仅是合规。每年更新并提供培训，以涵盖组织、技术和趋势的变化。对培训参与者进行调查，以评估培训的质量和相关性。收集其他与其工作或环境相关的信息建议。在员工从事关键任务之前，确保他们具备足够的安全知识。活动：实施正式培训计划，要求任何参与软件开发生命周期的人在入职过程中完成适合其角色和技术的相关培训。根据应用程序的重要性和用户的角色，考虑在完成入职培训之前限制访问权限。虽然组织可能会从外部获取一些模块，但该计划由内部主持和管理，并包括超越一般安全最佳实践的组织特定内容。该项目有明确的课程安排，会检查参与情况，并测试理解和能力。培训包括行业最佳实践与组织内部标准的结合，包括针对组织使用的特定系统的培训。除了与安全直接相关的问题外，该组织还为该计划包括其他标准，例如代码复杂度、代码文档、命名规范以及其他与流程相关的规范。该培训可以最大限度地减少员工遵循组织外部实践所导致的问题，并确保代码风格和能力的连续性。为了便于跟踪进度并顺利完成每个培训模块，组织提供了一个学习管理平台或具有类似功能的其他集中门户。员工可以监控自己的进度，并且即使在完成初始培训后，也可以访问所有培训资源。每年至少审查一次因员工未遵守既定标准、政策、程序或安全最佳实践而产生的问题，以评估培训的有效性，并确保培训涵盖与组织相关的所有问题。定期更新培训，并对员工进行关于任何变化和最常见安全缺陷的培训。标准：使用学习管理系统（LMS）跟踪培训和认证 | 培训基于内部标准、政策和程序 | 您使用认证计划或出勤记录来确定对开发系统和资源的访问权限

好处 明确组织中最低安全级别的期望 活动 制定一套政策和标准库，以管理组织中软件开发的各个方面。政策和标准基于现有的行业标准，并适合组织所处的行业。由于技术特定的各种限制和最佳实践，请与各个产品团队一起审查拟议的标准。为了整体提高应用程序和计算基础设施的安全性，请各产品团队就标准中任何不可行或成本高昂的实施方面提供反馈，同时也请提出标准能够在产品团队几乎不增加工作量的情况下进一步改进的机会。对于政策，应强调高级定义和与应用安全相关的方面，而不依赖于特定的技术或托管环境。关注组织更广泛的目标，以保护其计算环境的完整性、数据的安全性和隐私，以及软件开发生命周期的成熟度。对于大型组织，政策可能会根据数据分类或应用功能确定具体要求，但不应详细到提供针对特定技术的指导。对于标准，应纳入政策中规定的要求，并关注针对技术的具体实施指导，这些指导旨在利用不同编程语言和框架的安全特性。标准的制定需要来自高级开发人员和架构师的意见，他们被认为是组织所使用的各种技术的专家。以便定期更新的格式创建它们。使用政策或第三方要求对各个需求进行标注或标记，以便于维护和审计，使其更简便高效。益处 为产品团队提供如何遵守安全策略的共同理解 活动 协助持续实施和验证对政策和标准的遵从性，开发与每个适用要求相关的应用程序安全和适当的测试脚本。将这些文档整理到库中，并以最适合各应用程序使用的格式提供给所有应用团队。清晰标注文档，并将其与所代表的政策和标准链接，以便于持续更新和维护。版本策略和标准，并在每次迭代更新时包含详细的变更日志，以便更容易地将其持续纳入不同产品的 SDLC 中。以与现有需求管理流程一致的格式编写应用程序安全需求。您可能需要多个版本，以适应不同的开发方法或技术。目标是让各个产品团队能够轻松地将政策和标准融入其现有的开发生命周期，几乎不需要对要求进行解释。测试脚本通过明确应用功能的预期来强化应用安全需求，并指导可能已经是开发过程一部分的自动或手动测试工作。这些努力不仅帮助每个团队建立对现有政策和标准的合规现状的了解，还能确保在应用程序持续变化时的合规性。好处在于理解您的组织在政策和标准方面的合规情况。活动：制定一个程序，以衡量每个应用程序对现有政策和标准的合规情况。强制性要求应在所有团队中有理由地提出并始终如一地报告。尽可能将合规状态与自动化测试绑定，并在每个版本中进行报告。合规报告包括政策和标准的版本以及适当的代码覆盖因素。鼓励不合规的团队查看可用资源，如安全要求和测试脚本，以确保不合规不是由于指导不足造成的。将因指导不足引起的问题转发给负责发布应用程序要求和测试脚本的团队，以便在未来的版本中加以改进。将因无法遵守政策和标准而产生的问题升级到处理应用程序安全风险的团队。标准：您已根据组织所在行业调整现有标准，以考虑特定领域的因素 | 您的标准与政策一致，并纳入了具体技术的实施指导

好处 明确组织中最低安全级别的期望 活动 制定一套政策和标准库，以管理组织中软件开发的各个方面。政策和标准基于现有的行业标准，并适合组织所处的行业。由于技术特定的各种限制和最佳实践，请与各个产品团队一起审查拟议的标准。为了整体提高应用程序和计算基础设施的安全性，请邀请产品团队就标准中任何不可行或成本高昂的实施方面提供反馈，同时也请他们提出能够在产品团队几乎不增加工作量的情况下进一步改进标准的机会。对于政策，应强调高级定义和与应用安全相关的方面，而不依赖于特定的技术或托管环境。关注组织更广泛的目标，以保护其计算环境的完整性、数据的安全性和隐私，以及软件开发生命周期的成熟度。对于大型组织，政策可能会根据数据分类或应用功能确定具体要求，但不应详细到提供针对特定技术的指导。对于标准，应纳入政策中规定的要求，并关注针对技术的具体实施指导，这些指导旨在利用不同编程语言和框架的安全特性。标准的制定需要来自高级开发人员和架构师的意见，他们被认为是组织所使用的各种技术的专家。以便定期更新的格式创建它们。使用政策或第三方要求对各个需求进行标注或标记，以便于维护和审计，使其更简便高效。益处 为产品团队提供如何遵守安全政策的共同理解 活动 协助持续实施和验证对政策和标准的遵从性，开发与每个适用要求相关的应用程序安全和适当的测试脚本。将这些文档整理成库，并以最适合纳入各个应用程序的格式提供给所有应用团队。清楚地标记文档，并将其链接到它们所代表的政策和标准，以协助持续的更新和维护。版本政策和标准，并在每次迭代更新时包含详细的变更日志，以便更容易地将其持续纳入不同产品的 SDLC 中。以与现有需求管理流程一致的格式编写应用程序安全需求。您可能需要多个版本，以适应不同的开发方法或技术。目标是让各个产品团队能够轻松将政策和标准纳入其现有的开发生命周期，尽量减少对要求的解释。测试脚本通过对应用功能的明确预期来加强应用安全要求，并指导可能已经是开发过程一部分的自动或手动测试工作。这些努力不仅帮助每个团队建立对现有政策和标准的合规现状的了解，还能确保在应用程序持续变化时的合规性。好处在于理解您的组织在政策和标准方面的合规情况。活动：制定一个程序，以衡量每个应用程序对现有政策和标准的合规情况。强制性要求应在所有团队中有理由地提出并始终如一地报告。尽可能将合规状态与自动化测试绑定，并在每个版本中进行报告。合规报告包括政策和标准的版本以及适当的代码覆盖因素。鼓励不合规的团队查看可用资源，如安全要求和测试脚本，以确保不合规不是由于指导不足造成的。将因指导不足引起的问题转发给负责发布应用程序要求和测试脚本的团队，以便在未来的版本中加以改进。将因无法满足政策和标准而产生的问题升级到处理应用程序安全风险的团队。标准：在适用的情况下，您创建符合政策要求和相关标准实施指南的验证清单和测试脚本 | 您创建适应组织使用的每种开发方法和技术的版本

好处 明确组织中最低安全级别的期望 活动 制定政策和标准库，以管理组织中软件开发的所有方面。政策和标准基于现有的行业标准，并适合组织所在的行业。由于技术特定的各种限制和最佳实践，请与各个产品团队一起审查拟议的标准。为了整体提高应用程序和计算基础设施的安全性，请邀请产品团队就标准中任何不可行或成本高昂的实施方面提供反馈，同时也请他们提出能够在产品团队几乎不增加工作量的情况下进一步改进标准的机会。对于政策，应强调高级定义和与应用安全相关的方面，而不依赖于特定的技术或托管环境。关注组织更广泛的目标，以保护其计算环境的完整性、数据的安全性和隐私，以及软件开发生命周期的成熟度。对于大型组织，政策可能会根据数据分类或应用功能确定具体要求，但不应详细到提供针对特定技术的指导。对于标准，应纳入政策中规定的要求，并关注针对技术的具体实施指导，这些指导旨在利用不同编程语言和框架的安全特性。标准的制定需要来自高级开发人员和架构师的意见，他们被认为是组织所使用的各种技术的专家。以便定期更新的格式创建它们。使用政策或第三方要求对各个需求进行标注或标记，以便于维护和审计，使其更简便高效。益处 为产品团队提供如何遵守安全政策的共同理解 活动 协助持续实施和验证对政策和标准的遵从性，开发与每个适用要求相关的应用程序安全和适当的测试脚本。将这些文档整理成库，并以最适合纳入各个应用程序的格式提供给所有应用团队。清楚地标记文档，并将其链接到它们所代表的政策和标准，以协助持续的更新和维护。版本策略和标准，并在每次迭代更新时包含详细的变更日志，以便更容易地将其持续纳入不同产品的 SDLC 中。以与现有需求管理流程一致的格式编写应用程序安全需求。您可能需要多个版本，以适应不同的开发方法或技术。目标是让各个产品团队能够轻松地将政策和标准融入其现有的开发生命周期，几乎不需要对要求进行解释。测试脚本通过明确应用功能的预期来强化应用安全需求，并指导可能已经是开发过程一部分的自动或手动测试工作。这些努力不仅帮助每个团队建立对现有政策和标准的合规现状的了解，还能确保在应用程序持续变化时的合规性。好处在于理解您的组织在政策和标准方面的合规情况。活动：制定一个程序，以衡量每个应用程序对现有政策和标准的合规情况。强制性要求应在所有团队中有理由地提出并始终如一地报告。尽可能将合规状态与自动化测试绑定，并在每个版本中进行报告。合规报告包括政策和标准的版本以及适当的代码覆盖因素。鼓励不合规的团队查看可用资源，如安全要求和测试脚本，以确保不合规不是由于指导不足造成的。将因指导不足引起的问题转发给负责发布应用程序要求和测试脚本的团队，以便在未来的版本中加以改进。将因无法遵守政策和标准而产生的问题升级到处理应用程序安全风险的团队。标准：你有定期生成合规报告的程序（如果可能，最好是自动化的）| 你向所有相关利益相关者提供合规报告 | 利益相关者使用报告的合规状态信息来识别需要改进的领域

好处 共同理解贵组织的安全状况 活动 根据应用程序的风险暴露情况，了解现有或可能存在的威胁，以及高层领导对这些风险的容忍度。这种理解是确定软件安全保障优先级的关键组成部分。为了确定这些威胁，请采访企业主和利益相关者，并记录组织所在行业特有的驱动因素以及组织本身特有的驱动因素。收集的信息包括可能影响组织的最坏情况，以及通过优化的软件开发生命周期和更安全的应用程序可能提供的市场差异化或创造额外机会。收集的信息为组织开发和推进其应用程序安全计划提供了基准。项目中的事项按优先顺序处理，以应对对组织最重要的威胁和机遇。基线被分为若干风险因素和驱动因素，这些因素与组织的优先事项直接相关，并用于通过记录每个自定义开发应用程序在被破坏时可能对组织造成的影响，帮助建立其风险概况。基线和个体风险因素应予以公布，并提供给应用开发团队，以确保在创建应用风险概况和将组织优先事项纳入项目过程时更加透明。此外，这些目标应提供一组具体的目标，用于确保所有应用程序安全计划的改进能够直接支持组织当前和未来的需求。可用收益及已商定的应用安全（AppSec）计划路线图 基于资产规模、威胁和风险承受能力，制定安全战略计划和预算，以应对与应用安全相关的业务优先事项。该计划涵盖1至3年，并包括与组织的业务驱动因素和风险相一致的里程碑。它提供战术和战略举措，并遵循一条使其与业务优先事项和需求保持一致的路线图。在路线图中，在需要财务支出的变更、流程和程序的变更以及影响组织文化的变更之间达到平衡。这种平衡有助于同时实现多个里程碑，同时不会过度消耗可用资源或开发团队。里程碑的频率足以帮助监控项目成功并触发及时的路线图调整。为了使项目成功，应用安全团队需要获得组织的相关利益者和应用开发团队的支持。已发布的计划可供任何需要支持或参与其实施的人使用。益处：使持续的应用安全程序与组织的业务目标保持一致。活动：您会定期审查应用安全计划，以确保其持续适用，并支持组织不断变化的需求和未来的发展。为此，您需要每年至少重复执行本安全实践前两个成熟度级别的步骤。其目标是确保计划始终支持组织的当前和未来需求，从而保证该计划与业务保持一致。除了审查业务驱动因素外，组织还会密切监控每个路线图里程碑的实施成功情况。您根据多种标准评估里程碑的成功，包括实施的完整性和效率、预算考虑以及该计划可能带来的任何文化影响或变化。您还会审查未完成或不令人满意的里程碑，并评估对整体项目可能的调整。该组织为负责软件开发的管理层和团队开发仪表板和衡量指标，以监控路线图的实施情况。这些仪表板足够详细，能够识别各个项目和举措，并清晰地了解该计划是否成功以及是否符合组织的需求。标准：您需要把握组织高层管理的风险偏好 | 组织领导审核并批准风险清单 | 您需要识别对资产和数据的主要业务和技术威胁 | 您需要记录风险并存储在易于访问的位置

好处 共同理解贵组织的安全状况 活动 根据应用程序的风险暴露情况，了解现有或可能存在的威胁，以及高层管理对这些风险的容忍度。这种理解是确定软件安全保障优先级的关键组成部分。为了确定这些威胁，请采访企业主和利益相关者，并记录组织所在行业特有的驱动因素以及组织本身特有的驱动因素。收集的信息包括可能影响组织的最坏情况，以及通过优化的软件开发生命周期和更安全的应用程序可能提供的市场差异化或创造额外机会。收集的信息为组织开发和推进其应用程序安全计划提供了基线。项目中的事项按优先顺序处理，以应对对组织最重要的威胁和机遇。基线被分为若干风险因素和驱动因素，这些因素与组织的优先事项直接相关，并用于通过记录每个自定义开发应用程序在被破坏时可能对组织造成的影响，帮助建立其风险概况。基线和个体风险因素应予以公布，并提供给应用开发团队，以确保在创建应用风险概况和将组织优先事项纳入项目过程时更加透明。此外，这些目标应提供一系列具体目标，用于确保所有应用程序安全计划的改进能够直接支持组织当前和未来的需求。可用收益及已商定的应用安全（AppSec）计划路线图 基于资产规模、威胁和风险承受能力，制定安全战略计划和预算，以应对与应用安全相关的业务优先事项。该计划涵盖1至3年，并包括与组织的业务驱动因素和风险相一致的里程碑。它提供战术和战略举措，并遵循一条使其与业务优先事项和需求保持一致的路线图。在路线图中，在需要财务支出的变更、流程和程序的变更以及影响组织文化的变更之间达到平衡。这种平衡有助于同时实现多个里程碑，同时不会过度消耗可用资源或开发团队。里程碑的频率足以帮助监控项目成功并触发及时的路线图调整。为了使项目成功，应用安全团队需要获得组织的相关利益者和应用开发团队的支持。已发布的计划可供任何需要支持或参与其实施的人使用。益处：使持续的应用安全程序与组织的业务目标保持一致。活动：您会定期审查应用安全计划，以确保其持续适用，并支持组织不断变化的需求和未来的发展。为此，您需要每年至少重复执行本安全实践前两个成熟度级别的步骤。其目标是确保计划始终支持组织的当前和未来需求，从而保证该计划与业务保持一致。除了审查业务驱动因素外，组织还会密切监控每个路线图里程碑的实施成功情况。您根据多种标准评估里程碑的成功，包括实施的完整性和效率、预算考虑以及该计划可能带来的任何文化影响或变化。您会审查未达标或不令人满意的里程碑，并评估对整体项目可能的调整。该组织为负责软件开发的管理层和团队开发仪表板和衡量指标，以监控路线图的实施情况。这些仪表板足够详细，能够识别各个项目和举措，并清晰地了解该计划是否成功以及是否符合组织的需求。标准：计划反映了组织的业务优先事项和风险偏好 | 计划包括可衡量的里程碑和预算 | 计划与组织的业务推动因素和风险一致 | 计划为战略和战术举措制定了路线图 | 您已获得包括开发团队在内的利益相关者的支持

好处 共同理解贵组织的安全状况 活动 根据应用程序的风险暴露情况，了解现有或可能存在的威胁，以及高层领导对这些风险的容忍度。这种理解是确定软件安全保障优先级的关键组成部分。为了确定这些威胁，请采访企业主和利益相关者，并记录组织所在行业特有的驱动因素以及组织本身特有的驱动因素。收集的信息包括可能影响组织的最坏情况，以及通过优化的软件开发生命周期和更安全的应用程序可能提供的市场差异化或创造额外机会。收集的信息为组织开发和推进其应用程序安全计划提供了基线。项目中的事项按优先顺序处理，以应对对组织最重要的威胁和机遇。基线被分为若干风险因素和驱动因素，这些因素与组织的优先事项直接相关，并用于通过记录每个自定义开发应用程序在被破坏时可能对组织造成的影响，帮助建立其风险概况。基线和个体风险因素应予以公布，并提供给应用开发团队，以确保在创建应用风险概况和将组织优先事项纳入项目过程时更加透明。此外，这些目标应提供一组具体的目标，用于确保所有应用程序安全计划的改进能够直接支持组织当前和未来的需求。可用收益及已商定的应用安全（AppSec）计划路线图 基于资产规模、威胁和风险承受能力，制定安全战略计划和预算，以应对与应用安全相关的业务优先事项。该计划涵盖1到3年，并包括与组织的业务驱动因素和风险相一致的里程碑。它提供战术和战略举措，并遵循一条使其与业务优先事项和需求保持一致的路线图。在路线图中，需要在需要财务支出的变更、流程和程序的变更以及影响组织文化的变更之间取得平衡。这种平衡有助于同时实现多个里程碑，同时不会过度消耗可用资源或开发团队。里程碑的频率足以帮助监控项目成功并触发及时的路线图调整。为了使项目成功，应用安全团队需要获得组织的相关利益者和应用开发团队的支持。已发布的计划可供任何需要支持或参与其实施的人使用。益处：使持续的应用安全程序与组织的业务目标保持一致。活动：您会定期审查应用安全计划，以确保其持续适用，并支持组织不断变化的需求和未来的发展。为此，您需要每年至少重复执行本安全实践前两个成熟度级别的步骤。其目标是让计划始终支持组织的当前和未来需求，从而确保该计划与业务保持一致。除了审查业务驱动因素外，组织还会密切监控每个路线图里程碑的实施成功情况。您根据多种标准评估里程碑的成功，包括实施的完整性和效率、预算考虑以及该计划可能带来的任何文化影响或变化。您会审查未达标或不令人满意的里程碑，并评估对整体项目可能的调整。该组织为负责软件开发的管理层和团队开发仪表板和衡量指标，以监控路线图的实施情况。这些仪表板足够详细，能够识别各个项目和举措，并清晰地了解该项目是否成功以及是否符合组织的需求。标准：您会根据业务环境、组织或其风险偏好的重大变化审查并更新计划 | 计划更新步骤包括与所有相关方一起审查计划，并更新业务驱动因素和战略 | 您会根据已完成的路线图活动中获得的经验教训调整计划和路线图 | 您会发布路线图活动的进展信息，确保所有相关方都能获取这些信息

好处 了解您的应用安全（AppSec）计划的有效性和效率 活动 定义并记录用于评估应用安全计划有效性和效率的指标。这样，改进是可衡量的，并且您可以利用这些改进来确保未来对该计划的支持和资金。考虑到大多数开发环境的动态性质，指标应包括以下类别的测量：`工作量`指标衡量在安全方面投入的工作量。例如培训时间、进行代码审查所花费的时间，以及扫描漏洞的应用程序数量。`结果`指标衡量安全工作取得的成果。示例包括存在安全缺陷的未修补补丁数量以及涉及应用程序漏洞的安全事件数量。`环境`指标衡量安全工作进行的环境。示例包括应用程序数量或代码行数，用以衡量难度或复杂性。每个指标本身都对特定用途有用，但将两个或三个指标结合在一起有助于解释指标趋势的峰值。例如，总漏洞数量的激增可能是由于组织上线了几个以前未受应用安全机制保护的新应用程序所导致的。或者，如果环境指标增加而努力或结果没有相应增加，这可能表明安全计划已经成熟且高效。在识别指标时，通常建议坚持使用符合多个标准的指标：持续测量、收集成本低、以基数或百分比表示、以计量单位表示。记录指标，并包括数据收集的最佳和最有效方法的描述，以及将各个度量组合成有意义指标的推荐方法。例如，单独来看，多个应用程序的数量和所有应用程序的总缺陷数可能没什么用，但当将它们结合为每个应用程序的未解决高严重性缺陷数量时，它们会提供一个更具操作性的指标。应用安全计划绩效的透明化效益 一旦组织定义了其应用安全指标，就收集足够的信息以制定切实可行的目标。测试已识别的指标，确保能够在短时间内持续高效地收集数据。在初步测试期之后，组织应有足够的信息来确定通过关键绩效指标（KPI）表达的目标和宗旨。虽然有几种指标可用于监控信息安全计划及其有效性，但KPI是由最有意义和最有效的度量指标组成的。旨在将应用程序开发环境中常见的波动从关键绩效指标中剔除，以减少由于临时或误导性的个别测量结果导致的不利数字的可能性。将关键绩效指标基于被认为对信息安全专业人员以及负责应用程序整体成功的个人和组织领导层都具有价值的指标。将关键绩效指标视为整个项目成功的确定性指标，并认为它们是可操作的。完整记录关键绩效指标，并分发给对项目成功有所贡献的团队以及组织的领导层。理想情况下，应简要说明每个关键绩效指标的信息来源，以及数字高或低的含义。包括短期和长期目标，以及需要立即干预的不合格测量范围。与应用安全和应用开发团队共享行动计划，以确保组织目标和宗旨得到充分透明的理解。好处 根据结果持续改进您的项目 活动 根据关键绩效指标（KPI）和其他应用安全指标，制定影响应用安全项目的指南。这些指南结合了应用开发过程和流程的成熟度与不同的指标，从而提升项目的效率。以下示例展示了测量与发展和改进应用程序安全方式之间的关系。关注开发生命周期的成熟度，通过主动应用安全措施可以降低每个缺陷的相对成本。监控努力、结果和环境指标之间的平衡可以提高程序的效率，并为额外的自动化及其他改进整体应用安全基线的方法提供依据。个别安全实践可以提供各个应用安全举措成功或失败的指标。工作量指标有助于确保应用程序安全工作集中在更相关和重要的技术和领域。在定义整体指标策略时，要牢记最终目标，并尽早明确可以根据关键绩效指标（KPI）和指标的变化做出的决策，以帮助指导指标的开发。标准：您需要记录每个指标，包括来源描述、测量覆盖范围，以及如何使用这些指标来解释应用程序安全趋势的指导 | 指标包括努力、结果和环境测量类别的衡量 | 大多数指标测量频繁，易于或成本低廉收集，并以基数或百分比表示 | 应用程序安全和开发团队会发布这些指标

好处 了解您的应用安全（AppSec）计划的有效性和效率 活动 定义并记录用于评估应用安全计划有效性和效率的指标。这样，改进是可衡量的，并且您可以利用这些改进来确保未来对该计划的支持和资金。考虑到大多数开发环境的动态性质，指标应包括以下类别的测量：`工作量`指标衡量在安全方面投入的工作量。例如培训时间、进行代码审查所花费的时间，以及扫描漏洞的应用程序数量。`结果`指标衡量安全工作取得的成果。示例包括存在安全缺陷的未修补补丁数量以及涉及应用程序漏洞的安全事件数量。`环境`指标衡量安全工作进行的环境。示例包括应用程序数量或代码行数，用以衡量难度或复杂性。每个指标本身都对特定用途有用，但将两个或三个指标结合在一起有助于解释指标趋势的峰值。例如，总漏洞数量的激增可能是由于组织上线了几个以前未受应用安全机制保护的新应用程序所导致的。或者，如果环境指标增加而努力或结果没有相应增加，这可能表明安全计划已经成熟且高效。在识别指标时，通常建议坚持使用符合多个标准的指标：持续测量、收集成本低、以基数或百分比表示、以计量单位表示。记录指标，并包括用于收集数据的最佳和最有效方法的描述，以及将各个指标组合成有意义指标的推荐方法。例如，单独来看，多个应用程序的数量和所有应用程序的总缺陷数可能没什么用，但当将它们结合为每个应用程序的未解决高严重性缺陷数量时，它们会提供一个更具操作性的指标。应用安全计划绩效的透明化效益 一旦组织定义了其应用安全指标，就收集足够的信息以制定切实可行的目标。测试已识别的指标，确保能够在短时间内持续高效地收集数据。在初步测试期之后，组织应有足够的信息来确定通过关键绩效指标（KPI）表达的目标和宗旨。虽然有几种指标可用于监控信息安全计划及其有效性，但KPI是由最有意义和最有效的度量指标组成的。旨在将应用程序开发环境中常见的波动从关键绩效指标中剔除，以减少由于临时或误导性的个别测量结果导致不利数字的可能性。将关键绩效指标基于被认为对信息安全专业人员以及负责应用程序整体成功的个人和组织领导层都具有价值的指标。将关键绩效指标视为整个项目成功的确定性指标，并认为它们是可操作的。完整记录关键绩效指标，并分发给对项目成功做出贡献的团队以及组织领导层。理想情况下，应简要说明每个关键绩效指标的信息来源，以及数字高或低的含义。包括短期和长期目标，以及需要立即干预的不合格测量范围。与应用安全和应用开发团队共享行动计划，以确保组织目标和宗旨得到充分透明的理解。好处 根据结果持续改进您的项目 活动 根据关键绩效指标（KPI）和其他应用安全指标，制定影响应用安全项目的指南。这些指南结合了应用开发过程和流程的成熟度与不同的指标，以提高项目的效率。以下示例展示了测量与发展和改进应用程序安全方式之间的关系。关注开发生命周期的成熟度，通过主动应用安全措施可以降低每个缺陷的相对成本。监控努力、结果和环境指标之间的平衡可以提高程序的效率，并为额外的自动化及其他改进整体应用安全基线的方法提供依据。个别安全实践可以提供各个应用安全举措成功或失败的指标。工作量指标有助于确保应用程序安全工作集中在更相关和重要的技术和领域。在定义整体指标策略时，要牢记最终目标，并尽早明确可以根据关键绩效指标（KPI）和指标的变化做出的决策，以帮助指导指标的开发。标准：您在收集了足够的信息以设定实际目标后定义了关键绩效指标（KPI） | 您在获得领导层及负责应用安全的团队认可的情况下制定了KPI | 应用团队可以获取KPI，并且KPI包括可接受的阈值及在团队需要采取行动时的指导 | 应用安全计划的成功可以通过定义的KPI清晰地体现

好处 了解您的应用安全（AppSec）计划的有效性和效率 活动 定义并记录用于评估应用安全计划有效性和效率的指标。这样，改进是可衡量的，并且您可以利用这些改进来确保未来对该计划的支持和资金。考虑到大多数开发环境的动态性质，指标应包括以下类别的测量：`工作量`指标衡量在安全方面投入的工作量。例如培训小时数、进行代码审查所花费的时间以及扫描漏洞的应用程序数量。`结果`指标衡量安全工作所取得的成果。示例包括存在安全缺陷的未修补补丁数量以及涉及应用程序漏洞的安全事件数量。`环境`指标衡量安全工作进行的环境。示例包括应用程序数量或代码行数，用以衡量难度或复杂性。每个指标本身都对特定用途有用，但将两个或三个指标结合在一起有助于解释指标趋势的峰值。例如，总漏洞数量的激增可能是由于组织上线了几个以前未受应用安全机制保护的新应用程序所导致的。或者，如果环境指标增加而努力或结果没有相应增加，这可能表明安全计划已经成熟且高效。在识别指标时，通常建议坚持使用符合几个标准的指标：持续测量、收集成本低、以基数或百分比表示、以计量单位表示。记录指标，并包括用于收集数据的最佳和最有效方法的描述，以及将各个指标组合成有意义指标的推荐方法。例如，单独来看，多个应用程序的数量和所有应用程序的总缺陷数可能没什么用，但当将它们结合为每个应用程序的未解决高严重性缺陷数量时，它们会提供一个更具操作性的指标。应用安全计划绩效的透明化效益 一旦组织定义了其应用安全指标，就收集足够的信息以制定切实可行的目标。测试已识别的指标，确保能够在短时间内持续高效地收集数据。在初步测试期之后，组织应有足够的信息来确定通过关键绩效指标（KPI）表达的目标和宗旨。虽然有几种指标可用于监控信息安全计划及其有效性，但KPI是由最有意义和最有效的度量指标组成的。旨在将应用程序开发环境中常见的波动从关键绩效指标中剔除，以减少因临时或误导性的个别测量而导致不利结果的可能性。将关键绩效指标基于被认为对信息安全专业人员以及负责应用程序整体成功的个人和组织领导层都具有价值的指标。将关键绩效指标视为整个项目成功的确定性指标，并认为它们是可操作的。完整记录关键绩效指标，并分发给对项目成功做出贡献的团队以及组织领导层。理想情况下，应简要说明每个关键绩效指标的信息来源，以及数字高或低的含义。包括短期和长期目标，以及需要立即干预的不合格测量范围。与应用安全和应用开发团队共享行动计划，以确保组织目标和宗旨得到充分透明的理解。好处 根据结果持续改进您的项目 活动 根据关键绩效指标（KPI）和其他应用安全指标，制定影响应用安全项目的指南。这些指南结合了应用开发过程和流程的成熟度与不同的指标，以提高项目的效率。以下示例展示了测量与发展和改进应用程序安全方式之间的关系。关注开发生命周期的成熟度，通过主动应用安全措施可以降低每个缺陷的相对成本。监控努力、结果和环境指标之间的平衡可以提高程序的效率，并为额外的自动化及其他改进整体应用安全基线的方法提供依据。个别安全实践可以提供各个应用安全举措成功或失败的指标。工作量指标有助于确保应用程序安全工作集中在更相关和重要的技术和领域。在定义整体指标策略时，要牢记最终目标，并尽早明确通过关键绩效指标和指标的变化可以做出哪些决策，以帮助指导指标的开发。标准：您至少每年评估一次关键绩效指标（KPI）的效率和有效性 | KPI 和应用安全指标触发大部分应用安全策略的调整

已知影响特定应用程序的安全缺陷的收益透明度 活动 引入安全缺陷的通用定义/理解，并定义识别这些缺陷的最常见方法。这些通常包括但不限于：威胁评估、渗透测试、静态和动态分析扫描工具的输出、负责任的披露流程或漏洞赏金。培养透明文化，避免指责任何团队引入或发现安全缺陷。将所有安全缺陷记录并跟踪在指定位置。这个位置不一定必须对整个组织来说是集中式的，但要确保您能够在任何时间点概览影响特定应用程序的所有缺陷。定义并应用跟踪的安全缺陷的访问规则，以降低信息泄露和滥用的风险。至少引入安全缺陷的初步定性分类，以便能够相应地优先处理修复工作。努力减少信息重复和误报的存在，以提高流程的可信度。好处 对安全缺陷进行一致的分类，并明确其处理预期。 活动 在整个组织中一致地引入并应用明确定义的安全缺陷评级方法，基于缺陷被利用的概率和预期影响。这将帮助您识别需要更多关注和投资的应用程序。如果你没有集中存储有关安全缺陷的信息，请确保仍然能够轻松地从所有来源获取信息，并对需要关注的“热点”进行概览。根据安全缺陷的严重性等级引入按时修复的服务水平协议(SLA)，并集中监控及定期报告SLA违约情况。为在服务级别协议（SLA）规定的时间内无法或不经济修复缺陷的情况定义一个流程。这至少应确保所有相关利益相关者对所施加的风险有充分的了解。如果适用，可针对这些情况采取补偿性控制措施。即使您没有针对低严重性缺陷的正式服务级别协议（SLA），也要确保相关团队仍能定期了解影响其应用程序的问题，并理解特定问题如何相互影响或放大。益处：确保安全缺陷在预定义的SLA内得到处理。活动：如果修复时间超过定义的SLA，则实施对安全缺陷的自动警报。确保这些缺陷能自动转入风险管理流程，并通过一致的量化方法进行评估。评估特定缺陷如何相互影响/放大，不仅在各个团队层面上，而且在整个组织层面上。利用完整杀伤链的知识来优先排序、引入并跟踪减轻相应业务风险的补偿控制措施。将缺陷管理系统与其他实践引入的自动化工具集成，例如构建与部署：如果安全缺陷达到某一严重级别并影响最终产物，则使构建/部署过程失败，除非有人明确批准例外。监控：如果可能，确保在生产环境中滥用安全缺陷的行为能够被识别并发出警报。标准：您可以轻松概览影响一个应用程序的所有安全缺陷 | 您至少拥有一个基本的分类方案 | 该流程包含处理误报和重复条目的策略 | 缺陷管理系统涵盖来自各种来源和活动的缺陷

已知影响特定应用程序的安全缺陷的收益透明度 活动 引入对安全缺陷的共同定义/理解，并定义识别这些缺陷的最常见方法。这些通常包括但不限于：威胁评估、渗透测试、静态和动态分析扫描工具的输出、负责任的披露流程或漏洞赏金。培养透明文化，避免指责任何团队引入或发现安全缺陷。将所有安全缺陷记录并跟踪在指定位置。这个位置不一定必须对整个组织来说是集中式的，但要确保您能够在任何时间点概览影响特定应用程序的所有缺陷。定义并应用跟踪的安全缺陷的访问规则，以降低信息泄露和滥用的风险。至少引入安全缺陷的初步定性分类，以便能够相应地优先处理修复工作。努力减少信息重复和误报的存在，以提高流程的可信度。好处 对安全缺陷进行一致的分类，并明确其处理预期。 活动 在整个组织中一致地引入并应用明确定义的安全缺陷评级方法，基于缺陷被利用的概率和预期影响。这将帮助您识别需要更多关注和投资的应用程序。如果你没有集中存储有关安全缺陷的信息，请确保仍然能够轻松地从所有来源获取信息，并对需要关注的“热点”进行概览。根据安全缺陷的严重性等级引入按时修复的服务水平协议(SLA)，并集中监控及定期报告SLA违约情况。为在服务级别协议（SLA）规定的时间内无法或不经济修复缺陷的情况定义一个流程。这至少应确保所有相关利益相关者对所施加的风险有充分的了解。如果适用，可针对这些情况采取补偿性控制措施。即使您没有针对低严重性缺陷的正式服务级别协议（SLA），也要确保相关团队仍能定期了解影响其应用程序的问题，并理解特定问题如何相互影响或放大。益处：确保安全缺陷在预定义的SLA内得到处理。活动：如果修复时间超过定义的SLA，则实施对安全缺陷的自动警报。确保这些缺陷能自动转入风险管理流程，并通过一致的量化方法进行评估。评估特定缺陷如何相互影响/放大，不仅在各个团队层面上，而且在整个组织层面上。利用完整杀伤链的知识来优先排序、引入并跟踪减轻相应业务风险的补偿性控制措施。将你的缺陷管理系统与其他实践引入的自动化工具集成，例如。构建与部署：如果安全缺陷达到某一严重级别并影响最终产物，则使构建/部署过程失败，除非有人明确批准例外。监控：如果可能，确保在生产环境中滥用安全缺陷的行为能够被识别并发出警报。标准：在整个组织中对所有缺陷应用单一严重性方案 | 该方案包括针对特定严重性类别的修复服务水平协议（SLA） | 您定期报告对SLA的遵守情况

已知影响特定应用程序的安全缺陷的收益透明度 活动 引入对安全缺陷的共同定义/理解，并定义识别这些缺陷的最常见方法。这些通常包括但不限于：威胁评估、渗透测试、静态和动态分析扫描工具的输出、负责任的披露流程或漏洞赏金。培养透明文化，避免指责任何团队引入或发现安全缺陷。将所有安全缺陷记录并跟踪在指定位置。这个位置不一定必须对整个组织来说是集中式的，但要确保您能够在任何时间点获取特定应用程序的所有缺陷的概览。为跟踪的安全缺陷定义并应用访问规则，以降低信息泄露和滥用的风险。至少引入安全缺陷的初步定性分类，以便能够相应地优先处理修复工作。努力减少信息重复和误报的存在，以提高流程的可信度。好处 对安全缺陷进行一致的分类，并明确其处理预期。 活动 在整个组织中一致地引入并应用明确定义的安全缺陷评级方法，基于缺陷被利用的概率和预期影响。这将帮助您识别需要更多关注和投资的应用程序。如果你没有集中存储有关安全缺陷的信息，请确保仍然能够轻松地从所有来源获取信息，并对需要关注的“热点”进行概览。根据安全缺陷的严重性等级引入按时修复的服务水平协议(SLA)，并集中监控及定期报告SLA违约情况。为在服务级别协议（SLA）规定的时间内无法或不经济修复缺陷的情况定义一个流程。这至少应确保所有相关利益相关者对所施加的风险有充分的了解。如果适用，可针对这些情况采取补偿性控制措施。即使您没有针对低严重性缺陷的正式服务级别协议（SLA），也要确保相关团队仍能定期了解影响其应用程序的问题，并理解特定问题如何相互影响或放大。益处：确保安全缺陷在预定义的SLA内得到处理。活动：如果修复时间超过定义的SLA，则实施对安全缺陷的自动警报。确保这些缺陷能自动转入风险管理流程，并通过一致的量化方法进行评估。评估特定缺陷如何相互影响/放大，不仅在各个团队层面上，而且在整个组织层面上。利用完整杀伤链的知识来优先排序、引入并跟踪减轻相应业务风险的补偿性控制措施。将你的缺陷管理系统与其他实践引入的自动化工具集成，例如。构建与部署：如果安全缺陷达到某一严重级别并影响最终产物，则使构建/部署过程失败，除非有人明确批准例外。监控：如果可能，确保在生产环境中滥用安全缺陷的行为能够被识别并发出警报。标准：您会自动警报服务水平协议（SLA）违约情况，并将相应缺陷转移到风险管理流程中 | 您将相关工具（例如监控、构建、部署）与缺陷管理系统集成

益处 在构建过程中将人为错误的风险降至最低，从而减少安全问题。 活动 定义构建过程，将其分解为一组清晰的指令，由人工或自动化工具遵循。构建过程定义描述了整个端到端的过程，以便人工或工具每次都能一致地遵循并产生相同的结果。定义是集中存储的，任何工具或人员都可以访问。避免存储多个副本，因为它们可能会变得不一致或过时。流程定义不包含任何机密信息（特别是构建过程中需要的机密）。审查任何构建工具，确保它们由供应商积极维护并且已经更新了安全补丁。将每个工具的配置加固，以确保其符合供应商指南和行业最佳实践。为每个生成的工件确定一个值，以便以后用于验证其完整性，例如签名或哈希值。保护该值，如果工件已签名，则保护私有签名证书。确保构建工具定期打补丁并正确加固。优势 通过集成安全工具实现高效的构建流程 活动 自动化构建流程，以便随时能够一致地执行构建。构建过程通常不应需要任何干预，从而进一步降低人为错误的可能性。使用自动化系统增加了对构建工具安全性的依赖，因此加强和维护工具集变得更加重要。特别关注这些工具的界面，例如基于网络的门户以及它们如何被锁定。构建工具暴露在网络环境中可能会使恶意行为者篡改流程的完整性。例如，这可能允许恶意代码被嵌入到软件中。自动化流程可能需要访问构建软件所需的凭据和秘密，例如代码签名证书或访问存储库的权限。请谨慎处理这些信息。使用能够识别构建该软件的组织或业务单元的证书对生成的工件进行签名，以便验证其完整性。最后，添加适当的自动化安全检查（例如在流水线中使用 SAST 工具) 利用自动化实现安全效益。效益 确保你构建的软件符合安全基线。活动 定义适合在构建过程中执行的安全检查，以及通过构建的最低标准——这些标准可能会根据不同应用的风险状况而有所不同。在构建中包含相应的安全检查，并在未满足预定义标准时强制中断构建过程。对低于阈值的问题触发警告，并将其记录到集中系统中，以便跟踪并采取措施。如果可行，可实现例外机制，以便在特定漏洞的风险已被接受或缓解时绕过此行为。但是，请确保这些情况首先获得明确批准，并记录它们的发生情况及理由。如果技术限制阻止组织自动中断构建，请通过其他措施实现同样的效果，例如明确的政策和定期审计。在单独的集中服务器上处理代码签名，该服务器不会将证书暴露给执行构建的系统。在可能的情况下，使用一种确定性方法，以输出逐字节可重现的工件。标准：您有足够的信息来重新创建构建过程 | 您的构建文档是最新的 | 您的构建文档存储在可访问的位置 | 在构建过程中生成的工件校验和用于后续验证 | 您会加固构建过程中使用的工具

益处 在构建过程中将人为错误的风险降至最低，从而减少安全问题。 活动 定义构建过程，将其分解为一组清晰的指令，由人工或自动化工具遵循。构建过程定义描述了整个端到端的过程，以便人工或工具每次都能一致地遵循并产生相同的结果。定义是集中存储的，任何工具或人员都可以访问。避免存储多个副本，因为它们可能会变得不一致或过时。流程定义不包含任何机密信息（特别是构建过程中需要的机密）。审查任何构建工具，确保它们由供应商积极维护并且已经更新了安全补丁。将每个工具的配置加固，以确保其符合供应商指南和行业最佳实践。为每个生成的工件确定一个值，以便以后用于验证其完整性，例如签名或哈希值。保护该值，如果工件已签名，则保护私有签名证书。确保构建工具定期打补丁并正确加固。优势 通过集成安全工具实现高效的构建流程 活动 自动化构建流程，以便随时能够一致地执行构建。构建过程通常不应需要任何干预，从而进一步降低人为错误的可能性。使用自动化系统增加了对构建工具安全性的依赖，因此加强和维护工具集变得更加重要。特别关注这些工具的界面，例如基于网络的门户以及它们如何被锁定。构建工具暴露在网络环境中可能会让恶意行为者篡改流程的完整性。例如，这可能允许恶意代码被嵌入到软件中。自动化流程可能需要访问构建软件所需的凭据和秘密，例如代码签名证书或访问存储库的权限。请谨慎处理这些信息。使用能够识别构建该软件的组织或业务单元的证书对生成的工件进行签名，以便验证其完整性。最后，添加适当的自动化安全检查（例如在流水线中使用 SAST 工具) 利用自动化实现安全效益。效益 确保你构建的软件符合安全基线。活动 定义适合在构建过程中执行的安全检查，以及通过构建的最低标准——这些标准可能会根据不同应用的风险状况而有所不同。在构建中包含相应的安全检查，并在未满足预定义标准时强制中断构建过程。对低于阈值的问题触发警告，并将其记录到集中系统中，以便跟踪并采取措施。如果可行，实现一个例外机制，以便在特定漏洞的风险已经被接受或缓解时绕过此行为。但是，请确保这些情况首先获得明确批准，并记录它们的发生情况及理由。如果技术限制阻止组织自动中断构建，请通过其他措施实现同样的效果，例如明确的政策和定期审计。在单独的集中服务器上处理代码签名，该服务器不会将证书暴露给执行构建的系统。在可能的情况下，使用一种确定性方法，输出逐字节可再现的产物。标准：构建过程本身不需要任何人工干预 | 您的构建工具已按照最佳实践和供应商指南加固 | 您对构建工具所需的密钥进行加密，并根据最小特权原则控制访问

益处 在构建过程中将人为错误的风险降至最低，从而减少安全问题。 活动 定义构建过程，将其分解为一组清晰的指令，由人工或自动化工具遵循。构建过程定义描述了整个端到端的过程，以便人工或工具每次都能一致地遵循并产生相同的结果。定义是集中存储的，任何工具或人员都可以访问。避免存储多个副本，因为它们可能会变得不一致或过时。流程定义不包含任何机密信息（特别是构建过程中需要的机密）。审查任何构建工具，确保它们由供应商积极维护并且已经更新了安全补丁。将每个工具的配置加固，以确保其符合供应商指南和行业最佳实践。为每个生成的工件确定一个值，以便以后用于验证其完整性，例如签名或哈希值。保护该值，如果工件已签名，则保护私有签名证书。确保构建工具定期打补丁并正确加固。优势 通过集成安全工具实现高效的构建流程 活动 自动化构建流程，以便随时能够一致地执行构建。构建过程通常不应需要任何干预，从而进一步降低人为错误的可能性。使用自动化系统增加了对构建工具安全性的依赖，因此加强和维护工具集变得更加重要。特别关注这些工具的界面，例如基于网络的门户以及它们如何被锁定。构建工具暴露在网络环境中可能会使恶意行为者篡改流程的完整性。例如，这可能允许恶意代码被嵌入到软件中。自动化流程可能需要访问构建软件所需的凭据和秘密，例如代码签名证书或访问存储库的权限。请谨慎处理这些信息。使用能够识别构建该软件的组织或业务单元的证书对生成的工件进行签名，以便验证其完整性。最后，添加适当的自动化安全检查（例如在流水线中使用 SAST 工具) 利用自动化实现安全效益。效益 确保你构建的软件符合安全基线。活动 定义适合在构建过程中执行的安全检查，以及通过构建的最低标准——这些标准可能会根据不同应用的风险状况而有所不同。在构建中包含相应的安全检查，并在未满足预定义标准时强制中断构建过程。对低于阈值的问题触发警告，并将其记录到集中系统中，以便跟踪并采取措施。如果可行，可实现例外机制，以便在特定漏洞的风险已被接受或缓解时绕过此行为。但是，请确保这些情况首先获得明确批准，并记录它们的发生情况及理由。如果技术限制阻止组织自动中断构建，请通过其他措施实现同样的效果，例如明确的政策和定期审计。在单独的集中服务器上处理代码签名，该服务器不会将证书暴露给执行构建的系统。尽可能使用能够输出逐字节可再现制品的确定性方法。标准：如果应用程序未达到预定义的安全基线，则构建失败 | 对漏洞的严重性有最大可接受等级 | 在集中系统中记录警告和失败 | 至少每年选择并配置工具，根据安全要求评估每个应用程序

效益 部署过程中有限的人为错误风险 最大限度减少安全问题 活动 定义所有阶段的部署流程，将其拆分为一组清晰的指令，供人员或自动化工具执行。部署过程定义应从头到端描述整个流程，以便每次都能一致遵循，从而产生相同的结果。定义集中存储，所有相关人员均可访问。不要存储或分发多个副本，其中一些可能会过时。将应用程序部署到生产环境时，可使用自动化流程，或由非开发人员手动执行。确保开发人员在应用程序部署时无需直接访问生产环境。审核所有部署工具，确保它们由供应商积极维护并及时更新安全补丁。加强每个工具的配置，使其符合供应商的指南和行业最佳实践。鉴于这些工具大多数需要访问生产环境，因此它们的安全性至关重要。确保工具本身及其遵循的工作流程的完整性，并根据最小权限原则配置对这些工具的访问规则。让有权访问生产环境的人员至少经过最低级别的培训或认证，以确保他们在这一方面的能力。优势 通过集成的安全工具实现高效的部署流程 活动 自动化部署流程，覆盖各个阶段，无需手动配置步骤，从而消除孤立的人为错误风险。确保并验证部署在各个阶段的一致性。在部署流程中集成自动化安全检查，例如：使用动态应用安全测试（DAST）和漏洞扫描工具。同时，在适当的情况下，验证已部署工件的完整性。将这些测试的结果集中记录，并采取必要的措施。确保在检测到任何缺陷时，相关人员能够自动收到通知。如果发现任何超过预定义关键程度的问题，应自动停止或回滚部署，或引入单独的人工审批流程，以便记录此决策，并包含例外的解释。对所有阶段的所有部署进行记录和审计。建立一个系统来记录每次部署，包括执行部署的人、部署的软件版本以及与部署相关的任何相关变量。确保部署到生产环境的工件完整性 采取措施 利用在构建时签名的二进制文件，并通过将其签名与受信任的证书进行核对，自动验证正在部署的软件的完整性。这可能包括内部开发和构建的二进制文件，以及第三方工件。如果无法验证工件的签名，包括签名无效或证书过期的工件，请不要部署。如果受信任的证书列表中包含第三方开发者，请定期检查，并使其符合组织对受信第三方供应商的整体治理要求。在自动化部署过程中，至少手动批准一次部署。只要在部署过程中人工检查明显比自动检查更准确，就选择人工检查。标准：您拥有足够的信息来执行部署流程 | 您的部署文档是最新的 | 您的部署文档可供相关利益相关者访问 | 您确保只有定义好的合格人员可以触发部署 | 您强化了部署过程中使用的工具

好处 在部署过程中将人为错误的风险降至最低，从而减少安全问题。 活动 在各个阶段定义部署流程，将其分解为一系列清晰的指令，由人工或自动化工具执行。部署流程的定义应描述整个端到端的过程，以便每次都能一致地遵循，产生相同的结果。定义集中存储，所有相关人员均可访问。不要存储或分发多个副本，其中一些可能会过时。将应用程序部署到生产环境时，可使用自动化流程，或由非开发人员手动执行。确保开发人员不需要直接访问生产环境来进行应用部署。审核所有部署工具，确保它们由供应商积极维护并且已更新安全补丁。强化每个工具的配置，使其符合供应商指南和行业最佳实践。鉴于这些工具大多数需要访问生产环境，因此它们的安全性至关重要。确保工具本身及其遵循的工作流程的完整性，并根据最小权限原则配置对这些工具的访问规则。让有权访问生产环境的人员至少经过最低级别的培训或认证，以确保他们在此方面的能力。优势 通过集成安全工具实现高效的部署流程 活动 自动化部署流程以覆盖各个阶段，从而无需手动配置步骤，并消除孤立的人为错误风险。确保并验证部署在所有阶段的一致性。在您的部署流程中集成自动化安全检查，例如。使用动态应用安全测试（DAST）和漏洞扫描工具。同时，在适当的情况下，验证已部署工件的完整性。将这些测试的结果集中记录，并采取必要的措施。确保在检测到任何缺陷时，相关人员能够自动收到通知。如果发现任何超过预定义关键程度的问题，应自动停止或回滚部署，或引入单独的人工审批流程，以便记录此决策，并包含例外的解释。对所有阶段的所有部署进行记录和审计。建立一个系统来记录每次部署，包括执行部署的人、部署的软件版本以及与部署相关的任何重要变量。确保部署到生产环境的工件完整性 采取措施 利用在构建时签名的二进制文件，并通过将其签名与受信任的证书进行核对，自动验证正在部署的软件的完整性。这可能包括内部开发和构建的二进制文件，以及第三方工件。如果无法验证工件的签名，包括签名无效或已过期的证书，请不要部署工件。如果受信任证书列表中包含第三方开发者，请定期检查，并使其符合组织对受信第三方供应商的整体治理要求。在自动化部署过程中，至少手动批准一次部署。每当人工检查在部署过程中显著比自动化检查更准确时，请选择此选项。标准：部署流程在所有阶段都是自动化的 | 部署包括自动化安全测试程序 | 你会将发现的漏洞通知相关人员 | 你有过去部署的日志，并且这些日志保存了一定时间

好处 在部署过程中将人为错误的风险降至最低，从而减少安全问题。 活动 在各个阶段定义部署流程，将其分解为一系列清晰的指令，由人工或自动化工具执行。部署流程的定义应描述整个端到端的过程，以便每次都能一致地遵循，产生相同的结果。定义集中存储，所有相关人员均可访问。不要存储或分发多个副本，其中一些可能会过时。将应用程序部署到生产环境时，可使用自动化流程，或由非开发人员手动执行。确保开发人员在应用程序部署时无需直接访问生产环境。审核所有部署工具，确保它们由供应商积极维护并且已更新安全补丁。强化每个工具的配置，使其符合供应商指南和行业最佳实践。鉴于这些工具大多数需要访问生产环境，因此它们的安全性至关重要。确保工具本身及其遵循的工作流程的完整性，并根据最小权限原则配置对这些工具的访问规则。让有权访问生产环境的人员至少经过最低级别的培训或认证，以确保他们在这一方面的能力。优势 通过集成安全工具实现高效的部署流程 活动 自动化部署流程以覆盖各个阶段，从而无需手动配置步骤，并消除孤立的人为错误风险。确保并验证部署在所有阶段的一致性。在您的部署流程中集成自动化安全检查，例如。使用动态应用安全测试（DAST）和漏洞扫描工具。同时，在适当的情况下，验证已部署工件的完整性。将这些测试的结果集中记录，并采取必要的措施。确保在检测到任何缺陷时，相关人员能够自动收到通知。如果发现任何超过预定义关键程度的问题，应自动停止或回滚部署，或引入单独的人工审批流程，以便记录此决策，并包含例外的解释。对所有阶段的所有部署进行记录和审计。建立一个系统来记录每次部署，包括执行部署的人、部署的软件版本以及与部署相关的任何相关变量。确保部署到生产环境的工件完整性 采取措施 利用在构建时签名的二进制文件，并通过将其签名与受信任的证书进行核对，自动验证正在部署的软件的完整性。这可能包括内部开发和构建的二进制文件，以及第三方工件。如果无法验证工件的签名，包括签名无效或证书过期的工件，请不要部署。如果受信任的证书列表中包含第三方开发者，请定期检查，并使其符合组织对受信第三方供应商的整体治理要求。在自动化部署过程中，至少手动批准一次部署。每当在部署过程中人工检查的准确性明显高于自动化检查时，选择人工检查。标准：如果检测到完整性漏洞，你会阻止或回滚部署 | 验证是针对构建时生成的签名进行的 | 如果无法检查签名（例如外部构建的软件），你需引入补偿措施

受益于对组件的基本配置设置进行强化 活动 理解保护所使用技术栈的重要性，并根据可获取的指南（例如开源项目、供应商文档、博客文章）对栈元素应用安全配置。当你的团队根据试验和团队成员收集的信息为他们的应用程序制定配置指导时，鼓励他们在整个组织中分享他们的经验。识别常见技术堆栈的关键元素，并根据团队的实践经验，为这些元素建立配置标准。在这个成熟度水平上，您尚未建立管理配置基线的正式流程。配置可能无法在各个应用程序和部署中一致应用，并且可能缺乏合规性监控。好处：在组织中对技术栈组件进行一致的强化。活动：为所使用的每个技术栈中的所有组件建立配置强化基线。为了协助一致地应用加固基线，请为各个组件制定配置指南。要求产品团队将配置基线应用于所有新系统，并在可行的情况下应用于现有系统。将加固基线和配置指南纳入变更管理，并为每项分配负责人。所有者有持续的责任根据不断发展的最佳实践或相关组件的变化（例如版本更新、新功能）保持其最新。在较大的环境中，应从本地维护的主配置导出实例的配置，并应用相关的配置基线。使用自动化工具强化配置。优势 清晰了解组件配置，以避免不符合项 活动 积极监控已部署技术堆栈的安全配置，定期检查是否符合既定基线。确保配置检查的结果可以轻松获取，通过已发布的报告和仪表板提供。当您检测到不符合规范的配置时，应将每次出现视为安全问题，并在既定的缺陷管理实践中管理纠正措施。通过使用自动化措施（例如“自愈”配置和安全信息与事件管理（SIEM）警报），还可以实现进一步的收益。作为更新组件（例如...）过程的一部分新版本、供应商补丁)，审查相应的基线和配置指南，并根据需要更新它们，以保持其相关性和准确性。至少每年审查其他基线和配置指南。定期审查您的基线管理流程，结合应用和维护配置基线及配置指南的团队反馈和经验教训。标准：您已经识别了每个技术栈中使用的关键组件 | 您已经为每个关键组件建立了配置标准

受益于对组件的基本配置设置进行强化 活动 理解保护所使用技术栈的重要性，并根据可获取的指南（例如开源项目、供应商文档、博客文章）对栈元素应用安全配置。当你的团队根据试验和团队成员收集的信息为他们的应用程序制定配置指导时，鼓励他们在整个组织中分享他们的经验。识别常见技术堆栈的关键元素，并根据团队的实践经验，为这些元素建立配置标准。在这个成熟度水平上，您尚未建立管理配置基线的正式流程。配置可能无法在各个应用程序和部署中一致应用，并且可能缺乏合规性监控。好处：在组织中对技术栈组件进行一致的强化。活动：为所使用的每个技术栈中的所有组件建立配置强化基线。为了协助一致地应用加固基线，请为各个组件制定配置指南。要求产品团队将配置基线应用于所有新系统，并在可行的情况下应用于现有系统。将加固基线和配置指南纳入变更管理，并为每项分配负责人。所有者有持续的责任根据不断发展的最佳实践或相关组件的变化（例如版本更新、新功能）保持其最新。在较大的环境中，应从本地维护的主配置中派生实例的配置，并应用相关的配置基线。使用自动化工具来强化配置。优势 清晰了解组件配置，以避免不符合项 活动 积极监控已部署技术堆栈的安全配置，定期检查是否符合既定基线。确保配置检查的结果可以轻松获取，通过已发布的报告和仪表板提供。当您检测到不符合规范的配置时，应将每次出现都视为安全问题，并在既定的缺陷管理实践中管理纠正措施。通过使用自动化手段，如“自我修复”配置和安全信息及事件管理（SIEM）警报，还可以实现进一步的收益。作为更新组件（例如新版本、供应商补丁)，审查相应的基线和配置指南，并根据需要更新它们，以保持其相关性和准确性。至少每年审查其他基线和配置指南。定期审查基线管理流程，结合应用和维护配置基线及配置指南的团队反馈和经验教训。标准：您已为每个基线分配了负责人 | 负责人会保持其分配的基线更新 | 您将基线存储在可访问的位置 | 您对负责这些基线配置的员工进行培训

受益于对组件基础配置设置的强化 通过了解保护所使用技术栈的重要性，根据现有的指导（例如开源项目、供应商文档、博客文章）对栈元素应用安全配置。当你的团队根据试验和团队成员收集的信息为他们的应用程序制定配置指导时，鼓励他们在整个组织中分享他们的经验。识别常见技术堆栈的关键元素，并根据团队的实践经验，为这些元素建立配置标准。在这个成熟度水平上，您尚未建立管理配置基线的正式流程。配置可能无法在各个应用程序和部署中一致应用，并且可能缺乏合规性监控。好处：在组织中对技术栈组件进行一致的强化。活动：为所使用的每个技术栈中的所有组件建立配置强化基线。为了协助一致地应用加固基线，请为各个组件制定配置指南。要求产品团队将配置基线应用于所有新系统，并在可行的情况下应用于现有系统。将加固基线和配置指南纳入变更管理，并为每项分配负责人。所有者有持续的责任根据不断发展的最佳实践或相关组件的变化（例如版本更新、新功能）保持其最新。在较大的环境中，应从本地维护的主配置导出实例的配置，并应用相关的配置基线。使用自动化工具强化配置。优势 清晰了解组件配置，以避免不符合项 活动 积极监控已部署技术堆栈的安全配置，定期检查是否符合既定基线。确保配置检查的结果可以轻松获取，通过已发布的报告和仪表板展示。当您检测到不符合规范的配置时，应将每次出现都视为安全问题，并在既定的缺陷管理实践中管理纠正措施。通过使用自动化手段，如“自我修复”配置和安全信息及事件管理（SIEM）警报，还可以实现进一步的收益。作为更新组件（例如（新版本、供应商补丁），审查相应的基线和配置指南，根据需要更新它们以保持其相关性和准确性。至少每年审查其他基线和配置指南。定期审查您的基线管理流程，结合应用和维护配置基线及配置指南的团队反馈和经验教训。标准：您定期进行符合性检查，最好使用自动化工具 | 您将符合性检查结果存储在可访问的位置 | 您遵循既定流程处理报告的不符合项 | 您至少每年审查一次每个基线，并在必要时进行更新

好处 能够检测最明显的安全事件 活动 分析可用的日志数据（例如访问日志、应用日志、基础设施日志），以根据已知的日志数据保留周期检测可能的安全事件。在小型环境中，可以借助常用命令行工具手动完成此操作。在日志量较大的情况下，应使用自动化技术。即使是一个 `cron` 任务，运行一个简单的脚本来查找可疑事件，也是一个进步！如果你将来自不同来源的日志发送到专用的日志聚合系统，在那里分析日志并使用基本的日志关联原则。即使你没有全天候的事件检测流程，也要确保在负责人员（例如…）不可用时有相应安排。由于休假或疾病）不会显著影响检测速度或质量。建立并共享正式创建安全事件的联系人信息。好处 及时且持续地检测预期的安全事件 活动 为事件检测流程指定专门负责人，使所有流程相关方都能访问明确的文档，并确保定期审查和必要时更新。确保负责事件检测的员工遵循此流程（例如，通过培训）。该过程通常依赖高度自动化，从不同来源收集并关联日志数据，包括应用程序日志。如果合适，可以将日志集中到一个地方进行汇总。定期验证分析数据的完整性。如果添加了新的应用程序，请确保该过程在合理时间内涵盖它。使用可用的检查表检测可能的安全事件。清单应涵盖预期的攻击向量以及已知或预期的杀伤链。应定期评估和更新清单。当你确定某一事件是安全事件（有足够高的信心）时，应立即通知相关人员，即使在非工作时间也要通知。根据情况进行进一步分析，并启动升级流程。好处 能够及时检测安全事件 活动 确保流程文档包含持续改进流程的措施。检查流程改进的连续性（例如，通过跟踪变更）。确保可疑事件检测的清单至少与以下来源和知识库相关联：(i) 公司外部的来源和知识库（例如新漏洞公告影响所使用的技术）、（ii）过去的安全事件，以及（iii）威胁模型结果。对所有合理的事件场景使用日志关联来进行事件检测。如果用于事件检测的日志数据不可用，应将其缺失记录为缺陷，并根据既定的缺陷管理流程进行分类和处理。事件检测的质量不依赖于事件发生的时间或日期。如果安全事件在指定时间内（例如 20 分钟）未被确认和解决，请确保根据既定的升级路径生成进一步的通知。标准：您有一个安全事件创建的联系人 | 您根据日志数据保留期限分析数据 | 此分析的频率与您应用程序的重要性相一致

优势 能够检测最明显的安全事件 活动 分析可用的日志数据（例如访问日志、应用日志、基础设施日志），以根据已知的日志数据保留期检测可能的安全事件。在小型环境中，你可以借助常用的命令行工具手动进行此操作。在较大的日志量情况下，使用自动化技术。即使是一个 `cron` 任务，运行一个简单的脚本来查找可疑事件，也是一个进步！如果你将来自不同来源的日志发送到专用的日志聚合系统，在那里分析日志并使用基本的日志关联原则。即使你没有全天候的事件检测流程，也要确保在负责人员不可用时（例如）。由于休假或疾病）不会显著影响检测速度或质量。建立并共享正式创建安全事件的联系人信息。好处 及时且持续地检测预期的安全事件 活动 为事件检测流程指定专门负责人，使所有流程相关方都能访问明确的文档，并确保定期审查和必要时更新。确保负责事件检测的员工遵循此流程（例如，通过培训）。该过程通常依赖高度自动化，从不同来源收集并关联日志数据，包括应用程序日志。如果合适，可以将日志集中到一个地方。定期验证分析数据的完整性。如果添加了新应用程序，请确保该过程在合理时间内涵盖它。使用可用检查表检测可能的安全事件。清单应涵盖预期的攻击向量以及已知或预期的杀伤链。应定期评估和更新清单。当你确定某个事件是安全事件（有足够高的信心）时，应立即通知相关人员，即使在非工作时间也要通知。根据情况进行进一步分析，并启动升级流程。好处 能够及时检测安全事件 活动 确保流程文档包含持续改进流程的措施。检查流程改进的连续性（例如，通过跟踪变更）。确保可疑事件检测的清单至少与公司外部的来源和知识库相关联（例如。（新公布的影响所使用技术的漏洞）、（过去的安全事件）以及（威胁模型的结果）。在所有合理的事件场景中，使用日志关联进行事件检测。如果用于事件检测的日志数据不可用，应将其缺失记录为缺陷，并根据已建立的缺陷管理流程进行分级处理和处理。事件检测的质量不取决于事件发生的时间或日期。如果安全事件在指定时间内（例如 20 分钟）未被确认和解决，请确保根据既定的升级路径生成进一步的通知。标准：该流程有专门负责人 | 您将流程文档存放在可访问的位置 | 流程考虑了进一步分析的升级路径 | 您培训负责事件检测的员工掌握此流程 | 您有潜在攻击清单以简化事件检测

好处 能够检测最明显的安全事件 活动 分析可用的日志数据（例如访问日志、应用日志、基础设施日志），以根据已知的日志数据保留周期检测可能的安全事件。在小型环境中，可以借助常用命令行工具手动完成此操作。在日志量较大的情况下，应使用自动化技术。即使是一个 `cron` 任务，运行一个简单的脚本来查找可疑事件，也是一个进步！如果你将来自不同来源的日志发送到专用的日志聚合系统，在那里分析日志并使用基本的日志关联原则。即使你没有全天候的事件检测流程，也要确保在负责人员（例如…）不可用时有相应安排。由于休假或疾病）不会显著影响检测速度或质量。建立并共享正式创建安全事件的联系人信息。好处 及时且持续地检测预期的安全事件 活动 为事件检测流程指定专门负责人，使所有流程相关方都能访问明确的文档，并确保定期审查和必要时更新。确保负责事件检测的员工遵循此流程（例如，通过培训）。该过程通常依赖高度自动化，从不同来源收集并关联日志数据，包括应用程序日志。如果合适，可以将日志集中到一个地方。定期验证分析数据的完整性。如果添加了新应用程序，请确保该过程在合理时间内涵盖它。使用可用检查表检测可能的安全事件。清单应涵盖预期的攻击向量以及已知或预期的杀伤链。应定期评估和更新清单。当你确定某一事件是安全事件（有足够高的信心）时，应立即通知负责的工作人员，即使在非工作时间也要通知。根据需要进行进一步分析，并启动升级处理流程。好处 能够及时检测安全事件 活动 确保流程文档包含持续改进流程的措施。检查流程改进的连续性（例如，通过跟踪变更）。确保可疑事件检测的清单至少与公司外部的来源和知识库相关联（例如。（新公布的影响所使用技术的漏洞）、（ii）过去的安全事件，以及（iii）威胁模型的结果。使用日志关联进行所有合理事件场景的事件检测。如果用于事件检测的日志数据不可用，应将其缺失记录为缺陷，并根据已建立的缺陷管理流程进行分级处理和处理。事件检测的质量不取决于事件发生的时间或日期。如果安全事件在指定时间内（例如 20 分钟）未被确认或解决，请确保根据既定的升级路径生成进一步的通知。标准：您至少每年进行一次审查 | 您会根据外部和内部数据更新潜在攻击的清单

了解处理数据敏感性的好处以及可快速实现的措施 活动 了解您的应用程序存储和处理的数据类型及其敏感性，并保持对处理后数据去向的关注（例如，备份、与外部合作伙伴共享）。在该成熟度水平上，收集的信息可能以各种形式和不同地点保存；假设不存在全组织范围的数据目录。根据适用于所存储和处理的最敏感数据的保护要求，保护和处理与特定应用程序相关的所有数据。实施基本控制，以防止未经清理的敏感数据从生产环境传播到低环境。通过确保未经清理的生产数据不会传播到较低的（非生产）环境，您可以将数据保护策略和活动集中于生产环境。好处是对不同类别的敏感数据进行标准化处理。活动 在这个成熟度水平上，数据保护活动专注于主动管理您对数据的管理职责。建立技术和管理控制措施，以保护敏感数据的机密性，以及您所管理的所有数据的完整性和可用性，从其最初的创建/接收直到保留期结束时备份的销毁。识别应用程序存储、处理和传输的数据，并在数据目录中记录有关其类型、敏感性（分类）级别和存储位置的信息。明确识别受特定法规约束的记录或数据元素。建立关于所处理数据的唯一真实来源，有助于对其保护措施进行更细粒度的选择。收集这些信息可以提高您对与数据相关的查询（例如来自审计员、事件响应团队或客户）的响应的准确性、时效性和效率，并支持威胁建模和合规活动。根据您的数据保护政策，建立在数据整个生命周期内保护和保存数据的流程和程序，无论是在静止状态、处理过程中还是传输中。特别注意在活跃处理系统之外处理和保护敏感数据，包括但不限于：备份的存储、保留和销毁；以及离线存储介质的标记、加密和物理保护。您的流程和程序涵盖了为遵守关于存储位置、人员访问和其他因素的法规、合同或其他限制而采取的所有控制措施的实施。好处 技术上强制执行您的数据保护政策 活动 在此成熟度水平的活动集中于自动化数据保护，减少您对人工评估和管理政策合规性的依赖。重视反馈机制和主动审查，以识别并采取措施改进流程。实施技术控制以确保遵守您的数据保护政策，并建立监控机制以检测尝试或实际的违规行为。您可以使用多种现有工具来进行数据丢失防护、访问控制和跟踪，或异常行为检测。定期审计已建立的管理控制的合规性，并密切监控自动化机制的性能和运行情况，包括备份和记录删除。监控工具可以快速检测和报告自动化中的故障，使您能够及时采取纠正措施。定期审查和更新数据目录，以保持其对数据环境的准确反映。定期审查和更新流程和程序，以确保其与您的政策和优先事项保持一致。标准：您了解每个应用程序处理和存储的数据元素 | 您了解每个已识别数据元素的类型和敏感级别 | 您拥有防止未净化敏感数据从生产环境传播到低级环境的控制措施

了解处理数据敏感性的好处以及可快速实现的措施。活动：了解您的应用程序存储和处理的数据类型及其敏感性，并保持对处理后数据去向的关注（例如，备份、与外部合作伙伴共享）。在该成熟度水平上，收集的信息可能以各种形式存在并存储在不同的地方；假设不存在全组织范围的数据目录。根据适用于存储和处理的最敏感数据的保护要求，保护和处理与特定应用程序相关的所有数据。实施基本控制，以防止未清理的敏感数据从生产环境传播到低级环境。通过确保未经清理的生产数据不会传播到较低（非生产）环境，您可以将数据保护策略和活动集中在生产环境上。好处是对不同类别的敏感数据进行标准化处理。活动 在这个成熟度水平上，数据保护活动专注于主动管理您对数据的管理职责。建立技术和管理控制措施，以保护敏感数据的机密性，以及您所管理的所有数据的完整性和可用性，从其最初的创建/接收直到保留期结束时备份的销毁。识别应用程序存储、处理和传输的数据，并在数据目录中记录其类型、敏感性（分类）级别及存储位置。清楚标明受特定法规约束的记录或数据元素。建立关于您所处理数据的唯一真实来源，有助于对其保护措施进行更细粒度的选择。收集这些信息可以提高您对与数据相关的查询（例如来自审计员、事件响应团队或客户）的响应的准确性、时效性和效率，并支持威胁建模和合规活动。根据您的数据保护政策，建立在数据整个生命周期内保护和保存数据的流程和程序，无论是在静止状态、处理过程中还是传输中。特别注意在活跃处理系统之外处理和保护敏感数据，包括但不限于：备份的存储、保留和销毁；以及离线存储介质的标记、加密和物理保护。您的流程和程序涵盖了为遵守关于存储位置、人员访问和其他因素的法规、合同或其他限制而采取的所有控制措施的实施。好处 技术上强制执行您的数据保护政策 活动 在此成熟度水平的活动集中于自动化数据保护，减少您对人工评估和管理政策合规性的依赖。重视反馈机制和主动审查，以识别并采取措施改进流程的机会。实施技术控制以确保遵守您的数据保护政策，并建立监控机制以检测尝试或实际的违规行为。您可以使用多种现有工具来进行数据丢失防护、访问控制和跟踪，或异常行为检测。定期审计对已建立的管理控制措施的遵循情况，并密切监控自动化机制的性能和运作，包括备份和记录删除。监控工具能快速检测并报告自动化中的故障，允许您及时采取纠正措施。定期审查和更新数据目录，以保持其对数据环境的准确反映。定期审查和更新流程和程序可以确保其与您的政策和优先事项保持一致。标准：数据目录存储在可访问的位置 | 您知道哪些数据元素受特定法规约束 | 您拥有在数据整个生命周期中保护和保存数据的控制措施 | 您对数据有保留要求，并在相关保留期结束后及时销毁备份

了解处理数据敏感性的好处以及可快速实现的措施。活动：了解您的应用程序存储和处理的数据类型及其敏感性，并保持对处理后数据去向的关注（例如，备份、与外部合作伙伴共享）。在该成熟度水平上，收集的信息可能以各种形式和不同地点保存；假设不存在全组织范围的数据目录。根据适用于所存储和处理的最敏感数据的保护要求，保护和处理与特定应用程序相关的所有数据。实施基本控制，以防止未经清理的敏感数据从生产环境传播到低级环境。通过确保未经清理的生产数据不会传播到较低（非生产）环境，您可以将数据保护策略和活动集中在生产环境上。好处是对不同类别的敏感数据进行标准化处理。活动 在这个成熟度水平上，数据保护活动专注于主动管理您对数据的管理职责。建立技术和管理控制措施，以保护敏感数据的机密性，以及您所管理的所有数据的完整性和可用性，从其最初的创建/接收直到保留期结束时备份的销毁。识别应用程序存储、处理和传输的数据，并在数据目录中记录其类型、敏感性（分类）级别和存储位置。清楚标明受特定法规约束的记录或数据元素。建立关于您所处理数据的唯一真实来源，有助于对其保护措施进行更细粒度的选择。收集这些信息可以提高您对与数据相关的查询（例如来自审计员、事件响应团队或客户）的响应的准确性、时效性和效率，并支持威胁建模和合规活动。根据您的数据保护政策，建立在数据整个生命周期内保护和保存数据的流程和程序，无论是在静止状态、处理过程中还是传输中。特别注意在活跃处理系统之外处理和保护敏感数据，包括但不限于：备份的存储、保留和销毁；以及离线存储介质的标记、加密和物理保护。您的流程和程序涵盖了为遵守关于存储位置、人员访问和其他因素的法规、合同或其他限制而采取的所有控制措施的实施。好处 技术上强制执行您的数据保护政策 活动 在此成熟度水平的活动集中于自动化数据保护，减少您对人工评估和管理政策合规性的依赖。重视反馈机制和主动审查，以识别并采取措施改进流程的机会。实施技术控制以确保遵守您的数据保护政策，并建立监控机制以检测尝试或实际的违规行为。您可以使用多种现有工具来进行数据丢失防护、访问控制和跟踪，或异常行为检测。定期审计对已建立的管理控制措施的遵循情况，并密切监控自动化机制的性能和运作，包括备份和记录删除。监控工具能快速检测并报告自动化中的故障，允许您及时采取纠正措施。定期审查和更新数据目录，以保持其对数据环境的准确反映。定期审查和更新流程和程序可以确保其与您的政策和优先事项保持一致。标准：您拥有自动监控以检测《数据保护政策》的尝试性或实际违规行为 | 您拥有数据丢失防护、访问控制和跟踪或异常行为检测工具 | 您定期审计自动化机制的运行情况，包括备份和记录删除

确保架构控制措施有效性的好处 活动 审查架构组件及其提供的安全机制的有效性，评估其是否与组织的整体战略保持一致，并仔细审查所选择的安全解决方案在可用性、可扩展性和企业适用性方面的程度。虽然针对特定应用的战术选择在特定情境下可能有其合理性，但重要的是要关注整体情况，确保所设计的解决方案具备未来的适应性。将任何发现反馈到缺陷管理中，以促进对架构的进一步改进。益处 理解高级架构和合理的安全措施 活动 创建整体架构视图，并检查其是否正确提供了一般安全机制，如身份验证、授权、用户和权限管理、安全通信、数据保护、密钥管理和日志管理。同时考虑对隐私的支持。根据项目产出物，如架构或设计文档，或与业务负责人和技术人员的访谈来执行此操作。还要考虑基础设施组件——这些是所有非特定于应用程序的系统、组件和库（包括 SDK），但它们为组织中应用程序的使用或管理提供直接支持。注意架构中的任何安全相关功能，并审查其是否正确提供。从匿名用户、授权用户和特定应用角色的角度以临时方式进行此操作。益处：在整个组织内实现一致的架构审查流程。活动：验证解决方案架构是否涵盖所有已识别的安全和合规性要求。对于应用程序中的每个接口，遍历安全性和合规性要求的列表，并分析架构是否满足这些要求。同时执行交互或数据流分析，以确保这些要求在不同组件中得到充分满足。详细展开分析，展示设计层面上针对每个要求的特性。对内部接口（例如各层之间）以及外部接口（例如组成攻击面的一些接口）都进行这种类型的分析。同时识别和验证架构中做出的重要设计决策，特别是当它们偏离组织中可用的共享安全解决方案时。最后，根据开发周期中所做的更改更新发现，并将设计阶段未明确提供的任何需求记录为评估发现。标准：您评估安全控制的预防、检测和响应能力 | 您评估安全控制的策略一致性、适当支持和可扩展性 | 您每年至少评估一次其有效性 | 您将发现的缺陷记录为缺陷

确保架构控制措施的有效性 活动：审查架构组件及其提供的安全机制在与组织整体战略的一致性方面的有效性，仔细检查所选安全解决方案的可用性、可扩展性及企业适用性水平。虽然针对特定应用的战术选择在特定情境下可能有其合理性，但重要的是要关注整体情况，确保所设计的解决方案具备未来的适应性。将任何发现反馈到缺陷管理中，以促进对架构的进一步改进。益处 理解高级架构和合理的安全措施 活动 创建整体架构视图，并检查其是否正确提供了一般安全机制，如身份验证、授权、用户和权限管理、安全通信、数据保护、密钥管理和日志管理。同时考虑对隐私的支持。根据项目产出物，如架构或设计文档，或与业务负责人和技术人员的访谈来执行此操作。还要考虑基础设施组件——这些是所有的系统、组件和库（包括 SDK），它们不是特定于应用程序的，但为组织中应用程序的使用或管理提供直接支持。注意架构中的任何安全相关功能，并审查其是否正确提供。从匿名用户、授权用户和特定应用角色的角度以临时方式进行此操作。益处：在整个组织内实现一致的架构审查流程。活动：验证解决方案架构是否涵盖所有已识别的安全和合规性要求。对于应用程序中的每个接口，遍历安全性和合规性要求的列表，并分析架构是否满足这些要求。同时执行交互或数据流分析，以确保这些要求在不同组件中得到充分满足。详细展开分析，展示设计层面上针对每个要求的特性。对内部接口（例如各层之间）以及外部接口（例如组成攻击面的一些接口）都进行这种类型的分析。同时识别和验证架构中做出的重要设计决策，特别是当它们偏离组织中可用的共享安全解决方案时。最后，根据开发周期中所做的更改更新发现，并将设计阶段未明确提供的任何需求记录为评估发现。标准：您已有一致认可的整体软件架构模型 | 在架构模型中包含组件、接口和集成 | 验证通用安全机制的正确提供 | 将缺失的安全控制记录为缺陷

确保架构控制措施的有效性 活动：审查架构组件及其提供的安全机制的有效性，以确定其与组织整体战略的契合度，并仔细检查所选安全解决方案的可用性、可扩展性和企业适用性程度。虽然针对特定应用的战术选择在特定情境下可能有其合理性，但重要的是要关注整体情况，确保所设计的解决方案具备未来的适应性。将任何发现反馈到缺陷管理中，以促进对架构的进一步改进。益处 理解高级架构和合理的安全措施 活动 创建整体架构视图，并检查其是否正确提供了一般安全机制，如身份验证、授权、用户和权限管理、安全通信、数据保护、密钥管理和日志管理。同时考虑对隐私的支持。根据项目产出物，如架构或设计文档，或与业务负责人和技术人员的访谈来执行此操作。还要考虑基础设施组件——这些是所有非特定于应用程序的系统、组件和库（包括 SDK），但它们为组织中应用程序的使用或管理提供直接支持。注意架构中的任何安全相关功能，并审查其是否正确提供。从匿名用户、授权用户和特定应用角色的角度以临时方式进行此操作。好处：在整个组织内实现一致的架构审查流程。活动：验证解决方案架构是否涵盖所有已识别的安全和合规性要求。对于应用程序中的每个接口，遍历安全性和合规性要求的列表，并分析架构是否满足这些要求。同时执行交互或数据流分析，以确保这些要求在不同组件中得到充分满足。详细展开分析，展示设计层面上针对每个要求的特性。对内部接口（例如各层之间）以及外部接口（例如组成攻击面的一些接口）都进行这种类型的分析。同时识别和验证架构中做出的重要设计决策，特别是当它们偏离组织中可用的共享安全解决方案时。最后，根据开发周期中所做的更改更新发现，并记录在设计阶段未明确提供的任何需求作为评估结果。标准：您审查内部和外部要求的合规性 | 您系统地审查系统中的每个接口 | 您使用规范化的审查方法和结构化验证 | 您将缺失的安全机制记录为缺陷

益处 验证标准安全控制的有效性 活动 进行安全测试，以验证标准软件安全控制是否按预期运行。总体而言，这意味着测试数据以及服务的机密性、完整性和可用性控制的正确功能。安全测试至少包括对身份验证、访问控制、输入验证、数据编码与转义以及加密控制的测试。测试目标是验证安全控制是否正确实施。安全测试验证相关的软件安全控制。每次应用程序更改其对控制的使用时，都应手动或使用工具执行控制验证安全测试。可以使用功能开关和A/B测试等技术，在功能经过充分验证后，逐步向更广泛的用户群体开放。对所有属于SAMM计划的软件，软件控制验证是强制性的。将安全需求整合到测试场景中的益处 活动 根据安全需求，识别并实施一组安全测试用例，以检查软件的正确功能。要有一个成功的测试计划，您必须了解由安全需求指定的测试目标。根据作为“安全需求”SAMM安全实践一部分创建的安全需求，为范围内的应用程序推导安全测试用例。为了通过安全测试验证安全需求，安全需求是以功能为导向的，并突出了预期的功能（即‘是什么’）以及隐含的实现方式（即‘如何实现’）。这些需求也被称为“正向需求”，因为它们说明了可以通过安全测试进行验证的预期功能。正向需求的示例包括“应用程序在六次登录失败后会锁定用户”或“密码至少需要六个字母数字字符”。对正向需求的验证包括确认预期功能。你可以通过重现测试条件并根据预定义输入运行测试来进行验证。将结果显示为失败或通过状态。通常，最有效的方法是利用项目团队的时间来构建特定于应用程序的测试用例，并使用公开的资源或购买的知识库来选择适用于安全性的通用测试用例。相关的开发、安全和质量保证人员会评审候选测试用例的适用性、有效性和可行性。在功能的需求和/或设计阶段推导测试用例。测试安全需求是软件功能测试的一部分。好处 及时且可靠地检测安全要求的违规行为 活动 为所有已识别（并修复）的漏洞编写和自动化回归测试，以确保它们成为测试工具，防止在后续发布中引入类似问题。安全单元测试应动态验证（即在运行时) 确保组件按预期工作，并应验证代码更改是否正确实施。开发人员的一个好做法是将安全测试用例构建为通用安全测试套件，并将其作为现有单元测试框架的一部分。通用的安全测试套件可能包括安全测试用例，以验证安全控制的正面和负面需求，例如身份、认证和访问控制、输入验证和编码、用户和会话管理、错误和异常处理、加密以及审计和日志记录。尽早验证安全测试的正确执行。如果可行，例如，可以将通过安全测试作为合并要求的一部分，在允许新代码进入主代码库之前进行考虑。或者，可以将其通过作为验证构建的一个要求。对于安全功能测试，应在软件组件级别使用单元测试来测试安全控制的功能，例如函数、方法或类。例如，一个测试用例可以通过断言组件的预期功能来检查输入和输出的验证（例如，变量清理）以及变量的边界检查。标准：安全测试至少应验证身份验证、访问控制、输入验证、数据编码与转义以及加密控制的实现情况 | 每当应用程序更改其控制使用方式时，都应执行安全测试

益处 验证标准安全控制的有效性 活动 进行安全测试，以验证标准软件安全控制是否按预期运行。总体而言，这意味着测试数据以及服务的机密性、完整性和可用性控制的正确功能。安全测试至少包括对身份验证、访问控制、输入验证、数据编码与转义以及加密控制的测试。测试目标是验证安全控制是否正确实施。安全测试验证相关的软件安全控制。每次应用程序更改其对控制的使用时，都应手动或使用工具执行控制验证安全测试。可以使用功能开关和A/B测试等技术，在功能经过充分验证后，逐步向更广泛的用户群体开放。对所有属于SAMM计划的软件，软件控制验证是强制性的。将安全需求整合到测试场景中的益处 活动 根据安全需求，识别并实施一组安全测试用例，以检查软件的正确功能。要有一个成功的测试计划，您必须了解由安全需求指定的测试目标。根据作为“安全需求”SAMM安全实践一部分创建的安全需求，为范围内的应用程序推导安全测试用例。为了通过安全测试验证安全需求，安全需求是以功能为导向的，并突出了预期的功能（即‘是什么’）以及隐含的实现方式（即‘如何实现’）。这些需求也被称为“正向需求”，因为它们说明了可以通过安全测试进行验证的预期功能。正向需求的示例包括“应用程序在六次登录失败后会锁定用户”或“密码至少需要六个字母数字字符”。对正向需求的验证包括确认预期功能。你可以通过重现测试条件并根据预定义输入运行测试来进行验证。将结果显示为失败或通过状态。通常，最有效的方法是利用项目团队的时间来构建特定于应用程序的测试用例，并使用公开的资源或购买的知识库来选择适用于安全性的通用测试用例。相关的开发、安全和质量保证人员会评审候选测试用例的适用性、有效性和可行性。在功能的需求和/或设计阶段推导测试用例。测试安全需求是软件功能测试的一部分。好处 及时且可靠地检测安全要求的违规行为 活动 为所有已识别（并修复）的漏洞编写和自动化回归测试，以确保它们成为测试工具，防止在后续发布中引入类似问题。安全单元测试应动态验证（即在运行时) 确保组件按预期工作，并应验证代码更改是否正确实施。开发人员的一个好做法是将安全测试用例构建为通用安全测试套件，并将其作为现有单元测试框架的一部分。通用的安全测试套件可能包括安全测试用例，以验证安全控制的正面和负面需求，例如身份、认证和访问控制、输入验证和编码、用户和会话管理、错误和异常处理、加密以及审计和日志记录。尽早验证安全测试的正确执行。如果可行，例如，可以将通过安全测试作为合并要求的一部分，在允许新代码进入主代码库之前进行考虑。或者，可以将其通过作为验证构建的一个要求。对于安全功能测试，应在软件组件级别使用单元测试来测试安全控制的功能，例如函数、方法或类。例如，一个测试用例可以通过断言组件的预期功能来检查输入和输出的验证（例如，变量的清理）以及变量的边界检查。标准：您根据每个应用程序定制测试并断言预期的安全功能 | 您将测试结果记录为通过或失败 | 测试使用标准化的框架或领域特定语言（DSL）

益处 验证标准安全控制的有效性 活动 进行安全测试，以验证标准软件安全控制是否按预期运行。总体而言，这意味着测试数据以及服务的机密性、完整性和可用性控制的正确功能。安全测试至少包括对身份验证、访问控制、输入验证、数据编码与转义以及加密控制的测试。测试目标是验证安全控制是否正确实施。安全测试验证相关的软件安全控制。每次应用程序更改其对控制的使用时，都应手动或使用工具执行控制验证安全测试。可以使用功能开关和A/B测试等技术，在功能经过充分验证后，逐步向更广泛的用户群体开放。对所有属于SAMM计划的软件，软件控制验证是强制性的。将安全需求整合到测试场景中的益处 活动 根据安全需求，识别并实施一组安全测试用例，以检查软件的正确功能。要有一个成功的测试计划，您必须了解由安全需求指定的测试目标。根据作为“安全需求”SAMM安全实践一部分创建的安全需求，为范围内的应用程序推导安全测试用例。为了通过安全测试验证安全需求，安全需求是以功能为导向的，并突出了预期的功能（即‘是什么’）以及隐含的实现方式（即‘如何实现’）。这些需求也被称为“正向需求”，因为它们说明了可以通过安全测试进行验证的预期功能。正向需求的示例包括“应用在连续六次登录失败后会锁定用户”或“密码至少需要六个字母数字字符”。对正向需求的验证包括确认预期功能。你可以通过重现测试条件并根据预定义的输入执行测试来进行。将结果显示为失败或通过状态。通常，最有效的方法是利用项目团队的时间来构建特定于应用程序的测试用例，并使用公开的资源或购买的知识库来选择适用的一般安全测试用例。相关的开发、安全和质量保证人员会评审候选测试用例的适用性、有效性和可行性。在功能的需求和/或设计阶段推导测试用例。测试安全需求是软件功能测试的一部分。好处 及时且可靠地检测安全要求的违规行为 活动 为所有已识别（并修复）的漏洞编写和自动化回归测试，以确保它们成为测试工具，防止在后续发布中引入类似问题。安全单元测试应动态验证（即在运行时) 确保组件按预期工作，并应验证代码更改是否正确实施。开发人员的一个好做法是将安全测试用例构建为通用安全测试套件，并将其作为现有单元测试框架的一部分。通用的安全测试套件可能包括安全测试用例，以验证安全控制的正面和负面需求，例如身份、认证和访问控制、输入验证和编码、用户和会话管理、错误和异常处理、加密以及审计和日志记录。尽早验证安全测试的正确执行。如果可行，例如，可以将通过安全测试作为合并要求的一部分，在允许新代码进入主代码库之前进行考虑。或者，可以将其通过作为验证构建的一个要求。对于安全功能测试，应在软件组件级别使用单元测试来测试安全控制的功能，例如函数、方法或类。例如，一个测试用例可以通过断言组件的预期功能来检查输入和输出验证（例如，变量清理）以及变量的边界检查。标准：你始终为所有已识别的错误编写测试（可能超过预定义的严重性阈值）| 你将安全测试收集到现有单元测试框架的一部分测试套件中

常见易发现漏洞的效益检测 活动 使用自动化的静态和动态安全测试工具对软件进行测试，从而提高安全测试的效率并获得更高质量的结果。逐步增加安全测试的频率并扩展代码覆盖率。应用程序安全测试可以通过静态方式执行，即在不运行应用程序的情况下检查其源代码，或通过动态方式执行，即仅观察应用程序对各种输入条件的响应行为。前者通常称为静态应用程序安全测试（SAST），后者则称为动态应用程序安全测试（DAST）。一种称为交互式应用安全测试（IAST）的混合方法，通过动态测试自动加装的应用程序，结合了两种方法的优势（代价是额外的开销），从而可以准确监控应用程序对外部输入的内部状态响应。很多安全漏洞如果不仔细检查源代码，是很难被发现的。虽然理想情况下应由专家或同行评审来执行，但这是一个缓慢且昂贵的任务。尽管自动化SAST工具“噪声更大”，且通常不如专家主导的评审准确，但它们比人工更便宜、快得多且更一致。许多商业和免费工具能够在大型代码库中高效地检测出足够重要的漏洞和缺陷。动态测试不需要应用程序源代码，因此非常适合源代码不可用的情况。它还可以识别具体的漏洞实例。由于其“黑盒”方法，没有进行代码插装，它更有可能发现表面上的缺陷。动态测试工具需要大量的测试数据，而手动生成这些数据是不可行的。存在许多工具可以自动生成合适的测试数据，从而提高安全测试的效率并获得更高质量的结果。根据多个因素选择合适的工具，包括检查的深度和准确性、安全测试用例的稳健性和准确性、与其他工具的可用集成、使用和成本模式等。在选择工具时，应参考具有安全意识的技术人员以及开发人员和开发经理的意见，并与利益相关者一起审查结果。好处：能够检测组织特有的、易于发现的漏洞。活动：通过针对特定技术栈和应用程序调整和定制自动化安全测试工具，提高其有效性。自动化安全测试工具有两个重要特征：它们的误报率，即错误报告的不存在的漏洞和缺陷；它们的漏报率，即未能检测到的实际漏洞和缺陷。随着你在使用自动化测试工具方面的成熟，你会努力将它们的误报率和漏报率降到最低。这可以最大化开发团队用于审核和解决应用程序中实际安全问题的时间，并减少通常与使用未经调优的自动化安全分析工具相关的摩擦。首先，禁用对您不使用的技术和框架的工具支持，并在可能的情况下针对特定版本。这将提高执行速度并减少报告的虚假结果数量。依靠安全工具的使用专家或共享安全团队，与一组积极的开发团队协调试用这些工具。这将帮助识别可能的误报，从而在工具输出中忽略或移除它们。识别特定的安全问题和反模式，并选择最适合检测它们的工具。利用现有工具功能，考虑应用程序特定和组织的编码风格以及技术标准。许多自动化静态分析工具允许用户编写自己的规则或将默认分析规则自定义为适应测试项目中的具体软件接口，以提高准确性和覆盖深度。例如，潜在危险的输入（也称为受污染输入）在经过指定的自定义清理方法处理后，可以被标记为安全。从策略上讲，通过自动化工具可靠地检测有限的安全问题子集，并逐步扩展覆盖范围，比试图立即检测所有已知问题更为明智。一旦工具经过充分调整，就可以向更多的开发团队提供使用。持续监测开发团队对其有效性的认知非常重要。在更高级的形式中，可以采用机器学习技术来识别并自动批量过滤可能的误报。在尽早阶段自动识别漏洞的收益识别 组织内的活动项目通常在开发过程中运行自动安全测试并审查结果。配置安全测试工具，使其作为构建和部署过程的一部分自动运行，以实现低开销的可扩展性。发生问题时立即进行检查。在需求或设计阶段尽早进行安全测试是有益的。虽然这种方法传统上用于功能测试用例，但这种测试驱动开发的方法涉及在开发周期早期识别并运行相关的安全测试用例。通过自动执行安全测试用例，项目在实现阶段开始时会有一些测试失败，因为对应的功能尚不存在。当所有测试通过时，实施即完成。这为开发人员在开发周期早期提供了明确的目标，降低了因安全问题导致发布延迟或为了满足项目截止日期而被迫接受风险的可能性。通过仪表板显示自动化和手动安全测试的结果，并定期向管理层和业务相关方（例如每次发布前）进行汇报。如果有未处理的发现仍被作为发布的可接受风险，相关方和开发管理人员将共同制定解决这些问题的具体时间表。持续审查和提升安全测试的质量。考虑并实施安全测试关联工具，将动态、静态和交互式应用扫描器的测试结果自动匹配并合并到一个中央仪表板中，为缺陷管理提供直接输入。在开发团队中传播已创建的安全测试及其结果的知识，以提高组织内部的安全知识和意识。标准：您使用自动化工具动态生成安全测试输入 | 您选择符合组织架构和技术栈的安全测试工具，并在检查深度和准确性与组织可用性发现之间取得平衡

常见易发现漏洞的效益检测 活动 使用自动化的静态和动态安全测试工具对软件进行测试，从而提高安全测试的效率并获得更高质量的结果。逐步增加安全测试的频率并扩展代码覆盖率。应用程序安全测试可以通过静态方式执行，即在不运行应用程序的情况下检查其源代码，或通过动态方式执行，即仅观察应用程序对各种输入条件的响应行为。前者通常称为静态应用程序安全测试（SAST），后者则称为动态应用程序安全测试（DAST）。一种称为交互式应用安全测试（IAST）的混合方法，通过动态测试自动加装的应用程序，结合了两种方法的优势（代价是额外的开销），从而可以准确监控应用程序对外部输入的内部状态响应。很多安全漏洞如果不仔细检查源代码，是很难被发现的。虽然理想情况下应由专家或同行评审来执行，但这是一个缓慢且昂贵的任务。尽管自动化SAST工具通常比专家主导的评审“噪声更大”，且准确性较低，但它们比人工更便宜、速度更快且更一致。许多商业和免费工具能够在大型代码库中高效地检测出足够重要的漏洞和缺陷。动态测试不需要应用程序源代码，因此非常适合源代码不可用的情况。它还可以识别具体的漏洞实例。由于其“黑箱”方法，没有进行仪器化，它更有可能发现表面错误。动态测试工具需要大量的测试数据，而手动生成这些测试数据几乎是不可能的。存在许多工具可以自动生成合适的测试数据，从而提高安全测试的效率并获得更高质量的结果。根据多个因素选择合适的工具，包括检查的深度和准确性、安全测试用例的稳健性和准确性、与其他工具的可用集成、使用和成本模式等。在选择工具时，应参考具有安全意识的技术人员以及开发人员和开发经理的意见，并与利益相关者一起审查结果。好处 检测组织特有的易于发现的漏洞 活动 通过针对特定的技术栈和应用程序调整和定制自动化安全测试工具，提高其有效性。自动化安全测试工具有两个重要特征：它们的误报率，即错误报告的不存在的漏洞和缺陷；它们的漏报率，即未能检测到的实际漏洞和缺陷。随着你在使用自动化测试工具方面的成熟，你会努力将它们的误报率和漏报率降到最低。这可以最大化开发团队用于审核和解决应用程序中实际安全问题的时间，并减少通常与使用未经调优的自动化安全分析工具相关的摩擦。首先，禁用对您不使用的技术和框架的工具支持，并在可能的情况下针对特定版本。这将提高执行速度并减少报告的虚假结果数量。依靠安全工具的使用专家或共享安全团队，与一组积极的开发团队协调试用这些工具。这将帮助识别可能的误报，从而在工具输出中忽略或移除它们。识别特定的安全问题和反模式，并选择最适合检测它们的工具。利用现有工具功能，考虑应用程序特定和组织的编码风格以及技术标准。许多自动化静态分析工具允许用户编写自己的规则或将默认分析规则自定义为适应测试项目中的具体软件接口，以提高准确性和覆盖深度。例如，潜在危险的输入（也称为受污染输入）在经过指定的自定义清理方法处理后，可以被标记为安全。从策略上讲，通过自动化工具可靠地检测有限的安全问题子集，并逐步扩展覆盖范围，比试图立即检测所有已知问题更为明智。一旦工具经过充分调整，就可以向更多的开发团队提供使用。持续监测开发团队对其有效性的认知非常重要。在更高级的形式中，可以采用机器学习技术来识别并自动批量过滤可能的误报。在尽早阶段自动识别漏洞的收益识别 组织内的活动项目通常在开发过程中运行自动安全测试并审查结果。配置安全测试工具，使其作为构建和部署过程的一部分自动运行，以便在低开销的情况下实现可扩展性。及时检查出现的发现。在需求或设计阶段尽早进行安全测试是有益的。虽然这种方法传统上用于功能测试用例，但这种测试驱动开发的方法涉及在开发周期早期识别并运行相关的安全测试用例。通过自动执行安全测试用例，项目在实现阶段开始时会有一些测试失败，因为对应的功能尚不存在。当所有测试通过时，实施即完成。这为开发人员在开发周期早期提供了明确的前期目标，从而降低了由于安全问题引起的发布延迟风险，或为满足项目截止日期而被迫接受风险的情况。通过仪表板显示自动化和手动安全测试的结果，并定期向管理层和业务相关方（例如每次发布前）进行汇报。如果存在未处理的、仍被接受为发布风险的发现，相关方和开发管理人员将共同制定解决这些问题的具体时间表。持续审查和提升安全测试的质量。考虑并实施安全测试关联工具，将动态、静态和交互式应用扫描器的测试结果自动匹配并合并到一个中央仪表板中，为缺陷管理提供直接输入。在开发团队中传播已创建的安全测试及其结果的知识，以提高组织内部的安全知识和意识。标准：您调整并选择与您的应用程序或技术栈匹配的工具功能 | 通过屏蔽或自动过滤无关的警告或低概率的发现，您可以将误报降到最低 | 通过利用工具扩展或领域特定语言（DSL）为您的应用程序或组织标准定制工具，您可以将漏报降到最低

常见易发现漏洞的益处检测 活动 使用自动化的静态和动态安全测试工具对软件进行测试，从而提高安全测试的效率并获得更高质量的结果。逐步增加安全测试的频率并扩展代码覆盖率。应用程序安全测试可以通过静态方式执行，即在不运行应用程序的情况下检查其源代码，或通过动态方式执行，即仅通过观察应用程序对各种输入条件的行为来进行。前一种方法通常被称为静态应用程序安全测试（SAST），后一种方法则称为动态应用程序安全测试（DAST）。一种称为交互式应用安全测试（IAST）的混合方法，通过动态测试自动加装的应用程序，结合了两种方法的优势（代价是额外的开销），从而可以准确监控应用程序对外部输入的内部状态响应。很多安全漏洞如果不仔细检查源代码，是很难被发现的。虽然理想情况下应由专家或同行评审来执行，但这是一个缓慢且昂贵的任务。尽管自动化 SAST 工具相比专家主导的评审“噪声更大”，且准确性通常较低，但它们比人工更便宜、速度更快且更加一致。许多商业和免费的工具能够高效地在大型代码库中检测出足够重要的漏洞和缺陷。动态测试不需要应用程序源代码，因此非常适合源代码不可用的情况。它还可以识别具体的漏洞实例。由于其“黑盒”方法，没有进行仪器化，更有可能发现表层错误。动态测试工具需要大量的测试数据，其手动生成是不可行的。存在许多工具可以自动生成合适的测试数据，从而提高安全测试的效率并获得更高质量的结果。根据多个因素选择合适的工具，包括检查的深度和准确性、安全测试用例的稳健性和准确性、与其他工具的可用集成、使用和成本模式等。在选择工具时，应参考具有安全意识的技术人员以及开发人员和开发经理的意见，并与利益相关者一起审查结果。好处：能够检测组织特有的易于发现的漏洞。活动：通过针对特定的技术栈和应用程序调整和定制自动化安全测试工具，提高其有效性。自动化安全测试工具有两个重要特征：它们的误报率，即错误报告的不存在的漏洞和缺陷；它们的漏报率，即未能检测到的实际漏洞和缺陷。随着你在使用自动化测试工具方面的成熟度提高，你会努力将它们的误报率和漏报率降到最低。这可以最大化开发团队用于审核和解决应用程序中实际安全问题的时间，并减少通常与使用未经调优的自动化安全分析工具相关的摩擦。首先，禁用对您不使用的技术和框架的工具支持，并在可能的情况下针对特定版本。这将提高执行速度并减少报告的虚假结果数量。依靠安全工具的使用专家或共享安全团队，与一组积极的开发团队协调试用这些工具。这将帮助识别可能的误报，从而在工具输出中忽略或移除它们。识别特定的安全问题和反模式，并选择最适合检测它们的工具。利用现有工具功能，考虑应用程序特定和组织的编码风格以及技术标准。许多自动化静态分析工具允许用户编写自己的规则或将默认分析规则自定义为适应测试项目中的具体软件接口，以提高准确性和覆盖深度。例如，潜在危险的输入（也称为受污染输入）在经过指定的自定义清理方法处理后，可以被标记为安全。从策略上讲，通过自动化工具可靠地检测有限的安全问题子集，并逐步扩展覆盖范围，比试图立即检测所有已知问题更为明智。一旦工具经过充分调整，就可以向更多的开发团队提供使用。持续监测开发团队对其有效性的认知非常重要。在更高级的形式中，可以采用机器学习技术来识别并自动批量过滤可能的误报。在尽早阶段自动识别漏洞的收益识别 组织内的活动项目通常在开发过程中运行自动安全测试并审查结果。配置安全测试工具，使其作为构建和部署过程的一部分自动运行，以便在低开销的情况下实现可扩展性。实时检查发现的问题。在需求或设计阶段尽早进行安全测试是有益的。虽然这种方法传统上用于功能测试用例，但这种测试驱动开发的方法涉及在开发周期早期识别并运行相关的安全测试用例。通过自动执行安全测试用例，项目在实现阶段开始时会有一些测试失败，因为对应的功能尚不存在。当所有测试通过时，实施即完成。这为开发人员在开发周期早期提供了明确的前期目标，从而降低了因安全问题导致发布延迟或为了满足项目截止日期而被迫接受风险的可能性。通过仪表板显示自动化和手动安全测试的结果，并定期向管理层和业务相关方（例如每次发布前）进行汇报。如果有未处理的发现仍被作为发布的可接受风险，相关方和开发管理人员将共同制定解决这些问题的具体时间表。持续审查和提升安全测试的质量。考虑并实施安全测试关联工具，将动态、静态和交互式应用扫描器的测试结果自动匹配并合并到一个中央仪表板中，为缺陷管理提供直接输入。在开发团队中传播已创建的安全测试及其结果的知识，以提高组织内部的安全知识和意识。标准：管理层和业务相关方在整个开发周期中跟踪和审查测试结果 | 你将测试结果合并到中央仪表板，并将其输入缺陷管理系统