成熟度模型中的建筑安全 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 流程中发挥更积极的指导作用。