DevOps Security 涵盖与 DevOps 流程中安全工程和作相关的控制措施，包括部署阶段之前的关键安全检查（例如静态应用程序安全测试、漏洞管理）的部署，以确保整个 DevOps 流程的安全性：它还包括威胁建模和软件供应安全性等常见主题。
DS-1：执行威胁建模
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 16.10, 16.14 | SA-15 | 6.5, 12.2 |
安全原则：执行威胁建模以识别潜在威胁并枚举缓解控制措施。 确保您的威胁建模能够达到以下目标：
- 在生产运行时阶段保护应用程序和服务。
- 保障用于构建、测试和部署的工件、基础 CI/CD 管道及其他工具和环境的安全。 威胁建模至少应包括以下几个方面：
- 定义应用程序的安全要求。 确保在威胁建模中充分满足这些要求。
- 分析应用程序组件、数据连接及其关系。 确保此分析还包括应用程序范围外的上游和下游连接。
- 列出应用程序组件、数据连接以及上游和下游服务可能暴露的潜在威胁和攻击途径。
- 确定可用于缓解枚举的威胁的适用安全控制措施，并识别可能需要其他治疗计划的任何控制漏洞（例如安全漏洞）。
- 枚举和设计可缓解标识的漏洞的控件。
Azure 指南：将威胁建模工具（如Microsoft威胁建模工具）与嵌入的 Azure 威胁模型模板配合使用，以推动威胁建模过程。 使用 STRIDE 模型枚举内部和外部的威胁，并确定适用的控件。 确保威胁建模过程包括 DevOps 进程中的威胁场景，例如通过访问控制策略配置不当的不安全项目存储库进行的恶意代码注入。
如果使用威胁建模工具不适用，则至少应使用基于问卷的威胁建模过程来识别威胁。
确保在应用程序或威胁环境中发生重大安全影响更改时记录和更新威胁建模或分析结果。
Azure 实现和额外背景信息：
AWS 指南：将威胁建模工具（如Microsoft威胁建模工具）与嵌入的 Azure 威胁模型模板配合使用，以推动威胁建模过程。 使用 STRIDE 模型枚举内部和外部的威胁，并确定适用的控件。 确保威胁建模过程将威胁方案纳入 DevOps 过程，例如通过访问控制策略配置错误的不安全制品库进行恶意代码注入。
如果使用威胁建模工具不适用，则至少应使用基于问卷的威胁建模过程来识别威胁。
确保在应用程序或威胁环境中发生重大安全影响更改时记录和更新威胁建模或分析结果。
AWS 实现和其他上下文：
GCP 指南：将威胁建模工具（如Microsoft威胁建模工具）与嵌入的 Azure 威胁模型模板配合使用，以推动威胁建模过程。 使用 STRIDE 模型枚举内部和外部的威胁，并确定适用的控件。 确保威胁建模过程中纳入 DevOps 流程中的威胁场景，例如由于访问控制策略配置错误，通过不安全的工件存储库进行的恶意代码注入。
如果使用威胁建模工具不适用，则至少应使用基于问卷的威胁建模过程来识别威胁。
确保在应用程序或威胁环境中发生重大安全影响更改时记录和更新威胁建模或分析结果。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：
DS-2：确保软件供应链安全性
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 16.4, 16.6, 16.11 | SA-12、SA-15 | 6.3, 6.5 |
安全原则：确保企业 SDLC（软件开发生命周期）或流程包含一组安全控制措施，用于管理应用程序具有依赖项的内部和第三方软件组件（包括专有和开源软件）。 定义限制条件，以防止集成并部署到环境中的易受攻击或恶意组件。
软件供应链安全控制至少应包括以下方面：
- 通过确定服务/资源开发、生成、集成和部署阶段所需的上游依赖项，正确管理软件材料清单（SBOM）。
- 当上游有修补程序可用时，清单并跟踪内部和第三方软件组件是否存在已知漏洞。
- 使用静态和动态应用测试评估软件组件中的漏洞和恶意软件，以发现未知漏洞。
- 使用适当的方法确保缓解漏洞和恶意软件。 这可能包括源代码本地或上游修复、功能排除和/或应用补偿控件（如果直接缓解不可用）。
如果在生产环境中使用闭源第三方组件，则可能对其安全状况具有有限的可见性。 应考虑其他控制措施，例如访问控制、网络隔离和终结点安全性，以最大程度地减少与组件关联的恶意活动或漏洞的影响。
Azure 指南：对于 GitHub 平台，通过 GitHub 高级安全性或 GitHub 本机功能的以下功能或工具确保软件供应链安全性：- 使用 Dependency Graph 通过顾问数据库扫描、清查和识别项目的所有依赖项和相关漏洞。
- 使用 Dependabot 确保跟踪和修正易受攻击的依赖项，并确保存储库自动跟上它所依赖的包和应用程序的最新版本。
- 使用 GitHub 的本机代码扫描功能在外部采购代码时扫描源代码。
- 使用 Microsoft Defender for Cloud 在 CI/CD 工作流中集成容器映像的漏洞评估。 对于 Azure DevOps，可以使用第三方扩展来实现与清单、分析和修正第三方软件组件及其漏洞类似的控制。
Azure 的实施和附加上下文：
AWS 指南：如果使用 AWS CI/CD 平台（如 CodeCommit 或 CodePipeline），请确保使用 CodeGuru Reviewer 的软件供应链安全性通过 CI/CD 工作流扫描源代码（适用于 Java 和 Python）。 CodeCommit 和 CodePipeline 等平台还支持第三方扩展来实现与清单、分析和修正第三方软件组件及其漏洞类似的控制。
如果通过 GitHub 平台管理源代码，请通过 GitHub 高级安全性或 GitHub 的本机功能中的以下功能或工具确保软件供应链安全性：
- 使用 Dependency Graph 通过顾问数据库扫描、清查和识别项目的所有依赖项和相关漏洞。
- 使用 Dependabot 确保跟踪和修正易受攻击的依赖项，并确保存储库自动跟上它所依赖的包和应用程序的最新版本。
- 使用 GitHub 的本机代码扫描功能在外部采购代码时扫描源代码。
- 如果适用，请使用 Microsoft Defender for Cloud 在 CI/CD 工作流中集成容器映像的漏洞评估。
AWS 实现和其他上下文：
GCP 指南：使用软件交付防护执行端到端软件供应链安全分析。 这包括保证的 OSS（开源软件）服务，用于访问并合并由 Google 验证和测试的 OSS 包，以及使用 Google 安全管道生成的已验证的 Java 和 Python 包。 这些包会定期扫描、分析和测试漏洞。 此类功能可以集成到 Google Cloud Build、Cloud Deploy、Artifact Registry、Artifact Analysis 作为 CI/CD 工作流的一部分。
如果通过 GitHub 平台管理源代码，请通过 GitHub 高级安全性或 GitHub 的本机功能中的以下功能或工具确保软件供应链安全性：
- 使用 Dependency Graph 通过顾问数据库扫描、清查和识别项目的所有依赖项和相关漏洞。
- 使用 Dependabot 确保跟踪和修正易受攻击的依赖项，并确保存储库自动跟上它所依赖的包和应用程序的最新版本。
- 使用 GitHub 的本机代码扫描功能在外部采购代码时扫描源代码。
- 如果适用，请使用 Microsoft Defender for Cloud 在 CI/CD 工作流中集成容器映像的漏洞评估。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：
DS-3：安全 DevOps 基础结构
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 16.7 | CM-2、CM-6、AC-2、AC-3、AC-6 | 2.2, 6.3, 7.1 |
安全原则：确保 DevOps 基础结构和管道遵循跨环境（包括生成、测试和生产阶段）的安全最佳做法。 这通常包括以下范围的安全控制：
- 用于存储源代码、构建包和映像、项目制品以及业务数据的制品库。
- 托管 CI/CD 管道的服务器、服务和工具。
- CI/CD 管道配置。
Azure 指南：在将Microsoft云安全基准应用于 DevOps 基础结构安全控制时，优先考虑以下控制措施：
- 保护项目和基础环境，以确保 CI/CD 管道不会成为插入恶意代码的途径。 例如，查看 CI/CD 管道，确定 Azure DevOps 核心区域中的任何错误配置，例如组织、项目、用户、管道（生成和发布）、连接和生成代理，以识别任何错误配置，例如开放访问、弱身份验证、不安全的连接设置等。 对于 GitHub，请使用类似的控件来保护组织权限级别。
- 确保跨开发项目一致地部署 DevOps 基础结构。 使用 Microsoft Defender for Cloud（例如合规性仪表板、Azure Policy、云状况管理）或你自己的合规性监视工具大规模跟踪 DevOps 基础结构的合规性。
- 在 Azure AD、本机服务和管道中的 CI/CD 工具中配置标识/角色权限和权利策略，以确保对管道的更改获得授权。
- 避免为人工帐户（例如开发人员或测试人员）提供永久的特权访问权限，建议使用 Azure 托管标识和及时访问等功能。
- 从 CI/CD 工作流作业中使用的代码和脚本中删除密钥、凭据和机密，并将其保存在密钥存储或 Azure Key Vault 中。
- 如果您运行自托管的构建/部署代理，请遵循 Microsoft 云安全基准控制，包括网络安全、安全形势和漏洞管理，以及终端安全性，以保护您的环境。
注意：请参阅“日志记录和威胁检测”、“DS-7”和“姿态与漏洞管理”部分，以使用 Azure Monitor 和 Microsoft Sentinel 等服务，为您的 DevOps 基础设施启用治理、合规性、运营审计和风险审计功能。
Azure 实现和其他上下文：
AWS 指南：在将 Microsoft 云安全基准应用于 DevOps 基础结构的安全控制（如 GitHub、CodeCommit、CodeArtifact、CodePipeline、CodeBuild 和 CodeDeploy）的安全控制过程中，优先考虑以下控件：
- 请参阅本指南和 AWS 精心构建的框架安全支柱，以保护 AWS 中的 DevOps 环境。
- 保护制品和底层支持基础设施，以确保 CI/CD 管道不会成为插入恶意代码的途径。
- 确保在整个开发项目中一致地部署并持续部署 DevOps 基础结构。 使用 AWS 配置或你自己的合规性检查解决方案大规模跟踪 DevOps 基础结构的合规性。
- 使用 CodeArtifact 安全地存储和共享用于应用程序开发的软件包。 可以将 CodeArtifact 与常用的生成工具和包管理器（如 Maven、Gradle、npm、yarn、pip 和 twine）配合使用。
- 在您的管道中配置 AWS IAM、原生 AWS 服务以及 CI/CD 工具中的身份和角色权限及权限策略，以确保管道修改获得授权。
- 从 CI/CD 工作流作业中使用的代码和脚本中删除密钥、凭据和机密，并将其保留在密钥存储或 AWS KMS 中
- 如果您运行自托管的构建/部署代理，请遵循Microsoft云安全基准控制措施，包括网络安全、安全态势和漏洞管理以及端点安全性，以保护您的环境。 使用 AWS 检查器来扫描 EC2 或容器化环境中的漏洞作为生成环境。
注意：请参阅日志记录和威胁检测、DS-7 和姿态和漏洞管理部分，以便借助 AWS CloudTrail、CloudWatch 和 Microsoft Sentinel 等服务为 DevOps 基础结构启用治理、合规审核、操作审计和风险审计。
AWS 实现和其他上下文：
GCP 指南：在将Microsoft云安全基准应用于 DevOps 基础结构安全控制时，优先考虑以下控制措施：
- 保护项目和基础环境，以确保 CI/CD 管道不会成为插入恶意代码的途径。 例如，查看 CI/CD 管道，以确定 Google Cloud Build、Cloud Deploy、Artifact Registry、Connections 和 Build Agent 等服务中的任何错误配置，以识别任何错误配置，例如开放访问、弱身份验证、不安全连接设置等。 对于 GitHub，请使用类似的控件来保护组织权限级别。
- 确保跨开发项目一致地部署 DevOps 基础结构。 使用 Google Cloud Security 命令中心（如合规性仪表板、组织策略、单个威胁记录和识别错误配置）或你自己的合规性监视工具大规模跟踪 DevOps 基础结构的合规性。
- 在 Cloud Identity/AD 原生服务中配置身份/角色权限和权限策略，并在你的流水线中配置 CI/CD 工具，以确保对流水线的更改经过授权。
- 避免使用 Google 托管标识等功能向人工帐户（如开发人员或测试人员）提供永久的“站立”特权访问权限。
- 从 CI/CD 工作流作业中使用的代码和脚本中删除密钥、凭据和机密，并将其保存在密钥存储或 Google 机密管理器中。
- 如果您运行自托管的构建/部署代理，请遵循Microsoft云安全基准中的控制措施，包括网络安全、状态和漏洞管理，以及终端安全，以确保您的环境安全。
注意：请参阅日志记录和威胁检测、DS-7 和“姿态和漏洞管理”部分，以便使用 Azure Monitor 和 Microsoft Sentinel 或 Google Cloud 运营套件和 Chronicle SIEM 和 SOAR 等服务，为 DevOps 基础结构启用治理、合规性、操作审核和风险审核。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：
DS-4：将静态应用程序安全测试集成到 DevOps 管道
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 16.12 | SA-11 | 6.3, 6.5 |
安全原则：确保静态应用程序安全测试（SAST）模糊测试、交互式测试、移动应用程序测试，是 CI/CD 工作流中控制措施的一部分。 可以根据测试结果设置此限制，以防止易受攻击的包提交到存储库、生成到包中或部署到生产环境。
Azure 指南：将 SAST 集成到管道（例如基础结构中的代码模板中），以便可以在 CI/CD 工作流中自动扫描源代码。 Azure DevOps Pipeline 或 GitHub 可以将以下工具和第三方 SAST 工具集成到工作流中。
- 用于源代码分析的 GitHub CodeQL。
- Microsoft BinSkim Binary Analyzer for Windows 和 *nix 二进制分析。
- Azure DevOps 凭据扫描程序（Microsoft 安全 DevOps 扩展）和 GitHub 原生机密扫描，可以在源代码中扫描凭据。
Azure 实现和额外的背景信息：
AWS 指南：将 SAST 集成到管道中，以便可以在 CI/CD 工作流中自动扫描源代码。
如果使用 AWS CodeCommit，请使用 AWS CodeGuru Reviewer 进行 Python 和 Java 源代码分析。 AWS Codepipeline 还可以支持将第三部分 SAST 工具集成到代码部署管道中。
如果使用 GitHub，则可以将以下工具和第三方 SAST 工具集成到工作流中。
- 用于源代码分析的 GitHub CodeQL。
- Microsoft BinSkim 二进制分析器，用于 Windows 和 *nix 的二进制分析。
- GitHub 原生机密扫描，用于在源代码中扫描凭据。
- 用于 Python 和 Java 源代码分析的 AWS CodeGuru 审阅者。
AWS 实现和其他上下文：
GCP 指南：将 SAST（如软件交付盾、项目分析）集成到管道（例如基础结构中的代码模板中），以便可以在 CI/CD 工作流中自动扫描源代码。
云生成、云部署、项目注册表等服务支持与软件交付盾和项目分析的集成，它可以扫描 CI/CD 工作流中的源代码和其他项目。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：
DS-5：将动态应用程序安全测试集成到 DevOps 管道
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 16.12 | SA-11 | 6.3, 6.5 |
安全原则：确保动态应用程序安全测试（DAST）是 CI/CD 工作流中控制措施的一部分。 可以根据测试结果来设置该限制，以防止漏洞生成到包中或部署到生产环境。
Azure 指南：将 DAST 集成到管道中，以便在 Azure DevOps 或 GitHub 中的 CI/CD 工作流集中自动测试运行时应用程序。 自动渗透测试（使用手动辅助验证）也应是 DAST 的一部分。
Azure DevOps Pipeline 或 GitHub 支持将第三方 DAST 工具集成到 CI/CD 工作流中。
Azure 实现和其他上下文：
AWS 指南：将 DAST 集成到管道中，以便在 AWS CodePipeline 或 GitHub 中的 CI/CD 工作流集中自动测试运行时应用程序。 自动渗透测试（使用手动辅助验证）也应是 DAST 的一部分。
AWS CodePipeline 或 GitHub 支持将第三方 DAST 工具集成到 CI/CD 工作流中。
AWS 实现和其他上下文：
GCP 指南：将 DAST（例如云 Web 安全扫描程序）集成到管道中，以便在 Google Cloud Build、Cloud Deploy 或 GitHub 等服务中的 CI/CD 工作流集中自动测试运行时应用程序。 云 Web 安全扫描程序可用于识别应用引擎、Google Kubernetes 引擎（GKE）和计算引擎上托管的工作负载 Web 应用程序中的安全漏洞。 自动渗透测试（使用手动辅助验证）也应是 DAST 的一部分。
Google Cloud Build、Google Cloud Deploy、Artifact Registry 和 GitHub 还支持将第三方 DAST 工具集成到 CI/CD 工作流中。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：
DS-6：在整个 DevOps 生命周期内加强工作负载的安全性
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 7.5, 7.6, 7.7, 16.1, 16.7 | CM-2、CM-6、AC-2、AC-3、AC-6 | 6.1, 6.2, 6.3 |
安全原则：确保在开发、测试和部署阶段的整个生命周期内保护工作负荷。 使用 Microsoft 云安全基准来评估可在默认情况下或者在部署阶段之前“左移”设置为防护措施（例如网络安全、身份管理、特权访问等）的控制措施。 具体而言，请确保在 DevOps 过程中实施以下控制：- 通过在 CI/CD 工作流中使用 Azure 或第三方工具、基础结构管理（基础结构即代码）和测试来自动执行部署，以减少人为错误和攻击面。
- 确保虚拟机、容器映像和其他制品免受恶意篡改的安全保护。
- 在 CI/CD 工作流中的部署之前扫描工作负荷项目（换句话说，容器映像、依赖项、SAST 和 DAST 扫描）
- 将漏洞评估和威胁检测功能部署到生产环境中，并在运行时持续使用这些功能。
Azure 指南：Azure VM 指南：
- 使用 Azure 共享映像库可以共享和控制组织中不同用户、服务主体或 AD 组对映像的访问。 请使用 Azure 基于角色的访问控制 (Azure RBAC) 来确保只有授权用户才能访问自定义映像。
- 定义 VM 的安全配置基线，以消除不必要的凭据、权限和包。 通过自定义映像、Azure 资源管理器模板和/或 Azure Policy 客户配置来部署和强制实施配置基线。
Azure 容器服务的指南：
- 使用 Azure 容器注册表（ACR）创建专用容器注册表，可在其中通过 Azure RBAC 限制精细访问，因此只有经过授权的服务和帐户才能访问专用注册表中的容器。
- 使用 Defender for Containers 对专用 Azure 容器注册表中的映像进行漏洞评估。 此外，还可以使用 Microsoft Defender for Cloud 将容器映像扫描作为 CI/CD 工作流的一部分集成。
对于 Azure 无服务器服务，应采用类似的控制措施，以确保在部署之前的阶段将安全控制“左移”。
Azure 实现和其他上下文：
AWS 指南：使用 Amazon Elastic Container Registry 共享和控制组织中不同用户和角色对映像的访问。 使用 AWS IAM 确保只有经过授权的用户才能访问自定义映像。
定义 EC2 AMI 映像的安全配置基线，以消除不必要的凭据、权限和包。 通过自定义 AMI 映像、CloudFormation 模板和/或 AWS 配置规则部署和强制实施配置基线。
使用 AWS 检查器对 VM 和容器化环境进行漏洞扫描，防止其受到恶意作。
对于 AWS 服务器无服务器服务，建议结合使用 AWS CodePipeline 和 AWS AppConfig 以采用类似的控制措施，从而确保安全控制能够在部署前的阶段“左移”。
AWS 实现和其他上下文：
GCP 指南：Google Cloud 包括用于保护计算资源和 Google Kubernetes 引擎 （GKE） 容器资源的控制措施。 Google 提供 Shielded VM，这种技术加强了 VM 实例的安全性。 它提供启动安全性、监视完整性并使用虚拟受信任的平台模块 （vTPM）。
使用 Google Cloud 工件分析来扫描容器或操作系统映像中的漏洞，以及在您的流水线中按需或自动扫描其他类型的工件。 使用容器威胁检测持续监视 Container-Optimized OS 节点映像的状态。 该服务会评估所有更改和远程访问尝试，以近乎实时地检测运行时攻击。
使用制品库设置用于安全管理的私有构建制品存储，以便持续控制谁可以通过注册表原生的 IAM 角色和权限访问、查看或下载制品，并在 Google 的安全可靠基础设施上始终保持高可用性。
对于 GCP 无服务器服务，采用类似的控制措施，以确保安全控制提前到部署前的阶段。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：
DS-7：在 DevOps 中启用日志记录和监视
| CIS Controls v8 ID | NIST SP 800-53 r4 ID | PCI-DSS ID v3.2.1 |
|---|---|---|
| 8.2, 8.5, 8.9, 8.11 | AU-3、AU-6、AU-12、SI-4 | 10.1, 10.2, 10.3, 10.6 |
安全原则：确保日志记录和监视范围包括 DevOps 中使用的非生产环境和 CI/CD 工作流元素（以及任何其他开发过程）。 如果针对这些环境的漏洞和威胁未正确监视，可能会给生产环境带来重大风险。 还应监视 CI/CD 生成、测试和部署工作流中的事件，以识别 CI/CD 工作流作业中的任何偏差。
Azure 指南：在在整个 DevOps 过程中使用的非生产环境和 CI/CD 工具环境（例如 Azure DevOps 和 GitHub）中启用和配置审核日志记录功能。
还应监视从 Azure DevOps 和 GitHub CI/CD 工作流（包括生成、测试和部署作业）生成的事件，以识别任何异常结果。
通过日志记录流或 API 将上述日志和事件引入 Microsoft Sentinel 或其他 SIEM 工具，以确保正确监视并会审安全事件进行处理。
Azure 实现和其他上下文：
AWS 指南：在 DevOps 过程中，针对非生产环境和 CI/CD 工具环境（如 AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy、AWS CodeStar），启用并配置 AWS CloudTrail 以实现审核日志记录功能。
还应监视从 AWS CI/CD 环境（如 AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy、AWS CodeStar）和 GitHub CI/CD 工作流（包括生成、测试和部署作业）生成的事件，以识别任何异常结果。
通过日志记录流或 API 将上述日志和事件引入 AWS CloudWatch，Microsoft Sentinel 或其他 SIEM 工具，以确保正确监视并会审安全事件进行处理。
AWS 实现和其他上下文：
GCP 指南：在非生产和 CI/CD 工具环境中为云生成、Google Cloud 部署、项目注册表和 GitHub 等产品启用和配置审核日志记录功能，可在 DevOps 过程中使用。
还应监视从 GCP CI/CD 环境（如云生成、Google Cloud 部署、项目注册表）和 GitHub CI/CD 工作流（包括生成、测试和部署作业）生成的事件，以识别任何异常结果。
通过日志记录流或 API 将上述日志和事件引入 Microsoft Sentinel、Google Cloud Security Command Center、Chronicle 或其他 SIEM 工具，以确保正确监视并会审安全事件进行处理。
GCP 实现和其他上下文：
客户安全利益干系人（了解详细信息）：