OWASP 软件保证成熟度模型 2.0

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

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

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