CISO助手
完成度
0%(0/48)
评估报告
OWAS

OWASP 软件保证成熟度模型 2.0

成熟度模式

SAMM 是一个规范性模型,是一个开放的框架,易于理解、定义明确且可衡量。它帮助组织制定和实施软件安全策略。

版本: 2.0覆盖状态: 完整覆盖 (96/96)控制项/量表/总计: 48/48/96当前展示: 3 / 485 个分类

政策与合规

3
G-PC-A-1您是否在整个组织中拥有并应用一套通用的政策和标准?成熟度实践
Governance / 政策与合规

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

评估
评估状态:
评估备注:
G-PC-A-2您是否将组织的政策作为测试脚本或操作手册发布,以便开发团队容易理解?成熟度实践
Governance / 政策与合规

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

评估
评估状态:
评估备注:
G-PC-A-3您是否定期报告政策和标准的合规情况,并利用这些信息来指导合规改进工作?成熟度实践
Governance / 政策与合规

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

评估
评估状态:
评估备注: