成熟度模型中的建筑安全 15 15

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。