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

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。

该组织通过制定标准来满足安全指导的需求，这些标准说明了遵守政策和执行以安全为中心的设计、开发和运营的必要方式。标准可能要求如何执行基于身份的应用程序身份验证，或如何实施传输层安全，也可能由SSG确保提供参考实现。标准通常适用于超出应用程序代码范围的软件，包括容器构建、编排、基础设施即代码以及云安全配置。标准可以通过多种方式部署，以保持其可操作性和相关性。例如，它们可以被自动化集成到开发环境中（例如 IDE 或工具链），或者明确地与代码示例和部署工件（例如容器）关联。无论如何，要被认为是标准，它们必须被采纳和执行。技术栈标准 [SR3.4] 和引入新技术的标准 [SR3。可以预期它们会帮助创建这些标准，但并非必需。该组织有一个知名的中央平台，用于提供有关软件安全的信息。通常，这是由SSG和卫星团队（安全冠军）维护的内部网站，人们可以查阅以获取有关安全政策、标准和要求的最新信息，以及其他资源（如培训）。交互式门户比包含很少更新的指南文档的静态门户更好。组织通常会通过邮件列表、聊天频道（见 [T2.12]）以及面对面的会议来补充这些材料。开发团队越来越多地将软件安全知识直接嵌入组织之外的工具链和自动化中（例如，GitHub），但这并不消除由 SSG 主导的知识管理的必要性。合规性约束被转化为各个项目的安全要求，并传达给工程团队。这是组织合规战略中的关键环节——通过以需求的形式明确表现合规约束并告知相关方，组织表明合规是一项可管理的任务。例如，如果组织开发处理信用卡交易的软件，那么在安全需求阶段，PCI DSS 合规性就会发挥作用。在其他情况下，为实现国际互操作性而制定的技术标准可以包括有关合规需求的安全指导。将这些标准表示为需求还有助于在审计时提高可追溯性和可见性。将这些需求编纂成可重用的代码（参见 [SFD2.1]）或工件部署规范（参见 [SE1.4]）尤其有用。识别组织的代码库和构建软件中包含的开源组件及其依赖项，然后对其进行审核以了解其安全状况。组织使用各种工具以及交付管道提供的元数据来发现具有已知漏洞的旧版本开源组件，或者其软件依赖于同一组件的多个版本。通过使用自动化工具来寻找开源，无论是整个组件还是可能的大量借用代码，从而扩大工作规模。一些软件开发流水线平台、容器注册表和中间件平台已经开始将这种可见性作为元数据提供（例如，由幕后工件扫描产生的 SBOM [SE3.6]）。一些组织将软件生命周期多个阶段的组成分析结果结合起来，以获得在生产软件中包含的开源软件的更完整和更准确的列表。建立一个制定软件安全标准的流程，并确保所有利益相关者都有机会发表意见。这个审查过程可以通过为任何提议的安全标准指定一名发言人来进行，由此让该人承担证明标准达到其目标的责任，并获得利益相关者的支持和批准。企业架构或企业风险小组有时会承担创建和管理标准审查流程的责任。当标准直接作为软件实施时，负责的人可能是 DevOps 经理、发布工程师，或拥有相关部署工件（例如编排代码）的人。标准审查流程的常见触发因素包括定期更新、安全事件、发现重大漏洞、新技术的采用、企业收购等。SSG与法律部门合作，为与供应商和外包服务提供商（包括云服务提供商）的合同制定标准SLA模板，要求他们采取软件安全措施。法律部门也可能利用该模板来帮助防止合规性和隐私问题。根据协议，供应商和外包服务提供商必须满足公司规定的软件安全服务水平协议（SLA）（参见 [CP2.4]）。模板语言可能要求对软件安全工作提供客观的第三方见解，例如 SSDF 差距分析（https://csrc.nist.gov/Projects/ssdf）、BSIMMsc 测量或 BSIMM 分数。该组织能够控制因使用开源组件及所有相关依赖（包括运行时集成的依赖）而产生的风险。控制风险暴露通常包括多项措施，例如对已识别开源中的已知漏洞进行响应（见 [SR1.5]）。开源的使用也可能仅限于预定义的项目或经过批准的安全审查流程、已修复不可接受漏洞的少数版本，并且仅通过批准的内部仓库和容器提供。在某些用例中，政策可能完全禁止使用开源。由于许可证合规目标以及与 GPL 代码相关的传播性许可证问题，法律部门通常会主导额外的开源控制措施。与法律部门合作并对其进行教育的 SSG 可以帮助组织改善其开源风险管理实践，而这些实践必须在整个软件组合中应用才能有效。与供应商合作，对其进行教育，并推广组织的安全标准。与供应商的良好关系通常从合同条款开始（见 [CP2.4]），但SSG应与供应商接触，讨论供应商的安全实践，并用简单易懂的语言（而非法律术语）解释组织的期望。每当供应商采纳组织的安全标准时，都是进展的明显标志。请注意，以安全功能或基础设施配置形式实施的标准可能是与供应商进行服务集成的要求（参见 [SFD1.1]，[SE1.4]）。当公司的 SSDL 公布时，关于软件安全期望的沟通会更加容易。同样，分享内部实践和措施可以让预期更加清晰。开发人员使用安全编码标准来避免最明显的错误，并作为代码审查的基本规则。这些标准必然针对特定的编程语言，并且可以涉及流行框架、API、库和基础设施自动化的使用。安全编码标准也可以适用于低代码或无代码平台（例如）。例如，Microsoft Power Apps、Salesforce Lightning)。虽然在此阶段强制执行不是重点（见 [CR3.5]），但违反标准是所有利益相关者的一个可学习的机会。其他有用的编码标准主题包括正确使用云 API、使用批准的加密技术、内存清理、禁止的函数、开源使用以及许多其他内容。如果组织已经为其他目的（例如，风格）制定了编码标准，那么其安全编码标准应在这些基础上建立。一套清晰的安全编码标准是指导手动和自动代码审查的好方法，同时也可为安全培训提供相关示例。一些团队可能会选择将其安全编码标准直接整合到自动化中。宣传遵循标准的好处也是获得广泛认同的一个良好第一步（参见 [SM2.7]）。组织对特定技术栈的使用进行标准化，这意味着工作负担减轻，因为团队不必为每个新项目探索新的技术风险。组织可能会为每个技术栈创建一个安全的基础配置（通常以黄金镜像、Terraform 定义等形式），进一步减少安全使用该栈所需的工作量。在云环境中，加固的配置可能包括最新的安全补丁、配置和服务，例如日志记录和监控。在传统的本地部署 IT 环境中，一个技术栈可能包括操作系统、数据库、应用服务器和运行时环境（例如，MEAN 栈）。可重复使用技术（如容器、微服务或编排代码）的安全使用标准意味着，在一个环节上做好安全，将对所有下游工作中的安全态势产生积极影响（参见 [SE2.5]）。SSG参与制定内部技术实践，这些技术新到业界最佳实践尚未被规范化。让SSG参与探索性工作，以理解和规划新技术，可以通过主动考虑潜在的安全风险来最小化不安全实现带来的负面影响。SSG的参与可能导致政策和标准的更新 [SR1.1]、技术栈的新安全要求 [SR3.4]、安全设计的组件和服务 [SFD2.1, SFD3.2]，或编码指南 [SR3.3]。SSG必须参与与新技术采用相关的前瞻性工作，而不仅仅是事后保护现有集成 [SFD2]。2] 或根据不断变化的法规 [CP1.1] 或新出现的威胁情报 [AM1.5] 更新政策和标准。