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

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

SSG 已做好应对事件或警报的准备，并且定期参与事件响应流程，无论是通过建立自身的事件响应能力，还是通过定期与组织现有团队进行对接。SSG 与事件响应团队之间的固定会议确保信息双向流动。与关键供应商（例如）建立预先沟通渠道。ISP、监控、IaaS、SaaS、PaaS）也非常重要。通过运维监控在生产中发现的缺陷会反馈给开发，并用于改变工程行为。生产缺陷的有用来源包括事件、漏洞赏金（见 [CMVM3.4]）、负责任的披露（见 [CMVM2）。4]）、SIEM、生产日志、客户反馈，以及来自云安全态势监控、容器配置监控、RASP 和类似技术的遥测数据。将生产缺陷数据录入现有的缺陷跟踪系统（也许可以使用特殊的安全标记）可以闭合信息循环，并确保安全问题得到修复。此外，重要的是要总结生产缺陷中的经验教训，并利用这些经验教训改变组织的行为。在最理想的情况下，可以根据运营数据改进SSDL中的流程（见 [CMVM3.2]）。在运营中发现的缺陷（见 [CMVM1.2]）会被录入既定的缺陷管理系统，并在修复过程中进行跟踪。这种追踪能力可以表现为缺陷发现者与缺陷修复者之间的双向桥梁，或者通过中间人（例如漏洞管理团队）实现，但务必确保环路完全闭合。缺陷可能出现在所有类型的可部署工件、部署自动化和基础设施配置中。在缺陷跟踪系统中设置安全标志可以帮助跟踪。当软件（例如应用程序、API、微服务、基础设施）受到攻击时，组织可以快速进行代码和配置更改。应急响应小组与应用所有者、工程部门、运维部门以及SSG等利益相关者协作，研究代码和攻击，寻找解决方案并修复生产代码（例如，将补丁推送到生产环境、回滚到已知的良好状态、部署新容器）。通常，应急响应小组就是工程团队本身。在这里，明确的流程是必须的，未经使用的流程可能实际上并不可行。组织拥有其软件部署及相关的容器化、编排和部署自动化代码的地图，以及各自的负责人。如果需要更改或淘汰某个软件资产，运维或 DevOps 团队可以可靠地识别相关利益相关者以及需要进行更改的所有位置。可以记录公共组件，以便当一个应用程序出现错误时，共享相同组件的其他应用程序也可以得到修复。构建准确的库存表示可能需要至少列举源代码、在构建过程中和动态生产更新期间使用的开源软件、纳入生产镜像的编排软件以及生产环境中发生的任何服务发现或调用。当在操作中发现安全缺陷时（参见 [CMVM1.组织会查找并修复操作中所有缺陷的出现，而不仅仅是最初报告的那一个。主动执行这一操作需要在出现新类型缺陷时，能够重新检查整个操作软件清单（参见 [CMVM2.3]）。重新审查的一种方法是制定一套规则，将已部署的缺陷概括为可以通过自动代码审查扫描的内容。在某些环境中，处理缺陷可能需要立即将其从生产环境中移除，并在重新部署前按优先顺序进行实际修复。使用编排可以大大简化针对软件缺陷所有出现情况的修复部署（参见 [SE2.7]）。通过低摩擦的公共入口，为外部漏洞报告者提供与内部安全专家的沟通渠道。这些专家与漏洞报告者合作，触发必要的组织响应，并在整个缺陷管理生命周期中与外部实体协调。成功的信息披露流程需要来自内部利益相关者的见解，例如法律、市场营销和公共关系角色，以在软件安全危机期间简化和加快决策（参见 [CMVM3.3]）。尽管漏洞赏金对于激励一些研究人员可能很重要（参见 [CMVM3]）。适当的公开署名和低阻力的报告流程通常足以激励研究人员参与协调披露。大多数组织会结合使用易于找到的登录页面、常用邮箱地址（如 security@）以及在适当情况下嵌入的产品文档（如 security.txt）作为外部报告者启动该流程的入口。来自运营的经验会导致SSDL的变更（见 [SM1.1]），这些变更反过来可以被强化以防止缺陷的再次引入。为了使这一过程系统化，事件响应事后分析包括一个反馈到SSDL的步骤。事后分析的结果可能会导致 CI/CD 流水线中的基于工具的策略规则集发生变化，以及自动化部署配置的调整（见 [SE1.4]）。当根本原因分析能够准确找出软件生命周期中错误可能被引入或未被发现（例如缺陷逃逸）的环节时，这种方法的效果最好。DevOps 工程师可能会更容易应对这一点，因为所有相关人员都可能参与了讨论和解决方案的制定。对 SSDL 改进的临时方法不足以进行预防。SSG 模拟高影响的软件安全危机，以确保软件事件的检测和响应能力将损害降到最低。模拟可以测试识别和缓解特定威胁的能力，也可以从假设关键系统或服务已被攻破开始，评估组织的应对能力。计划的混沌工程在模拟过程中可以有效触发意外情况。演练必须包括在适当的软件层进行的攻击或其他软件安全危机，以产生有用的结果（例如，针对Web应用程序的应用层和针对物联网设备的较低层）。当模拟成功攻击时，一个需要考虑的重要问题是清理所需的时间。无论如何，模拟必须关注与安全相关的软件故障，而不是自然灾害或其他类型的应急演练。高度依赖供应商基础设施（例如云服务提供商、SaaS、PaaS）和安全功能的组织，自然会在危机模拟中涵盖这些内容。该组织向外部研究人员征集漏洞报告，并对每一份经过验证和接受的漏洞支付赏金。支付金额通常根据多种因素采取滑动比例，例如漏洞类型（例如，远程代码执行漏洞价值 10,000 美元，而...CSRF 值 750 美元），可利用性（可演示的漏洞利用通常获得更高的奖励），或特定服务和软件版本（广泛部署或关键服务的漏洞奖励更高）。临时或短期活动，如夺旗比赛或非正式的众包活动，并不构成漏洞赏金计划。SSG 与工程团队合作，通过自动化验证由受控自助服务流程生成的基础设施的安全属性（例如，遵守约定的安全加固措施）。工程师使用自助服务流程创建网络、存储、容器和虚拟机实例，协调部署，并执行曾经仅由 IT 执行的其他任务。在促进验证方面，该组织使用可机器读取的政策和配置标准（参见 [SE1.4]）来自动检测问题，并报告不符合预期的基础设施。在某些情况下，自动化会对正在运行的环境进行更改以使其符合要求，但在许多情况下，组织使用单一策略来管理不同环境中的自动化，例如在多云和混合云环境中。组织收集并发布有关其部署的应用程序、服务、API、容器及其他软件的风险信息。无论是通过人工过程还是遥测自动化捕获，发布的信息都超出了基本的软件安全（见 [SM2.1]）和库存数据（见 [CMVM2.3]），还包括风险信息。这些信息通常包括软件的组成（例如，BOMs [SE3].6]），关于创建它的团体及其方式的来源数据，以及与已知漏洞、部署模型、安全控制或每个工件固有的其他安全特性相关的风险。这种方法促进了跨职能协调，并帮助利益相关者采取知情的风险管理行动。列出不用于决策支持的风险清单，是无法获得有用结果的。操作标准和程序通过使用攻击情报和应用弱点数据主动最小化应用攻击面，以限制脆弱条件。在运维中发现和修复软件缺陷很重要（参见 [CMVM1.2]），同样重要的是发现和修复云安全模型、VPN、分段、网络、主机和应用程序的安全配置等方面的错误。，以限制成功攻击已部署应用程序的能力。将攻击情报（见 [AM1.5]）与软件资产信息（见 [AM2.9]）以及对应用程序弱点的持续监控相结合，有助于确保攻击面管理跟上攻击者的方法。在危机情况下进行攻击面管理时，软件物料清单（SBOM，见 [SE3.6]）也是一个重要的信息来源。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

外部渗透测试人员用于证明组织的软件存在问题。在高知名度的应用程序中发现关键漏洞，可以提供管理层通常需要的证据。随着时间的推移，渗透测试的重点从试图确定代码在某些方面是否存在缺陷，转变为在发布前或定期进行的合理性检查。除了破坏代码之外，这种合理性检查还可以有效地确保漏洞防护技术既被使用又有效。引入拥有新经验和技能的外部渗透测试人员对于解决问题最为有用。所有渗透测试结果都会通过既定的缺陷管理或缓解渠道反馈给工程部门，开发和运维部门通过缺陷管理和发布流程进行响应。除了应用程序漏洞外，还会跟踪其他软件的测试结果，例如容器和基础设施配置。如果正确执行，这项演练可以展示组织提升安全状况的能力，并强调不仅要发现安全问题，还要实际解决安全问题的重要性。确保引起重视的一种方法是在漏洞跟踪和缺陷管理系统中添加安全标记。组织可以利用开发者工作流程或社交工具（例如，JIRA 或 Slack）来沟通变更请求，但这些请求仍然作为漏洞管理流程的一部分被明确跟踪。组织建立了一个内部渗透测试能力，使用工具作为既定流程的一部分。执行可以由SSG负责，也可以作为组织中其他部门的专门团队的一部分，工具与人工操作互相补充，以提高测试过程的效率和可重复性。通常使用的工具包括专门用于应用渗透测试的现成产品、能够专门理解应用层的网络渗透工具、容器和云配置测试工具，以及自定义脚本。业余时间或危机驱动的尝试不能等同于内部能力。渗透测试人员，无论是内部还是外部，通常都会利用在软件安全开发生命周期（SSDL）中创建的各种工件，以进行更全面的分析并发现更多问题。示例工件包括设计文档、架构分析结果、误用和滥用案例、代码审查结果、云环境及其他部署配置，以及源代码（如适用）。关注高风险应用是一个良好的起点。请注意，拥有 SSDL 工件的访问权限并不等于使用它们。所有应用程序都会定期测试，这可能与日历或发布周期相关。高风险应用程序例如每年至少进行一次渗透测试，即使没有实质性的代码更改，而其他应用程序可能会按类似的时间表接受不同类型的安全测试。进行的任何安全测试都必须着重于发现漏洞，而不仅仅是检查某个流程或合规性标记。此测试作为一种合理性检查，有助于确保昨天的软件不会受到今天攻击的影响。测试还可以帮助维护软件配置和环境的安全性，尤其是针对云中的容器和组件。整个组合中定期安全测试的一个重要方面是确保已识别的问题得到实际修复。非应用程序的软件，例如为持续集成/持续交付（CI/CD）、基础设施即代码等创建的自动化，也值得进行一些安全测试。SSG 使用外部渗透测试人员对关键软件系统或技术进行深入分析，并引入新的思路。实现这一目标的一种方法是通过以目标为导向的红队演练来模拟持续性攻击者。这些测试人员是领域专家和专业人士，他们使组织能够跟上最新的攻击者视角，并且在破坏所测试的软件类型方面有良好的记录。在攻击组织的软件时，这些测试人员展现出创造性的方法，为设计、实施和强化新系统的人提供有用的知识。从威胁情报和滥用案例中创建新类型的攻击通常需要较长的时间表，这在涉及新技术时是必不可少的，并且可以防止仅查找已知问题类型的清单式方法。建立创建渗透测试工具的能力，或改编公开可用的工具，以更高效、更全面地攻击组织的软件。创建渗透测试工具需要对攻击（参见 [AM2.1]、[AM2.8]）和技术栈（参见 [AM3.4]）有深刻理解。定制现有工具不仅仅是配置更改，还包括扩展工具功能以发现新的问题。工具将在不影响SSG能够识别问题深度的前提下，提高渗透测试过程的效率。在使用敏捷方法的组织中，自动化尤其有价值，因为它可以帮助团队加快速度。可以定制的工具总是优于通用工具。成功往往取决于通过定制工具实现的测试的深度和范围。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，RASP 或 WAF 可以进行这种监控，而其他类型的软件可能需要其他方法，例如自定义运行时检测。软件和技术栈，例如移动端和物联网，可能需要它们自己的输入监控解决方案。无服务器和容器化软件可能需要与供应商软件进行交互，以获取适当的日志和监控数据。云部署和平台即服务的使用可能会为监控、数据收集和汇总方法增加另一个难度层面。该组织通过确保其数据中心和网络中的主机（无论是裸机还是虚拟机）及网络安全基础得到落实，并在新版本发布期间保持这些基础，从而为其运行中的软件提供了坚实的基础。主机和网络安全基础必须考虑不断演变的网络边界、日益增加的连接性和数据共享、软件定义网络，以及对供应商（例如内容分发、负载均衡和内容检查服务）的依赖增加。除了保护生产环境外，组织还应考虑保护其开发端点[SE3.10]和工具链[SE3.9]。在建立主机和网络安全之前进行软件安全，就像在穿袜子之前先穿鞋一样。组织确保云安全控制措施已经到位并在公有云和私有云中有效运行。行业最佳实践是制定本地政策和标准以推动控制和配置的良好起点。当然，基于云的资产通常具有面向公众的服务，这会产生不同于私有数据中心的攻击面（例如，基于云的存储），因此这些资产需要定制的安全配置和管理。在日益软件定义的世界中，SSG 必须帮助每个人明确配置特定于云的安全功能和控制（例如）。通过云提供商管理控制台) 类似于在私有数据中心使用电缆和物理硬件构建的系统。关于云提供商共享责任的安全模型的详细知识总是必要的，以确保正确的云安全控制措施得以保持。创建部署自动化或安装指南（例如标准操作程序）以帮助团队和客户安全地安装和配置软件。这里的软件包括应用程序、产品、脚本、镜像、固件以及其他形式的代码。部署自动化通常包括对软件工件和基础设施即代码（例如）进行清晰描述的配置。包括部署它们所需的工具（如 Terraform、CloudFormation、ARM 模板、Helm Charts），以及有关商业现成软件（COTS）、开源、供应商和云服务组件的详细信息。所有部署自动化应可被人类理解，而不仅仅是机器理解，尤其是在分发给客户时。当部署自动化不可用时，客户或部署团队需要包含加固指南和安全配置的安装指南。使用代码保护机制（例如，代码签名），使组织能够证明重要代码的来源、完整性和授权。尽管传统和移动平台通过即时代码签名和权限活动实现了这一点，但保护现代容器化软件则需要在各个生命周期阶段采取措施。组织可以使用构建系统验证依赖项的来源和清单，并创建自己的加密证明。打包和部署系统可以对二进制包进行签名和验证，包括代码、配置、元数据、代码身份以及发布材料的授权。在某些情况下，组织只允许来自其自身注册表的代码在特定环境中执行。保护代码完整性还包括保障开发基础设施安全，使用权限和同行评审来管理代码贡献，并限制代码访问以帮助保护完整性（参见[SE3.9]）。该组织使用应用容器来支持其软件安全目标。仅仅部署容器不足以获得安全收益，但有计划地使用它们可以支持应用程序与其依赖关系的更紧密结合、不可变性、完整性（参见 [SE2.4]）以及在无需在虚拟机上部署完整操作系统的开销下获得一些隔离优势。容器是应用和更新安全控制的便捷场所（参见 [SFD3]）。2]），虽然它们在开发和测试环境中非常有用，但在生产环境中的使用提供了所需的安全性收益。组织使用自动化以有序的方式扩展服务、容器和虚拟化环境。编排流程利用内置和附加的安全功能（见 [SFD2）。1]），例如防止漂移、秘密管理、基于角色的访问控制（RBAC）和回滚，以确保每个部署的工作负载都符合预定的安全要求。汇总设置安全行为可以在需要时快速进行变更。编排平台本身也是作为生产环境一部分的软件，这反过来又需要加固、安全补丁和配置——换句话说，如果你使用 Kubernetes，请确保对 Kubernetes 进行补丁更新。为了保护知识产权并增加漏洞开发的难度，组织会建立反向工程其软件的屏障（例如。反篡改、调试保护、防盗版功能、运行时完整性)。对于某些软件，混淆技术可以作为生产构建和发布过程的一部分进行应用。在其他情况下，当应用程序在部署后动态重新生成时，这些保护可以在软件定义网络或软件编排层应用。代码保护对于广泛分发的代码尤为重要，例如移动应用程序和分发到浏览器的 JavaScript。在某些平台上，可以使用数据执行防护（DEP），组织会监控生产软件以查找不当行为或攻击迹象。超越主机和网络监控，寻找特定软件的问题，例如恶意行为、欺诈及相关问题的迹象。应用层入侵检测和异常检测系统可能会关注应用程序与操作系统的交互（通过系统调用），或者应用程序消费、产生和操作的数据类型。应用程序没有按预期运行的迹象将取决于软件的业务逻辑及其环境，因此一刀切的解决方案可能无法产生令人满意的结果。在某些类型的环境中（例如，平台即服务），部分数据及相关的预测分析可能来自供应商。创建一个物料清单（BOM），详细列出重要生产软件的组件、依赖项及其他元数据。使用此物料清单帮助组织加强安全防护，即在攻击者和攻击手法不断演变、合规要求变化以及需要修补的项目数量大幅增加时，能够灵活应对。了解所有组件在运行软件中的位置——无论它们是在私有数据中心、云端，还是作为成品销售（见 [CMVM2.3]）——可以在不幸事件发生时及时作出响应。使用组合分析结果，将关于重要应用程序所有组成组件的数据补充到软件资产清单信息中。除了开源软件（见 [SR1.5]），还包括清单信息（见 [SM3.1）包括内部开发（第一方）、委托开发的代码（第二方）以及外部（第三方）软件的组件和依赖信息，无论这些软件是以源代码还是二进制形式存在。记录这些信息的一种常见方法是构建软件物料清单（SBOMs）。手动执行这项工作可能不可行——跟上软件的变化很可能需要工具链集成，而不是作为一次性活动来完成。这些信息在供应链安全工作中非常有用（见 [SM3.5]）。该组织通过维护和保护所有开发基础设施，并防止对源代码及其他软件生命周期工件的未经授权的更改，确保其构建和集成的软件的完整性。开发基础设施包括代码和工件仓库、构建管道以及部署自动化。通过安全处理和存储机密信息、遵循流水线配置要求、修补工具和构建环境、限制对流水线设置的访问以及审计配置变更来保障开发基础设施的安全。防止未经授权的更改通常包括对代码仓库执行最小权限访问以及要求对代码提交进行审批。自动为所有项目团队成员授予访问权限不足以充分保护软件的完整性。组织通过对与开发工具链交互的开发相关人员使用的工作站应用基本安全措施来维护其开发的软件的完整性。开发端点是用于编写源代码、配置开发工具链、测试软件功能或修改代码或工件存储库中的数据的工作站。组织可以通过限制或监控特权操作、确保操作系统和杀毒软件定义是最新的、审查已安装的软件，或者提供一个专门的、受保护的开发工作站（不用于管理任务）来保护开发端点。建立和应用开发端点安全基线不仅允许利益相关者执行软件开发所需的技术任务，还为开发工具链提供了另一层防护 [SE3.9]。

组建一个跨职能团队，了解适用于组织及其客户的软件安全的监管或合规要求所带来的限制。该团队采取统一的方法，消除冗余和冲突，整合合规要求，例如来自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]）。主动识别未来成员是创建一个促进安全融入软件开发和运维的社交网络的一步。一个由热情且有技能的志愿者组成的团队比一个被强制加入的团队更容易管理。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

具有安全意识的审查员会识别应用程序的安全功能，依据应用程序的安全需求和运行时参数对这些功能进行审查，并确定每个功能是否能够充分执行其预期的功能——通常统称为威胁建模。目标是快速识别缺失的安全功能和需求，或错误的部署配置（认证、访问控制、加密使用等），并进行处理。例如，威胁建模可以识别由于访问控制漏洞而受到特权提升攻击的系统，以及错误将个人身份信息存储在本地的移动应用程序。使用公司设计安全组件通常可以简化这一过程（参见 [SFD2.1]）。许多现代应用程序不再只是简单的“3 层架构”，而是涉及跨各种层级交互的组件——浏览器/终端、嵌入式、Web、微服务、编排引擎、部署管道、第三方 SaaS 等。其中一些环境可能提供强大的安全功能集，而另一些环境可能存在关键能力缺口，需要仔细分析，因此组织应考虑整个架构和操作环境各层中安全功能的适用性和正确使用。进行设计审查，以确定安全功能和部署配置是否能够抵抗攻击尝试，以破坏设计。其目标是将安全功能审查的更公式化的方法（见 [AA1.1]）扩展到在真实世界的攻击者和攻击背景下对应用行为进行建模。审查人员必须拥有超越简单威胁建模的经验，包括执行详细的设计评审和分析所考虑的设计漏洞。设计评审不应只是提供安全功能指导，而应产生一系列缺陷并制定缓解计划。组织可以聘请顾问来完成这项工作，但应积极参与其中。仅关注软件项目是否执行了正确流程步骤的评审不会产生关于缺陷的有用结果。注意，足够稳健的设计评审过程无法以 CI/CD 的速度执行，因此组织应从少数高风险的应用程序入手（参见 [AA1.4]）。使用已定义的风险方法收集每个应用程序的信息，以便分配风险分类和相关的优先级。使用这些信息来确定哪些应用程序或项目在测试范围内是非常重要的，包括安全功能和设计评审。信息收集可以通过问卷或类似方法进行，无论是手动还是自动化。用于分类所需的信息可能包括，“该应用程序使用哪些编程语言编写？”或“谁使用该应用程序？”或“该应用程序的部署是否由软件编排？”通常，由应用团队的合格成员提供这些信息，但整个过程应简短，仅需几分钟。然后，SSG 可以使用这些答案将应用程序分类为，例如。例如，高、中或低风险。由于风险问卷很容易被操纵，因此重要的是实施一些抽查以确保其有效性和准确性——过度依赖自我报告可能会使这一活动变得无效。定义并使用一个用于AA的流程，该流程不仅扩展设计评审（见 [AA1.2]），还用于记录业务风险以及技术缺陷。目标是识别应用程序设计缺陷以及相关风险（例如，被利用的影响），例如通过频率或概率分析，以更全面地为利益相关者的风险管理工作提供信息。AA流程包括一种标准化的方法，用于考虑攻击、漏洞和各种安全属性。该流程定义得足够清晰，以至于SSG外的人也可以执行。记录正在审查的架构、发现的任何安全漏洞以及人们可以理解和使用的风险信息都非常重要。Microsoft 威胁建模、Versprite PASTA 和 Black Duck ARA 是此类流程的例子，尽管这些流程可能需要根据特定环境进行调整。在某些情况下，执行AA和记录业务风险是由不同团队在一个流程中共同完成的。未经校准或临时的AA方法不算作已定义的流程。威胁建模、设计审查或AA流程采用约定的格式（例如，图示语言和图标，而不仅仅是文本描述）来描述架构，包括表示数据流的方式。在生成模型的人与分析和注释模型的人之间标准化架构描述，使分析更加易处理和可扩展。高级网络图、数据流和授权流总是有用的，但模型还应详细说明软件本身的结构。标准的架构描述可以增强，以提供需要保护的信息资产的明确图示，包括有用的元数据。统一使用的图标在图表、模板以及白板涂鸦中尤其有用。SSG在执行设计评审（见 [AA1.2]）以发现缺陷方面发挥主导作用。拆解一个架构本身就是一门艺术，SSG 或其他应用团队之外的审查员必须精通，而精通则需要实践。这种实践随后可能使得例如冠军能够在日常工作中承担领导，而 SSG 则保持在知识和流程方面的领导地位。SSG自身也无法独立成功——它很可能需要建筑师或执行者的帮助来理解设计。有了清晰的设计，SSG可能能够在与项目团队的最少互动下进行详细的审查。设计审查的方法会随着时间而演变，所以不要指望设定一个流程后就永远使用它。外包设计审查可能是必要的，但这也是一个参与和学习的机会。工程团队领导 AA 以发现技术缺陷并记录业务风险。这项工作需要一个充分理解和良好记录的流程（参见 [AA2.1]）。即便有良好的流程，要保持一致性也很困难，因为架构的变更需要经验，因此应为架构师提供 SSG 或外部专家的咨询支持。执行 AA 的工程团队通常可能承担开发、DevOps、云安全、运维安全、架构安全或其他类似职责。如果AA团队与设计团队不同，这一过程会更有用。在威胁建模、设计评审或AA过程中发现的失败会反馈给安全和工程团队，以便通过改进设计模式防止将来出现类似错误，无论该模式是团队内部使用还是正式批准供所有人使用（见[SFD3.1]）。这通常需要一个根本原因分析过程，以确定安全漏洞的来源，查找本应防止漏洞的措施，并在文档化的安全设计模式中进行必要的改进。请注意，安全设计模式可能会以意想不到的方式相互作用，从而破坏安全性，因此即使在标准使用经过验证的设计模式时，也应应用分析过程。对于云服务，提供商已经学到了很多关于其平台和服务如何无法抵御攻击的经验，并将这些经验总结为安全使用的模式。严重依赖这些服务的组织在构建自己的应用层模式时，可能会以云服务提供商提供的这些基础构件（例如 AWS CloudFormation 和 Azure Blueprints）为基础。为了建立组织的AA能力，SSG将专家作为资源或导师推荐给使用AA流程的团队（见 [AA2.1]）。这一努力可能使例如安全专家、网站可靠性工程师、DevSecOps工程师等能够带头，而SSG则提供建议。例如，导师会帮助调整 AA 流程输入（例如设计或攻击模式），使其在特定技术堆栈中更具可操作性。这种可重复使用的指导有助于节省团队的时间，让他们能够专注于那些需要创造性解决方案的问题，而不是重复列出已知的不良习惯。虽然 SSG 可能会在办公时间回答 AA 问题（参见 [T2）。在这种情况下，他们通常会分配一名导师与团队合作，该团队可能由具有安全意识的工程师和风险分析师组成，协助整个分析过程。对于高风险软件，SSG 应在应用 AA 流程中发挥更积极的指导作用。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

以机会主义的方式对高风险应用程序进行代码审查。例如，组织可以在设计审查之后进行代码审查，查找源代码和依赖项中的安全问题，也可能包括部署工件配置（例如，容器）和自动化元数据（例如，基础设施即代码）。这种非正式的目标设定通常会发展为系统化的方法（见 [CR1.4]）。人工代码审查可以借助特定的工具和服务来增强，但它必须成为主动流程的一部分。当新的技术出现时，代码审查可能需要采用新的方法。将静态分析纳入代码审查流程，以提高审查的效率和一致性。自动化不会取代人工判断，但它确实为审查过程提供了明确性，并为通常不是安全专家的审查者带来了安全专业知识。需要注意的是，特定工具可能无法涵盖整个项目组合，特别是当涉及新语言时，因此额外的本地努力可能是有用的。一些组织可能会进一步通过将静态分析工具集成到源代码管理工作流（例如，拉取请求）和交付流水线工作流（构建、打包和部署）中来实现工具使用的自动化，以使审查更加高效、一致，并与发布节奏保持一致。无论是使用自动化工具对源代码的一部分进行增量审查，例如开发人员提交新代码或小的更改，还是通过扫描整个代码库进行全面分析，该服务都应明确与软件开发过程中应用的更大型安全软件开发生命周期（SSDL）缺陷管理流程相连接。仅仅为了“打勾安全检查”而进行的努力是没有用的。以安全为重点的代码审查是所有软件项目的强制要求，缺乏代码审查或出现不可接受的结果会阻止发布、延缓发布，或导致软件被召回。虽然所有项目都必须进行代码审查，但不同类型的项目可能有不同的审查流程。对低风险项目的审查可能更多依赖于自动化（参见 [CR1.4]），例如，而高风险项目的审查者所花费的时间可能没有上限。设定最低可接受标准迫使不合格的项目进行修正并重新评估。一个几乎关闭了所有规则的代码审查工具（例如，以便它可以在 CI/CD 自动化速度下运行）不会提供足够的缺陷覆盖。同样，关注质量和风格的同伴代码审查或工具也不会提供有用的安全结果。导师会向开发人员展示如何充分利用代码审查工具，包括配置、分流和修复。安全冠军、DevOps 和网站可靠性工程师以及 SSG 成员通常是很好的导师。导师可以使用办公时间或其他外展活动来帮助开发人员建立正确的配置，并开始解释和修复结果。或者，导师可以在开发团队进行第一次审查时与其一起工作。工具的集中使用可以通过工具导师在一段时间内分配到开发组织或工具链中，但仅提供安装说明和集中工具下载的 URL 并不等同于指导。越来越多地，指导还扩展到与部署工件（例如容器安全）和基础设施（例如云配置）相关的代码审查工具。虽然人工智能在增强人工代码审查指导方面变得有用，但它可能没有替代人工审查所需的上下文。在代码审查工具中创建并使用自定义规则，以帮助发现与组织的编码标准或组织使用的基于框架或云提供的中间件相关的安全缺陷。提供工具指导的同一组（见 [CR1）。7]）很可能会引领这种定制化。自定义规则通常明确地与技术栈的正确使用相关联，以积极的方式促进使用，同时以消极的方式避免公司代码库中常见的错误。自定义规则也是检查是否遵守编码标准的一种简便方式（参见 [CR3.5]）。为了减轻每个人的工作量，许多组织还会制定规则以消除重复的误报，并关闭不相关的检查。维护一份组织希望从代码中消除的最重要类型错误的动态清单，并利用它来推动变革。许多组织一开始使用从公共来源获取的通用列表，但像 OWASP Top 10 这样的大范围列表很少能反映组织的漏洞优先级。通过使用从代码审查（见 [CR2.8]）、测试（见 [PT1.2]）、软件组成分析（见 [SE3.8]）以及实际事件（见 [CMVM1.1]）收集的真实数据来建立有价值的列表，然后根据防护工作进行优先排序。仅仅按照每天的缺陷发生次数对数据进行排序不会产生令人满意的列表，因为数据变化非常频繁。为了增加兴趣，SSG 可以在更新列表后定期发布“最想要”报告。顶级 N 列表的一个潜在问题是，它往往只包含已知的问题。当然，仅仅建立清单并不会有任何效果——每个人都必须使用它来查找和修复漏洞。在代码审查中发现的缺陷会被记录在一个集中式的存储库中，这使得组织可以进行汇总和趋势报告。报告的缺陷会推动工程改进，例如改进流程、更新标准、采用可重用框架等。例如，代码审查信息通常会被整合到 CISO 级仪表板中，该仪表板可以包括来自其他安全测试工作的数据源（例如，渗透测试、成分分析、威胁建模）。根据历史代码审查数据，SSG 还可以使用这些报告来展示进展（见 [SM3.3]）或指导培训课程。个别缺陷是很好的培训示例（见 [T2.8]）。一些组织已经开始分析这些数据，并利用结果推动自动化（参见 [ST3.6]）。将应用程序安全测试（AST）结果结合起来，使多种测试技术汇入一个报告和整改流程。除了代码审查之外，测试技术通常还包括动态分析、软件成分分析、容器扫描、云服务配置审查等。SSG 可能会编写脚本或获取软件以自动收集数据，并将结果整合成可被单一下游审查和报告解决方案使用的格式。这项活动的棘手之处在于，需要将来自不同来源的漏洞信息进行标准化，这些来源可能使用冲突的术语或评分。在某些情况下，可以使用标准化分类法（例如类似 CWE 的方法可以帮助实现规范化。结合多个来源有助于推动更明智的风险缓解决策并识别工程改进。当在代码审查期间发现安全漏洞（参见 [CR1.2]、[CR1.4]）时，组织会搜索并修复所有该漏洞的出现，而不仅仅是最初发现的实例。使用自定义规则进行搜索（参见 [CR2）。6]）使得完全消除特定漏洞成为可能，而无需等待每个项目都进入其生命周期中的代码审查阶段。这并不意味着在发现特定示例时需要找到每一种跨站脚本漏洞的每个实例——而是意味着要在所有地方针对该特定示例采取措施。只有少数几个基于单一技术栈构建的软件应用程序的公司，在这项活动中会比拥有许多基于多种技术栈构建的大型应用程序的公司更容易应对。新的开发框架或库、RASP 中的规则或下一代防火墙，或者提供防护指导的云配置工具，通常可以帮助消除工作（但不能替代消除工作）。使用自动化代码审查来识别由内部开发者或外包供应商编写的恶意代码。恶意代码的示例包括后门、逻辑炸弹、定时炸弹、恶意通信渠道、混淆的程序逻辑以及动态代码注入。虽然开箱即用的自动化可能会识别出一些通用的恶意构造，但对于静态分析工具而言，自定义规则来规范组织代码库中可接受和不可接受的模式可能会变得必不可少。手动审查恶意代码是一个好的起点，但对于大规模完成此项工作来说是不够的。虽然并非所有后门或类似代码在编写时都是恶意的（例如，开发人员为了测试而绕过认证的功能），但这些东西通常会保留在已部署的代码中，并且应被视为恶意，除非有证据证明不是。发现某些类型的恶意代码需要使用动态测试技术。违反安全编码标准足以成为拒绝某段代码的充分理由。这种拒绝可以采取一种或多种形式，例如拒绝拉取请求、中断构建、质量保证未通过、从生产环境中移除，或将代码移入不同的开发工作流以便修复或处理例外情况。组织强制执行的安全编码标准部分（见 [SR3.3]）通常一开始只是一个被禁止的函数或必需框架的简单列表。针对标准的代码审查必须是客观的——它不应成为关于非合规代码是否可被利用的争论。在某些情况下，编码标准特定于语言构造，并通过工具执行（例如，编入SAST规则中）。在其他情况下，已发布的编码标准是针对特定技术栈的，并在代码审查过程中或通过自动化手段进行强制执行。标准可以是积极的（“以这种方式做”）或消极的（“不要使用此 API”），但必须执行。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。

质量保证工作不仅限于功能测试，还会进行基本的对抗性测试，并探讨简单的边界情况和边界条件，无需特定的攻击者技能。当质量保证工作超越使用预期输入的标准功能测试时，它就开始向像攻击者一样思考的方向迈进。边界值测试，无论是自动化还是手动，都自然会引出攻击者故意探测边界的概念（例如，确定当有人反复输入错误密码时会发生什么）。QA 以安全需求和功能为基础，通过测试针对声明式安全机制。测试可以尝试以非特权用户身份访问管理功能，例如，或验证用户账户在多次身份验证失败后是否会被锁定。在大多数情况下，安全功能可以像其他软件功能一样进行测试——安全机制如账户锁定、交易限制、权限等。根据安全需求，对预期和意外输入进行测试。软件安全并不是安全软件，但测试安全功能是一个简单的入门方法。新的软件架构和部署自动化，例如使用容器和云基础设施编排，可能需要新的测试方法。该组织在质量保证过程中使用一种或多种不透明安全测试工具。这类工具非常有价值，因为它们能够概括攻击者的视角，尽管是通用的。传统的动态分析扫描器适用于 web 应用程序，而类似的工具也存在于云环境、容器、移动应用程序、嵌入式系统、API 等中。在某些情况下，其他团队可能会与SSG合作使用这些工具。例如，测试团队可以运行该工具，但会向SSG寻求结果解释的帮助。当测试被整合到敏捷开发方法中时，不透明箱工具可能会接入内部工具链，由基于云的工具链提供，或直接由工程团队使用。无论谁运行不透明工具，测试都应适当地整合到 SSDL 的 QA 循环中，并且通常包括经过认证和未认证的评审。将应用程序安全测试的结果，如渗透测试、威胁建模、组件分析、代码审查等，与 QA 团队分享，以推广安全意识。以安全缺陷为基础来讨论常见攻击模式或其潜在原因，可以让质量保证团队将这些信息概括为新的测试方法。利用如 GitHub 之类的软件管道平台或如 Atlassian 系列的 CI/CD 平台的组织，可以从团队自动接收各种测试结果中受益，这应当有助于及时进行利益相关者的对话——仅仅将安全报告通过电子邮件发送给 QA 团队并不会产生预期的效果。随着时间的推移，质量保证团队会学习安全思维，组织也会从能够创建针对组织代码定制的安全测试的能力提升中受益。安全测试被纳入自动化框架，并与功能、性能及其他质量保证测试套件一起运行。执行该自动化框架可以通过手动触发，也可以通过额外的自动化（例如，作为流水线工具的一部分）触发。当了解软件的测试创建者设计安全测试时，他们能够发现商业工具可能无法发现的更专业或更相关的缺陷（参见 [ST1.4]）。安全测试可能来源于安全功能的典型故障（参见 [SFD1.1]）、对功能测试和开发者测试的创造性调整，甚至可能来源于渗透测试人员提供的关于如何重现问题的指导。手动或带外执行的测试可能无法提供及时的反馈。质量保证工作包括针对对组织至关重要的 API 运行定制的模糊测试框架。API 可能是允许两个应用程序之间通信的软件，甚至可能是允许人类与应用程序交互的软件（例如，网页表单）。测试人员可以从零开始或使用现有的模糊测试工具包，但所需的定制通常不仅仅是创建自定义协议描述或文件格式模板，而是需要让模糊测试框架内置对应用程序接口和业务逻辑的理解。专门为特定应用程序开发的测试工具框架是集成模糊测试的良好场所。使用设计评审或架构分析结果来指导QA测试的创建。例如，如果尝试破坏设计的结果表明“系统的安全依赖于事务是原子性的且不会在中途被中断”，那么被中断的事务将成为对抗性测试的主要目标。像这样的对抗性测试可以根据风险概况来制定，其中高风险缺陷排在列表的顶部。与 QA 共享的安全缺陷数据（见 [ST2.4]）可以帮助将测试创建的重点放在潜在易受攻击的区域，从而有助于证明已识别的高风险缺陷的存在。测试人员衡量其应用程序安全测试的代码覆盖率，以识别未被执行的代码，然后调整测试用例以逐步提高覆盖率。应用安全测试（AST）可以包括自动化测试（参见 [ST2.5]，[ST2.6]）和手动测试（参见 [ST1.1]，[ST1.3]）。反过来，代码覆盖率分析推动了安全测试深度的增加。使用标准度量（例如功能覆盖、行覆盖或多条件覆盖）时，覆盖分析更容易。关键在于衡量测试用例对安全需求的覆盖范围，这不同于衡量测试用例对代码的执行范围。QA 团队会根据滥用用例（参见 [AM2]）来设计测试用例。1]）随着测试人员不仅仅停留在验证功能，而是开始从攻击者的角度进行思考。一种方法是系统地尝试复现组织历史上的事件。基于攻击者视角的滥用和误用案例也可以从安全策略、攻击情报、标准以及组织的前N大攻击列表中得出（见 [AM3.5]）。这一努力使质量保证（QA）从测试功能转向尝试破坏被测试软件的阶段迈出关键一步。SSG 指导自动化的实施，以进行持续的、事件驱动的应用程序安全测试。这里的事件仅仅是指值得注意的事件，例如将新代码放入代码库、提交拉取请求、构建请求或发布到部署环境。在管道自动化中实施的事件驱动测试（而不仅仅是在生产中测试）通常会使测试更接近触发测试需求的条件（无论是向设计阶段左移还是向运维阶段右移），在事件被触发时反复执行测试，并有助于确保在给定条件下执行正确的测试。这种方法的成功取决于广泛使用传感器（例如，代理、机器人）来监控工程过程、执行上下文规则，并向自动化系统提供遥测数据，当事件条件满足时，自动化系统会启动指定的测试。更成熟的配置通常包括基于风险的条件（例如，变更的规模、来源、功能、团队）。