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

处理软件安全的流程已被定义、在内部发布，并向所有利益相关者传播，以便每个人都了解计划。目标、角色、职责和活动都明确规定。大多数组织会审查现有的方法，如 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]）。