OWASP 软件保证成熟度模型 2.0

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

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

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

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

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

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

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

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

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