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

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。

为工程团队提供有关预先批准的安全功能的主动指导，让他们使用这些功能，而不是每个团队都自行实现安全功能。使用预先批准的实现方案对工程团队有益，同时SSG也受益，因为这样就不必反复追踪那些常常出现在安全功能中的细微错误（例如）。身份验证、角色管理、密钥管理、日志记录、加密、协议）。这些安全功能可能在SSDL活动中被发现，由SSG或专业开发团队创建，或在配置模板（例如云蓝图）中定义，并通过SDK、容器、微服务和API等机制提供。通用安全功能通常必须为特定平台进行定制。例如，每个移动和云平台可能都需要其自己的用户身份验证和授权方式、秘密管理方式，以及用户操作的集中记录和监控方式。关键在于实施和推广这些已定义的安全功能，这才是真正取得进展的方式，而不仅仅是列出这些功能。应用架构团队以对性能、可用性、可扩展性和弹性负责的方式对安全负责。防止安全问题在这些架构讨论中被忽视的一种方法是让安全设计专家（来自SSG、供应商等）参与其中。越来越多的架构讨论中包括开发人员和负责管理各种软件组件（如开源软件、API、容器和云服务）的站点可靠性工程师。在其他情况下，企业架构团队具备帮助专家创建安全设计的知识，使其能够正确地集成到企业设计标准中。与专家的主动参与是取得成功的关键。此外，一个团队永远不能假设另一个团队已经处理了安全需求——即使将一个知名系统迁移到云端，也意味着需要重新让专家参与。为工程团队使用构建或提供经批准的安全设计软件组件和服务。在批准和发布安全设计的软件组件和服务（包括开源和云服务）之前，SSG 必须对其进行仔细的安全评估。声明组件为安全设计的评估过程通常比普通项目的评估过程更严格、更深入。除了以身作则的教学之外，这些灵活且可重复使用的构建模块还有助于架构分析和代码审查等重要工作，因为它们使避免错误变得更加容易。这些组件和服务通常还具有一些功能（例如，应用程序身份、基于角色的访问控制），能够在不同的环境中实现统一使用。同样，SSG 还可以通过针对其提供的组件专门制定静态分析规则，从而进一步利用这个已定义的列表（参见 [CR2.6]）。通过解决组织安全组件或服务，或云服务提供商未解决的设计问题，为构建弹性架构做出贡献，从而最大限度地减少安全对其他约束（如功能开发速度）的负面影响。在应用重构或新协议、微服务或架构特性设计（例如）中，邀请SSG和安全设计专家参与。容器化) 可以及时分析现有防御的安全影响，并识别需要改进的元素。在新项目流程早期进行安全设计，比在现有设计中进行安全分析并在发现漏洞后进行重构更高效 (见 [AA1.1], [AA1.2], [AA2.1])。SSG 也可能参与到过去纯粹是工程讨论的内容中，即使是最基础的云原生技术使用（例如，“Hello, world!”）也需要正确使用配置和其他功能，而这些功能对安全态势有直接影响。一个审查委员会将规范在设计需求中对安全权衡达成和保持共识的过程。与通常关注功能的架构委员会不同，这个小组专注于提供安全指导，最好以模式、标准、功能或框架的形式呈现。它还会定期审查已发布的设计指导（尤其是关于身份验证、授权和加密的部分），以确保设计决策不会过时或失效。该审查委员会有助于控制与新技术采用相关的混乱情况，因为开发团队可能会在未与SSG或负责人沟通的情况下自行做出决策。审查委员会的安全指导还可以用来向外包软件提供商传达安全期望（参见[CP3.2]）。实施者必须从批准的列表或存储库中选择其安全功能和框架（参见[SFD1.1]、[SFD2.1]、[SFD3.1]）。这种做法有两个好处——开发人员无需花时间重新发明已有的功能，审查团队也无需在新项目或采用新平台时反复发现同样的旧缺陷。重用经过验证的组件可以简化测试、代码审查和威胁建模（参见 [AA1.1]）。重用是统一软件架构的一个主要优势，对于敏捷开发以及在 CI/CD 管道中维持开发速度尤其有帮助。通过打包和应用所需组件，例如通过容器化（参见 [SE2.5]），可以特别方便地重用已批准的功能和框架。通过收集整个组织中的安全设计模式（有时称为安全蓝图）并将其发布供所有人使用，促进集中化设计复用。SSG 网站的一个部分（见 [SR1.2]）可以推广在威胁建模或架构分析中识别出的积极元素，从而使好的想法广泛传播。这个过程是正式化的——临时的、偶然的注意是不够的。常用的设计模式可以加速开发，因此使用安全的设计模式非常重要，不仅适用于应用程序，也适用于所有软件资产（例如，微服务、API、容器、基础设施和自动化）。