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

组织会监控其运行的软件输入，以便发现攻击。只有在人工或机器人定期查看日志并采取措施时，记录日志文件的监控系统才有用。对于网络应用程序，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]。