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

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自PCI安全标准、美国的GLBA、SOX和HIPAA，或欧盟的GDPR。正式的方法将把适用的法规部分映射到应用于软件的控制（参见 [CP2.3]），以解释组织如何遵守规定。由法律、产品管理或其他位于 SSG 外的风险与合规团队运行的现有业务流程可以作为监管焦点，而 SSG 提供软件安全知识。一套统一的软件安全指导方针，用于应对监管压力，确保合规工作尽可能高效地完成。SSG 确认源于法规和客户期望的隐私义务，然后将这些义务转化为软件需求和隐私最佳实践。软件处理个人身份信息（PII）的方式可能受到明确的法规约束，但即使没有，隐私仍然是一个重要话题。例如，如果组织处理信用卡交易，SSG 将有助于识别 PCI DSS 对持卡人数据处理施加的隐私限制，并将通知所有相关方（参见 [SR1.3]）。请注意，外包到托管环境（例如，云) 并不会放松隐私义务，甚至可能增加识别和满足所有相关需求的难度。此外，请注意，开发在客户环境中处理个人身份信息（PII）的软件产品的公司，可能通过为其客户提供隐私控制和指导来满足这一需求。不断变化的消费者隐私期望、“软件无处不在”的普及，以及数据抓取和关联（例如社交媒体）为个人身份信息（PII）的保护增加了额外的期望和复杂性。SSG通过创建或参与制定满足内部、监管和客户驱动的安全要求的软件安全政策来指导组织。该政策规定了在倡议层面上允许和禁止的事项——如果不是强制的并受到执行，那就不是政策。政策包括一种统一的方法，用于满足治理层面上（可能很长的）安全驱动因素列表，以便项目团队无需跟进遵守所有适用法规或其他要求的具体细节。同样，项目团队无需自行重新学习客户的安全要求。架构标准和编码指南不是政策的例子，但规定并要求在某些软件类别中使用它们的政策属于这一范畴。在许多情况下，政策声明会被转化为自动化，以提供代码化治理。即使不由人类执行，已经自动化的政策仍然必须是强制性的。在某些情况下，政策将仅以治理即代码的形式记录（参见 [SM3.4]），通常作为工具配置，但它仍然必须能够被人类轻松阅读、审计和编辑。该组织识别并跟踪其每个系统处理或存储的个人可识别信息（PII）的类型，以及相关的数据存储库。一般来说，仅仅记录哪些应用程序处理PII是不够的——还需要标明PII的类型（例如，PHI、PFI、PI）及其存储位置，以便在关键情况下能轻松参考清单。这通常包括列出如果发生泄露需要通知客户的数据库，或列出用于危机模拟的数据库（参见 [CMVM3.3]）。构建个人身份信息（PII）清单可以从每个应用程序开始，记录其使用的PII，或者从PII类型开始，记录每种类型涉及的应用程序。系统架构已经发展到这样的程度，即个人可识别信息（PII）经常会流入基于云的服务和终端设备生态系统，然后停留在那里（例如，内容分发网络、工作流系统、移动设备、物联网设备），这使得保持准确的个人可识别信息清单变得棘手。该组织拥有正式的合规风险接受签署和问责流程，涵盖所有软件开发项目。在此过程中，SSG 充当顾问，而风险所有者则在软件发布前根据其符合已记录标准的情况签署合规状态。签字政策可能还要求业务部门负责人，例如承认尚未解决的合规问题或被跳过的与合规相关的SSDL步骤，但即使在不存在与合规相关的风险时，也需要签字确认。签字确认是明确的，并会被记录以供将来参考，任何例外情况都会被跟踪，即使在自动化应用生命周期方法中也是如此。请注意，即使应用程序没有安全缺陷，它仍可能不符合合规要求，因此干净的安全测试结果不能替代合规签署。即使在具有技术能力发布软件的 DevOps 组织中，也仍然需要一个明确的风险接受步骤，即使合规标准已嵌入自动化流程中（见 [SM3.4]）。在风险负责人批准了一套特定的合规接受标准，并将其通过自动化实施以提供代码化治理的情况下，必须持续验证这些标准是否仍然准确，以及自动化是否真正有效运行。该组织能够证明其符合适用要求，因为其安全软件开发生命周期（SSDL）与由安全策略小组（SSG）与合规利益相关者共同制定的控制声明一致（见[CP1.1]）。SSG与相关利益者合作，以跟踪控制措施，解决问题领域，并确保审计员和监管机构满意。当遵循 SSDL 的行为能够可预测且可靠地自动生成所需的合规性证据时，SSG 可以保持在后台。越来越多地，DevOps 方法将合规性控制嵌入到自动化中，例如在软件定义的基础设施和网络中，而不是依赖人工流程和手动干预。一家妥善进行此操作的公司可以明确地将满足其合规性需求与遵循其SSDL联系起来。软件供应商合同包括服务水平协议（SLA），以确保供应商的安全努力与组织的安全和合规性要求一致。每一份新合同或续签合同都包含要求供应商处理软件安全问题并交付符合组织安全政策的产品或服务的条款。在某些情况下，开源许可证问题会启动供应商管理流程，这可能为SLA中增加额外的软件安全条款提供机会（见［SR2.5］）。典型规定对政策遵循、事件管理、培训、缺陷管理以及处理软件安全问题的响应时间设定了要求。传统的IT安全要求以及仅允许渗透测试或其他缺陷发现方法的简单协议在这里是不够的。通过向高管提供组织合规和隐私要求及未能满足这些要求的潜在后果的通俗解释，获得对合规和隐私义务的认同。对于一些组织，解释合规失败或数据泄露的直接成本和可能的影响，可能是引入这一话题的有效方式。对于其他人来说，让外部专家向董事会汇报是有效的，因为一些高管更重视外部观点胜于内部观点。高管正确支持的一个明显标志是认可需求，并分配足够的资源来履行这些义务。利用通常在合规或隐私失误后产生的紧迫感来提高额外的意识，并启动新的工作。SSG 可以按需展示组织最新的软件安全合规情况。合规情况说明是一组数据、文档、策略控制或其他文档，展示组织软件和流程的合规状态。通常，高级管理层、审计人员以及监管机构——无论是政府还是其他机构——都会对可以直接通过各种工具生成的相同类型的报告感到满意。在某些情况下，特别是当组织通过云服务利用共享责任时，组织将需要从供应商处获取有关该供应商的控制措施如何支持组织合规需求的额外信息。通常有必要对来自不同来源的信息进行标准化。确保供应商的软件安全政策和 SSDL 流程与内部政策兼容。供应商可能由各种不同类型组成——云服务提供商、中间件提供商、虚拟化提供商、容器和编排提供商、定制软件开发者、承包商以及其他许多类型——每种类型可能需要遵守不同的政策要求。策略遵守的执行可能通过一次性审查（例如确保验收标准）、自动化检查（例如应用于拉取请求、已提交的工件如容器或类似内容），或者通过约定和协议（例如除非安全设置正确且存在预期的证书，否则防止服务连接）来进行。供应商遵从性的证据可能包括来自安全软件开发生命周期（SSDL）活动的结果、手动测试或直接内置于自动化或基础设施中的测试结果，或来自其他软件生命周期工具的数据。对于某些政策或SSDL流程，仅供应商问卷回复和声明可能已足够。将软件生命周期中的信息反馈到策略创建和维护过程，以推动改进，例如缺陷预防和加强以代码治理的实践（参见 [SM3.4]）。通过将此反馈作为常规流程，可以通过将其映射到SSDL失败的趋势来消除盲点。事件如经常出现不充分的架构分析、反复出现的漏洞、被忽视的安全发布条件，或选择错误的供应商进行渗透测试，都可能暴露政策的薄弱环节（参见 [CP1.3]）。例如，生命周期数据，包括 KPI、OKR、KRI、SLI、SLO 或其他组织指标，可以表明政策在哪里引入了过多的官僚主义，从而产生摩擦，阻碍工程按预期的交付节奏进行。快速的技术发展也可能导致政策空白，需要加以解决。随着时间的推移，政策会变得更加实用，执行起来也更容易（见 [SM1.1]）。最终，政策会根据SSDL数据进行优化，以提高和改进其效果。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 NIST SSDF、Microsoft SDL 或 Black Duck Touchpoints，然后根据自身需求进行调整。安全活动将适应软件生命周期流程（例如，瀑布、敏捷、CI/CD、DevOps），因此这些活动会随着组织和安全环境的变化而发展。该流程无需在公司外部公开推广即可产生预期影响（参见 [SM3.2]）。除了发布书面流程之外，一些公司还会对部分流程进行自动化（例如。，一种测试策略）作为治理即代码（参见 [SM3.4]）。高层管理人员经常会被展示恶意行为者攻击软件的方式以及这些攻击对组织可能产生的负面业务影响。超越对已开放和已关闭缺陷的报告，教育高层管理人员了解业务风险，包括在没有安全监督的情况下采用新兴工程技术和方法论的风险。在所有相关人员许可的情况下，在受控环境中演示最糟情况（例如，通过展示攻击及其对业务的影响）。向董事会汇报可以帮助争取新或持续的SSI项目的资源。展示在不断发展的领域中对新技能培训的需求，例如使用云原生技术的 DevOps 团队，可以帮助说服领导层接受 SSG 的建议，当这些建议可能会因追求更快的发布时间或其他优先事项而被忽视时。在必要时引入外部专家，以增强高管的关注度。软件安全流程包括在软件生命周期的一个或多个阶段设置检查点（如关卡、发布条件、防护措施、里程碑等）。建立特定于安全的检查点条件的前两步是确定与现有开发实践兼容的流程位置，然后开始收集必要的信息，例如风险等级阈值或缺陷数据，以做出继续或停止的决定。重要的是，此阶段无需强制执行这些条件——例如。，SSG可以在发布前收集每个项目的安全测试结果，然后就何谓充分测试或可接受测试结果提供知情意见，而无需阻止项目推进（参见[SM1.7]）。较短的发布周期可能需要创造性方法收集正确的证据，并且高度依赖自动化。社会化这些条件，并在大多数项目团队已经知道如何成功后执行，这是一种渐进的方法，能够激励良好行为，同时避免不必要的摩擦。在每个检查点（大门、护栏、里程碑等）执行安全释放条件。）用于每个项目，因此每个项目必须要么满足既定的衡量标准，要么遵循获得例外以继续推进的规定流程。使用内部政策和标准、法规、合同协议及其他义务来定义发布条件，然后跟踪所有例外情况。验证条件会生成数据，这些数据可用于指导关键风险指标（KRI）以及管理流程中使用的其他任何指标。自动给软件评分通过或在未经充分考虑的情况下给予例外，会违背验证条件的初衷。即便是看似无害的软件项目（例如，小的代码更改、基础设施访问控制更改、部署蓝图）也必须在软件生命周期的各个阶段成功满足规定的安全条件。同样，API、框架、库、定制代码、微服务、容器配置等都是必须满足安全发布条件的软件。在开发过程本身之前和之后对这些条件进行验证是可能的，而且通常非常有用。在现代开发环境中，验证过程将越来越多地实现自动化（见 [SM3.4]）。为了促进改进，组织内部会发布关于软件安全状态的数据。为高管和软件开发管理层制作包含指标的安全或开发仪表盘。仪表盘可以作为流水线工具链的一部分，以促进开发人员自我改进。有时，这些公开的数据不会与公司里的每个人共享，而只会与那些负责推动变革的利益相关者共享。在其他情况下，公开管理和向所有利益相关者发布的数据可以帮助每个人了解发生了什么。如果组织的文化促进各组间的内部竞争，可以利用这些信息增加安全维度。集成自动化安全遥测，以快速、准确地收集度量数据，从而提高安全数据的及时性，例如在速度（如修复时间）和质量（如缺陷密度）方面。在新技术（如云原生架构中的安全和风险）方面发布数据，对于识别所需改进非常重要。在组织中组建一群分散的人——通常被称为安全冠军——他们表现出高于平均水平的安全兴趣或技能，并为开发、质量保证和运维团队提供软件安全专业知识。形成这个倡导者的社交网络，是将安全扩展到软件工程中的一个良好步骤。建立初始团队的一种方法是跟踪在入门培训课程中表现突出的人员（参见[T3.6]）。另一种方法是征求志愿者。在更自上而下的方法中，初始的骨干成员是被指定的，以确保开发小组的良好覆盖，但后续的成员资格则基于实际表现。冠军可以作为新项目的意见交流平台，在新兴或快速发展的技术领域，他们可以帮助将软件安全技能与可能在SSG或工程团队中代表性不足的领域知识结合起来。敏捷教练、敏捷主管和DevOps工程师尤其可以成为有用的冠军成员，特别是在识别和消除流程摩擦方面。在某些环境中，卫星主导的工作是通过自动化（例如，代码化）来实现的。组织有一项覆盖整个计划的流程，用于记录责任并接受安全风险，即由风险负责人使用SSG批准的标准对所有软件在发布前的状态进行签核。签核政策还可能要求负责人，例如承认尚未缓解的关键漏洞或被跳过的SSDL步骤。仅凭非正式的或不了解情况的风险接受并不是安全签核，因为当风险接受形式化（例如，通过签名、表单提交或类似方式）并被记录以供将来参考时，其效果更佳。同样，仅仅声明某些项目完全不需要审批，并不能达到预期的风险管理效果。然而，在某些情况下，风险负责人可以对特定的软件项目验收标准集提供审批，然后将其实施到自动化中，以提供代码化治理（见 [SM3）。4]），但必须持续验证标准是否保持准确，并确保自动化正常运行。通过持续的宣传在整个组织中建立对软件安全的支持，并确保每个人在安全目标上保持一致。这一内部营销职能通常由各种利益相关者角色执行，能够让高管和其他人员及时了解软件安全问题的严重性及其解决方案的各个要素。例如，熟悉安全的倡导者或Scrum大师可以在团队转向敏捷和DevOps方法时，帮助他们采用更好的软件安全实践。同样，云计算专家可以演示无服务器应用程序在安全架构和测试方面所需的更改。布道者可以通过向内部团队（包括高管）进行演讲、发布路线图、撰写供内部使用的技术论文，或在内部网站上创建论文、书籍和其他资源的合集来增加理解并建立可信度（见[SR1。2]）并推动其使用。反过来，组织的反馈成为改进创意的有用来源。SSG 使用集中跟踪自动化来记录每个软件和可部署工件从创建到退役的进展情况，无论其开发方法如何。自动化记录了已计划、正在进行和已完成的安全活动，即使这些活动在紧密循环中或部署期间发生，也会纳入SSDL活动的结果。综合的清单和安全态势视图能够实现及时的决策。SSG使用自动化生成多个指标的组合报告，并且在许多情况下，至少在高管之间发布这些数据。随着一项倡议的成熟以及活动变得更加分散，SSG 使用集中报告系统来跟踪所有的运动部分。为了建立外部认知，SSG 帮助向内部团队之外推广 SSI。向外部分享细节并邀请批评的过程被用来将新的视角引入公司。在外部推广SSDL可以将安全工作转化为市场差异化因素，而来自外部市场的反馈可以将SSI的风险降低措施发展为竞争优势。SSG可能会在外部会议或展会中提供详细信息。在某些情况下，完整的SSDL方法论可以在公司外发布和推广，而治理即代码的概念可以成为有趣的案例研究。SSG及其管理层会确定定义和量化衡量SSI进展的指标。这些指标会定期进行审查，并推动项目的预算和资源分配，因此简单的计数和脱离上下文的测量在这里是不够的。在技术方面，其中一个指标可能是缺陷密度，其减少可以用来显示随时间推移的修复成本下降，当然前提是测试深度能够跟上软件的变化。指标数据最好通过事件驱动的流程和遥测频繁、尽早收集，而不是依赖于基于日历的数据收集。关键是将安全结果清晰、明显地与业务目标联系起来，以证明资源投入的合理性。因为对许多商业人士来说，安全的概念本身已经很模糊，因此需要明确地说明这种联系。各组织开始用基于软件的交付平台取代传统的基于文档、演示文稿和电子表格的生命周期管理。在某些软件生命周期阶段，人类已不再是从一个阶段推进到下一个阶段的主要推动力。相反，组织依赖自动化来推动管理和交付过程，使用的软件如 Spinnaker 或 GitHub，而人类则以异步方式参与（且通常是可选的）。自动化通常不仅限于 CI/CD 的范围，还包括交付的功能性和非功能性方面，例如健康检查、失败时的切换、回滚到已知的良好状态、缺陷发现与管理、合规性验证，以及确保遵守政策和标准的方法。一些组织也在通过整合其合规性和缺陷发现数据，可能结合情报信息和其他外部数据，来发展其生命周期管理方法，从而开始从一系列特定时间点的通过/不通过决策（例如发布条件）转向持续累积保证数据的未来状态（见 [CMVM3.6]）。组织风险管理流程确保进入组织的重要软件以及组织内部创建的软件通过政策驱动的访问和使用控制、维护标准（见 [SE3.9]）以及记录的软件来源数据（见 [SE2.4]）进行管理。将这些流程应用于外部（见 [SR2.7]）、定制以及内部开发的软件（见 [SE3。9]）以帮助确保已部署的代码具有预期的组件（参见 [SE3.8]）。从创建或导入到安全部署的整个软件生命周期管理，确保所有访问、使用和修改都符合政策。在软件生命周期过程中使用自动化在大规模实施时可以更容易地实现这一保障（参见 [SM3.4]）。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

为了在整个组织中推广软件安全文化，SSG定期开展软件安全意识培训。此培训可能通过SSG成员、安全倡导者、外部公司、内部培训组织或电子学习的方式进行，但课程内容不一定针对特定受众量身定制——例如，开发人员、QA工程师和项目经理都可能参加同一个“软件安全入门”课程。通过量身定制的方法增强此内容，明确针对公司的文化，这可能包括构建安全性的流程、避免常见错误以及技术主题，如 CI/CD 和 DevSecOps。仅涵盖基础 IT 或高层次安全概念的通用入门课程无法产生令人满意的效果。同样，仅针对开发人员而不针对组织中其他角色的意识培训是不足的。通过为 SSDL 利益相关者提供按需培训，组织可以减轻学生的负担并降低提供软件安全培训的成本。最明显的选择是电子学习，它可以通过订阅模式保持更新，但在线课程必须对不同角色的学生（例如开发人员、QA、云端、运维）具有吸引力和相关性，以实现其预期目标。无效的（例如过时的、偏离主题的）培训或未被使用的培训不会带来任何改变。热门的工程话题如容器化和安全编排，以及诸如游戏化的新培训方式，将比枯燥的政策讨论更能吸引人们的兴趣。对于开发人员来说，可以在需要时直接通过IDE提供培训，但在某些情况下，建立新的技能（如云安全或威胁建模）可能更适合由讲师主导的培训，这种培训也可以按需提供。将新员工引入软件工程组织的过程需要及时完成一门关于软件安全的培训课程。虽然通用的新员工入职流程通常涵盖选择强密码和防范网络钓鱼等主题，但该培训期进行了增强，以涵盖如何创建、部署和操作安全代码、软件安全开发生命周期（SSDL）、安全标准（见[SR1.1]）以及内部安全资源（见[SR1.2]）等内容。其目标是确保新员工能够尽快为安全文化做出贡献。尽管通用的入职模块很有用，但它无法替代及时且更完整的软件安全入门课程。通过邀请嘉宾讲师或举办关于高级软件安全主题的特别活动，加强安全冠军网络（参见 [SM2.3]）。这一努力旨在为冠军提供定制化培训（例如。，最新的软件安全技术用于DevOps或无服务器技术，或关于新政策和标准的影响）以便其能够履行分配的职责——这并不是关于邀请冠军成员参加常规的午餐学习会，或让他们报名参加标准的计算机培训课程。同样地，一个允许自愿参加的固定电话会议也无法达到预期效果，因为这些效果既涉及建立同事之间的友情，也涉及知识共享和组织效率。定期活动可以建立社区，促进协作和集体解决问题。面对面的会议无疑是最有效的，即使每年只举行一两次，即使有些参与者必须通过视频会议参加。在拥有大量地理位置分散且在家工作的成员的团队中，仅仅打开摄像头并确保每个人都有发言机会就能产生显著的效果。为了在行为上实现强有力且持久的改变，培训包括与公司软件安全挑战历史相关的材料。当参与者能够在问题中看到自己时，他们更有可能理解这些材料与自己的工作相关，以及何时以及如何应用所学知识。一种方法是将针对公司软件的显著攻击作为培训课程中的示例。成功和失败的攻击，以及渗透测试、设计审查和红队演练的显著结果，都可以成为很好的教学案例。公司历史中的故事可以帮助引导培训走向正确的方向，但前提是这些故事仍然相关且不过度审查。培训应涵盖开发人员使用的平台（负责容器编排的开发人员可能不会关心旧的虚拟化问题）以及与常用编程语言相关的问题。软件安全培训不仅仅是提高意识（见 [T1）。1）旨在使学生能够将安全实践融入到他们的工作中。这种培训专门涵盖与学生最相关的工具、技术栈、开发方法和问题。一个组织可以为其工程师提供不同的培训路径，例如，为架构师、开发人员、运维人员、DevOps、站点可靠性工程师和测试人员各提供一个培训路径。在这样的课程中，通常也需要针对特定工具的培训。虽然它可能比工程培训更简明，但对于组织内的许多其他利益相关者（包括产品管理、管理层等）来说，角色特定培训也是必要的。无论如何，培训必须由足够广泛的受众参与，以建立所需的整体技能组合。该组织举办安全活动，邀请外部讲者和提供相关内容，以加强其安全文化。这类活动的好例子包括 Intel iSecCon 和 AWS re:Inforce，这些活动邀请所有员工参与，邀请外部演讲者，并专注于帮助工程团队创建、部署和运行更高质量的代码。员工可以从听取外部观点中受益，尤其是那些与快速发展技术领域相关并涉及软件安全的观点，同时组织也可以通过展示其安全资质受益（参见 [SM3.2]）。仅对小型精选群体开放的活动，或者仅仅将录音放在内部门户上，都无法在整个组织中带来预期的文化变革。参与 SSDL 的每个人都必须每年参加一次软件安全复训课程。该课程能够让员工及时了解组织的安全策略，并确保组织不会因为人员流动、方法演变或部署模式变化而失去重点。SSG 可能会提供安全形势的最新信息，并解释政策和标准的变更。复习课程也可以作为公司整体安全日的一部分推出，或与内部安全会议配合进行。虽然一个复习模块可以用于多个角色（见 [T2.9]），但涵盖新主题和对前一年内容的更新应当产生大量新的内容。软件安全专家会在定期安排的办公时间或在 Slack、Jira 或类似的公开渠道上，以开放的方式为任何人提供帮助。通过作为希望解决安全问题的人的非正式资源，SSG 利用可教的时刻，并强调在安全最佳实践中以奖励为主而非惩罚的方式。办公时间可能由高级SSG成员每周主持一次下午，并可能邀请负责解决复杂安全问题的产品或应用小组进行简短汇报。Slack 和其他消息应用可以全天候捕捉问题，在适当的主题专家持续参与对话并确保生成的答案符合 SSG 期望的情况下，起到办公时间平台的作用。在线方法的额外好处是讨论可以被记录并可搜索。在安全课程的学习过程中取得进展会带来个人收益，例如获得公开认可或职业晋升。奖励体系可以是正式的，例如颁发认证或在人力资源系统中记录官方标志，也可以是非正式的，包括在年度评估时记录表扬等激励措施。让公司培训部门和人力资源团队参与进来，可以使提升安全技能对职业发展的影响更加明显，但SSG应继续监控公司内的安全知识，而不应完全放弃控制或监督。咖啡杯和T恤可以提升士气，但通常需要真实的职业发展机会才能真正改变行为。供应商和外包员工接受适当的软件安全培训，其水平与员工所接受的培训相当。在一开始就花时间和精力帮助供应商做好安全防护，要远比事后试图查明问题出在哪里简单得多，尤其是在开发团队已经转向其他项目的情况下。培训个人承包商比培训整个外包公司更自然，也是一个合理的起点。无论员工的雇佣状态如何，重要的是所有使用公司软件的人都应具备适当的培训水平，以提高他们满足其岗位软件安全期望的能力。当然，一些供应商和外包工作人员可能已经从他们自己的公司接受了充分的培训，但这总是需要进行核实。未来的安全冠军是通过注意那些在展示技能和热情的机会中表现突出的人来招募的，例如培训课程、办公时间、夺旗赛、黑客马拉松等，然后鼓励他们加入冠军团队。特别注意那些贡献代码、安全配置或缺陷发现规则的从业者。冠军计划通常开始于一组被指定的人，这些人分散在整个组织中，他们表现出高于平均水平的安全兴趣或对新技术栈和开发方法拥有高级知识（参见 [SM2.3]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。