成熟度模型中的建筑安全 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数据进行优化，以提高和改进其效果。