你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

DevSecOps 控件

DevSecOps 通过将安全过程和工具集成到 DevOps 开发过程中来应用创新安全性。

由于 DevOps 本身是一项新兴规则，具有高度的过程变体，因此要成功实现 DevSecOps，最好深入了解并将安全性精心集成到开发过程中。 添加安全性应从代码、开发过程和托管工作负荷的基础结构的低冲突性变更开始。 首先关注对安全性影响最大、最积极的更改，同时减轻对 DevOps 过程和技能的负担。

本文档介绍持续集成和持续交付 (CI/CD) DevOps 过程的每个阶段，以及建议的首先集成的安全控制。

计划和开发

通常，新式开发遵循敏捷开发方法。 Scrum 是敏捷方法的一种实现，让每个冲刺 (sprint) 从计划活动开始。 在开发过程的这一部分引入安全性应侧重于：

• 威胁建模，通过潜在攻击者的视角查看应用程序
• IDE 安全插件和预提交挂钩，用于集成开发环境 (IDE) 中的轻型静态分析检查。
• 同级评审和安全编码标准，以确定有效的安全编码标准、同级评审过程和预提交挂钩。

无需添加所有这些步骤。 但每一步都有助于及早发现安全问题，因为这些步骤的成本更低且更容易修复。

威胁建模

威胁建模可能是最重要的安全做法。 它提供了立竿见影的效果，并有助于在开发人员中建立安全意识，以提高他们未来所有项目的安全性。

威胁建模是一个简单的概念，但如果需要的话，它可以十分详尽且具有技术含量。 威胁建模揭示并记录应用程序的真实安全视图，其中包括：

• 攻击者如何滥用应用程序设计
• 如何修复漏洞
• 修复问题有多重要

威胁建模有效地将你置于攻击者的思维模式。 这使你可以通过攻击者的眼睛查看应用程序。 你将学习如何在攻击者对其采取任何行动之前阻止尝试。 如果团队在设计时使用用户角色，可以将攻击者视为恶意用户角色。

有若干已发布的威胁建模方法，包括简单的问答方法和基于工具的详细分析。 可以将方法基于 STRIDE 模型或 OWASP 威胁建模等方法。

威胁建模：从简单入手

由于某些威胁建模方法可能很耗时且需要大量技能，因此我们建议使用基本问题通过更简单的方法开始。 更简单的方法并不全面，但可以启动关键思维过程并帮助快速识别主要安全问题。

下面的简单问题方法将帮助你入门：

• Microsoft 的简单问题方法：此方法要求应对常见安全设计错误的特定技术问题。
• OWASP 威胁建模：此方法侧重于提出简单的非技术问题，以启动威胁建模过程。

可以使用其中一种或两种方法，具体取决于哪种方法对团队更有效。

你的团队对该过程更加熟悉后，可以应用 Microsoft 安全开发生命周期中的更高级技术。 他们可以集成威胁建模工具，如 Microsoft 威胁建模工具，以获得更深入的洞察力并帮助自动化流程。

另一个有用的资源是面向开发人员的威胁建模指南。

IDE 安全插件和预提交挂钩

开发人员专注于交付速度，而安全控制可能会减慢该过程。 通常，如果安全检查从管道开始，则速度会变慢。 开发人员会在将代码推送到存储库后发现潜在的漏洞。 若要加快此过程并立即提供反馈，需要添加 IDE 安全插件和预提交挂钩等步骤。

集成开发环境 (IDE) 安全插件在开发者熟悉的 IDE 环境中识别开发过程中的不同安全问题。 如果开发人员编写的代码中存在潜在的安全风险，插件可以提供即时反馈。 插件还可以揭示第三方库或包中的风险。 根据你选择的 IDE，安全公司可以使用和提供许多开源或商业插件。

另一个要考虑的选项是使用预提交框架，但前提是版本控制系统允许。 预提交框架提供了 Git 挂钩脚本，可帮助在开发人员提交代码进行代码审查之前识别问题。 一个示例是你可以在 GitHub 中设置的预提交。

同级评审和安全编码标准

拉取请求是开发过程中的标准步骤。 拉取请求过程的一部分是同级评审，同级评审通常会揭示未发现的缺陷、bug 或与人为错误相关的问题。 创建拉取请求之前，最好有一位安全支持者或经验丰富的安全团队成员，他们可以在创建拉取请求之前的同级评审过程中指导开发人员。

安全编码做法指南可帮助开发人员了解基本的安全编码原则及其应用方式。 存在安全编码做法（例如 OWASP 安全编码做法），这些做法可以与一般编码做法合并在一起。

提交代码

通常，开发人员在存储库（如 GitHub 或 Azure 存储库）中创建、管理和共享其代码。 这种方法提供了一个中央的、版本控制的代码库，供开发人员轻松协作。 但是，在单个代码库上启用多个协作者也可能会引入更改的风险。 这种风险可能导致漏洞或无意中在提交中包含凭据或令牌。

为了应对此风险，开发团队应评估和实现存储库扫描功能。 存储库扫描工具对存储库中的源代码执行静态代码分析。 这些工具会查找漏洞或凭据更改，并标记找到的任何项目以进行修复。 此功能可以防范人为错误，对于许多人员在同一存储库中协作的分布式团队来说，此保护措施非常有用。

依赖项管理

当前应用程序中高达 90% 的代码包含或基于外部包和库的元素。 在源代码中采用依赖项后，必须解决潜在风险。 许多第三方库都有严重的安全问题。 此外，开发人员不会始终遵循最佳生命周期并保持依赖关系最新。

确保开发团队知道要包含在其应用程序中的组件。 他们希望从已知源下载安全且最新的版本。 他们希望有一个使版本保持最新的过程。 你的团队可以使用 OWASP Dependency-Check 项目、WhiteSource 等工具。

只关注依赖漏洞或其生命周期是不够的。 处理包源安全性也很重要。 以包管理系统为目标的已知攻击途径包括：拼写错误、破坏现有包、替换攻击等。 因此，负责任的包管理必须解决这些风险。 有关详细信息，请参阅在使用专用包源时降低风险的三种方法。

静态应用程序安全测试

团队解决第三方库和包管理问题后，必须转移焦点并提高代码安全性。 有不同的方法可以提高代码的安全性。 可以使用 IDE 安全插件。也可以像之前讨论的那样将增量静态分析预提交和提交检查连接在一起。 也可以进行完整的源代码扫描，以捕捉前面步骤遗漏的错误。 这很有必要，但可能需要数小时或数日才能在大型代码块上运行。 因此，此方法可能会减慢开发速度并造成负担。

但是在实施静态代码扫描实践时，团队必须从某个地方开始。 一种方式是在持续集成中引入静态代码分析。 此方法在代码发生更改后立即验证安全性。 一个示例是 SonarCloud。 它使用适用于不同语言的多个静态应用程序安全性测试 (SAST) 工具。 SonarCloud 评估和跟踪技术债务，重点是可维护性。 该工具着眼于代码质量和风格，并具有特定于安全性的检查器。 但是市场上还有许多其他商业和开源工具。

为确保反馈循环有效，调整工具至关重要。 你希望尽量减少误报，并提供有关问题要修复的清晰、可操作的反馈。 此外，最好实现工作流，这样可以防止代码在发现错误时提交到默认分支。 你需要同时涵盖质量和安全发现。 这样，安全性将成为单元测试体验的一部分。

安全管道

DevOps 将自动化提升到另一个级别，因为开发生命周期中的所有内容都经过管道。 持续集成和持续交付 (CI/CD) 是现代开发周期的关键部分。 在 CI/CD 中，你的团队会定期将开发人员代码合并到一个中央代码库中，并自动运行标准构建和测试流程。

基础设施管道是开发的核心部分。 但是使用管道运行脚本或将代码部署到生产环境可能会带来独一无二的安全挑战。 你希望确保 CI/CD 管道不会成为运行恶意代码、允许凭据被盗或向攻击者提供任何外围访问的途径。 你还希望确保团队只打算发布然后部署的代码。

DevOps 团队必须确保他们为管道实施适当的安全控制。 关于如何应对这些风险，根据所选的平台有不同的准则。 有关详细信息，请参阅保护 Azure Pipelines。

生成和测试

许多组织使用生成和发布管道来自动化和标准化生成和部署代码的过程。 发布管道让开发团队可以快速、大规模地对代码部分进行迭代更改。 团队无需花费大量时间重新部署或升级现有环境。

使用发布管道还使团队能够从开发环境、测试环境并最终将代码推广到生产环境。 作为此自动化的一部分，开发团队应包括在将代码部署到测试环境时运行脚本化自动测试的安全工具。 测试应包括应用程序功能的单元测试，以检查漏洞或公共终结点。 测试确保有意访问。

动态应用程序安全性测试

在传统瀑布式开发模型中，安全性通常在最后一步引入，然后才进入生产环境。 最常用的安全方法之一是渗透测试。 渗透测试让团队可以从黑盒安全的角度来看待应用程序，就像最接近攻击者的心态一样。

渗透测试由多个操作点组成，其中之一是动态应用程序安全性测试 (DAST)。 DAST 是一种 Web 应用程序安全测试，它通过查看应用程序如何响应专门创建的请求来查找正在运行的应用程序中的安全问题。 DAST 工具也称为 Web 应用程序漏洞扫描程序。 一个例子是开源工具 OWASP Zed Attack Proxy (ZAP)。 该工具查找正在运行的 Web 应用程序中的漏洞。 OWASP ZAP 有不同的扫描方式：被动基线扫描或完全扫描，具体取决于配置。

渗透测试的缺点是需要时间。 彻底的渗透测试可能需要长达数周的时间，而且随着 DevOps 开发的速度，这个时间框架可能是不可持续的。 但仍然值得在开发过程中添加更轻量级的渗透测试，以发现 SAST 和其他步骤遗漏的问题。 像 OWASP ZAP 这样的 DAST 工具可以提供帮助。

开发人员将 OWASP ZAP 作为任务集成到管道中。 在运行期间，OWASP ZAP 扫描器在容器中启动并进行扫描，然后发布结果。 这种方法可能并不完美，因为它不是完整的渗透测试，但它仍然很有价值。 这是开发周期中用于改善安全状况的又一质量措施。

云配置验证和基础结构扫描

除了扫描和保护应用程序的代码外，还要确保你部署应用程序的环境也是安全的。 对于希望快速发展、创新和使用新技术的组织而言，安全环境至关重要。 安全环境还可以帮助团队快速创建新的实验环境。

Azure 功能允许组织从环境中创建安全标准，例如 Azure Policy。 团队可以使用 Azure Policy 创建策略集。 策略集阻止创建某些工作负载类型或配置项，例如公共 IP 地址。 这些防护措施可让团队在安全且受控的环境中进行试验，并平衡创新和治理。

DevOps 可以使开发人员和操作彼此同步的方法之一是支持将现有基础架构转换为基础架构即代码方法。

基础结构即代码 (IaC) 是在描述性模型中管理基础结构（网络、虚拟机、负载均衡器和连接拓扑）。 IaC 使用与 DevOps 团队用于源代码的相同版本控制模型。 与相同源代码生成相同二进制文件的原则相似，每次应用 IaC 模型时都会生成相同的环境。 IaC 是用于 持续交付的关键 DevOps 做法。

DevSecOps 将安全性向左转移，并表明安全性不仅与应用程序安全有关，还与基础设施安全有关。 DevSecOps 支持基础架构安全的方法之一是在基础架构部署到云之前包括安全扫描。 随着基础设施成为代码，你随后将与应用程序安全性相同的安全操作应用于基础设施。 有一些安全工具可用于根据你选择的 IaC 策略运行基础设施安全扫描。

随着云的采用，容器化是团队在应用程序架构决策中采用的一种流行方法。 某些容器存储库扫描映像以捕获具有已知漏洞的包。 容器包含过期软件仍然存在风险。 由于存在此种风险，因此扫描容器是否存在安全风险至关重要。 有大量针对该领域的开源和商业安全工具，并支持在 CD 流程中的紧密集成。 这些安全工具可帮助团队将 DevSecOps 用于基础设施即代码，并更具体地了解如何使用容器。

转到生产环境并进行操作

当解决方案投入生产时，继续监督和管理安全状态至关重要。 在流程的这个阶段，应该关注云基础设施和整体应用。

配置和基础结构扫描

若要获取跨多个订阅的云订阅和资源配置的可见性，可以使用 AzSK 团队的 Azure 租户安全解决方案。

Azure 包括监视和安全功能。 这些功能可检测并警告任何需要调查和潜在补救的异常事件或配置。 Microsoft Defender for Cloud 和 Microsoft Sentinel 等技术是本机集成到 Azure 环境中的第一方工具。 这些技术补充了环境和代码安全工具。 这些技术提供了全面的安全监控，因此组织可以快速、安全地进行试验和创新。

渗透测试

建议采用渗透测试来检查基础结构或应用程序配置中是否存在任何会被攻击者利用的弱点的漏洞。

许多产品和合作伙伴提供渗透测试服务。 Microsoft 提供有关 Azure 中的渗透测试的指导。

典型测试涵盖以下测试类型：

• 对终结点进行测试以发现漏洞
• 对终结点进行模糊测试（通过提供格式错误的输入数据来查找程序错误）
• 终结点的端口扫描

可操作智能

本指南中的工具和技术可以为组织提供一个整体安全模型，帮助其同步发展并试验推动创新的新技术。 DevSecOps 的一个关键要素是数据驱动、事件驱动的流程。 这些流程帮助团队识别、评估和应对潜在风险。 许多组织选择将警报和使用数据集成到其 IT 服务管理 (ITSM) 平台中。 然后，团队可以将相同的结构化工作流程用于他们用于其他事件和请求的安全事件。

反馈循环

以上技术和工具使团队能够查找和标记需要调查和潜在解决的风险和漏洞。 如果运营团队在调查支持票证时收到警报或发现潜在问题，则需要返回开发团队的路由来标记要评审的项目。 顺畅的协作反馈循环对于快速解决问题并尽可能降低漏洞风险至关重要。

反馈的常见模式是将其集成到开发人员工作管理系统中，例如 Azure DevOps 或 GitHub。 组织可以将警报或事件链接到工作项，以供开发人员计划和采取行动。 此过程为开发人员解决其标准工作流中的问题提供了一种有效方式，包括开发、测试和发布。