OWASP 软件保证成熟度模型 2.0

收益 对所有相关员工进行基本的安全意识教育 活动 为所有目前参与软件管理、开发、测试或审计的角色开展安全意识培训。目标是提高对应用程序安全威胁和风险的认识，了解安全最佳实践以及安全软件设计原则。培训可内部开发或外部采购。理想情况下，应当亲自进行培训，这样参与者可以作为团队进行讨论，但基于计算机的培训（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 和应用安全指标触发大部分应用安全策略的调整