OWASP 软件保证成熟度模型 2.0

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