成熟度模型中的建筑安全 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]）也是一个重要的信息来源。