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

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。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 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。