成熟度模型中的建筑安全 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]。