OWASP 软件保证成熟度模型 2.0

已知影响特定应用程序的安全缺陷的收益透明度 活动 引入安全缺陷的通用定义/理解，并定义识别这些缺陷的最常见方法。这些通常包括但不限于：威胁评估、渗透测试、静态和动态分析扫描工具的输出、负责任的披露流程或漏洞赏金。培养透明文化，避免指责任何团队引入或发现安全缺陷。将所有安全缺陷记录并跟踪在指定位置。这个位置不一定必须对整个组织来说是集中式的，但要确保您能够在任何时间点概览影响特定应用程序的所有缺陷。定义并应用跟踪的安全缺陷的访问规则，以降低信息泄露和滥用的风险。至少引入安全缺陷的初步定性分类，以便能够相应地优先处理修复工作。努力减少信息重复和误报的存在，以提高流程的可信度。好处 对安全缺陷进行一致的分类，并明确其处理预期。 活动 在整个组织中一致地引入并应用明确定义的安全缺陷评级方法，基于缺陷被利用的概率和预期影响。这将帮助您识别需要更多关注和投资的应用程序。如果你没有集中存储有关安全缺陷的信息，请确保仍然能够轻松地从所有来源获取信息，并对需要关注的“热点”进行概览。根据安全缺陷的严重性等级引入按时修复的服务水平协议(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）和漏洞扫描工具。同时，在适当的情况下，验证已部署工件的完整性。将这些测试的结果集中记录，并采取必要的措施。确保在检测到任何缺陷时，相关人员能够自动收到通知。如果发现任何超过预定义关键程度的问题，应自动停止或回滚部署，或引入单独的人工审批流程，以便记录此决策，并包含例外的解释。对所有阶段的所有部署进行记录和审计。建立一个系统来记录每次部署，包括执行部署的人、部署的软件版本以及与部署相关的任何相关变量。确保部署到生产环境的工件完整性 采取措施 利用在构建时签名的二进制文件，并通过将其签名与受信任的证书进行核对，自动验证正在部署的软件的完整性。这可能包括内部开发和构建的二进制文件，以及第三方工件。如果无法验证工件的签名，包括签名无效或证书过期的工件，请不要部署。如果受信任的证书列表中包含第三方开发者，请定期检查，并使其符合组织对受信第三方供应商的整体治理要求。在自动化部署过程中，至少手动批准一次部署。每当在部署过程中人工检查的准确性明显高于自动化检查时，选择人工检查。标准：如果检测到完整性漏洞，你会阻止或回滚部署 | 验证是针对构建时生成的签名进行的 | 如果无法检查签名（例如外部构建的软件），你需引入补偿措施