通过

DevOps 安全性

DevOps 安全性将整个软件开发生命周期（SDLC）的安全做法集成，从初始设计和编码到生成、测试和部署到生产环境。 与传统将安全视为最终关口的方法不同，DevOps 安全将安全控制、自动化测试和持续监控嵌入到开发管道的每个阶段。 此方法认识到，新式软件交付依赖于复杂的 CI/CD 管道、第三方依赖项、基础结构即代码和自动化部署，每个部署都引入了攻击者主动利用的潜在攻击途径。 通过应用零信任原则（假设违规、显式验证）和深层防御策略，DevOps 安全性可确保代码、依赖项、基础结构配置和管道进程在设计过程中通过生产保持可信和防篡改。 如果没有全面的 DevOps 安全性，组织将面临严重风险，包括供应链攻击、管道中的凭据泄露、恶意代码注入、易受攻击的容器映像和未经授权的基础结构更改，这些更改可以建立影响所有下游使用者的持续后门。

下面是 DevOps Security 安全域的三大核心支柱。

保护设计和供应链： 尽早执行结构化威胁建模。 使用依赖项和许可证扫描、漏洞管理和 SBOM 生成来保护供应链。 验证所有组件的出处和完整性。

相关控件：

向安全控件左移： 通过将 SAST、机密扫描、IaC 扫描和 DAST 集成到 CI/CD 管道中，Shift 离开安全控制。 集中机密管理（例如 Key Vault），限制管道更改机构，并在部署前持续扫描和保护项目（如容器和 VM 映像）。

相关控件：

监视和审核 DevOps 活动： 收集 DevOps 审核和安全日志并将其转发到中心分析平台，以便进行关联和响应。 检测未经授权的管道更改、特权升级、异常提交和非工作时间执行。

相关控件：

DS-1：进行威胁建模

安全原则

在设计阶段使用 STRIDE 方法实施系统威胁建模，以确定潜在的安全威胁、确定风险的优先级，并在代码开发开始之前实施适当的缓解措施。 这种左移策略可降低修正成本，并提高整体安全防御能力。

待缓解风险

在设计阶段未能进行威胁建模的组织存在关键盲点，容易被对手系统地利用。 没有系统的威胁分析：

  • 后期体系结构缺陷： 嵌入式设计漏洞需要在生产环境中进行昂贵的重构，修正成本明显高于在设计阶段解决问题。
  • 身份不明的攻击面： 威胁向量（如不安全的信任边界、缺少身份验证要求或数据流保护不足）仍不受记录，使攻击者能够利用防御者无法识别的已知弱点。
  • 安全控制不足： 由于威胁分析不完整，安全控制（加密、身份验证、授权、审核日志记录）缺失或不足，从而在深层防御策略中造成了可利用的差距。
  • 合规性盲点： 在没有记录的威胁模型和缓解证据的情况下，无法满足监管要求（PCI-DSS、HIPAA、SOX）要求安全设计验证。
  • 安全债务积累： 没有威胁建模的持续功能添加会加剧安全技术债务，使系统逐渐更加脆弱，难以追溯保护。

缺乏威胁建模会增加数据泄露的可能性，延长滞留时间，并导致更高的整改成本，而不是在设计阶段的早期进行缓解。

MITRE ATT&CK

  • 初始访问（TA0001）：通过利用面向公众的应用程序（T1190），利用在身份验证、会话管理或输入验证中的架构缺陷，这些问题可通过威胁建模来识别。
  • 特权提升（TA0004）：滥用提升控制机制（T1548）利用权限分离不足或系统体系结构中缺少授权检查。
  • 防御逃避（TA0005）：损害防御（T1562）利用缺失的审计日志、监控漏洞或系统设计中缺乏安全遥测。

DS-1.1：实现基于 STRIDE 的威胁建模

设计阶段的系统威胁建模为安全软件体系结构提供了基础，方法是在开发开始之前识别漏洞。 在设计阶段解决安全问题可大幅降低修正成本，并防止体系结构缺陷嵌入生产系统中。 早期威胁识别可确保安全控制内置于体系结构中，而不是稍后进行改造。

实现以下结构化方法来建立威胁建模：

  • 建立系统 STRIDE 方法： 使用 STRIDE 方法（欺骗、篡改、否认、信息泄露、拒绝服务、特权提升）建立系统威胁建模作为强制性的设计阶段活动。 首先创建映射系统组件、数据流、信任边界和外部依赖项的数据流关系图（DFD）。 对于每个组件和数据流，系统地评估所有六个 STRIDE 类别的潜在威胁，根据可能性和影响确定风险的优先级，并在开发开始之前记录特定的缓解措施。

  • 使用结构化威胁建模工具： 使用结构化威胁建模工具（如 Microsoft威胁建模工具 ）来保持一致性，并利用预构建的模板实现常见体系结构模式（Web 应用程序、API、微服务、IoT 解决方案）。 该工具有助于创建 DFD、基于组件类型和数据流的自动威胁识别，并生成具有关联安全控制措施的可作缓解建议。 将威胁模型作为版本化工件，与架构文档一起存储在源代码管理中。

  • 集成到开发工作流中： 通过将识别的威胁导出到 Azure DevOps 的工作项中，将威胁建模输出直接集成到开发工作流中，并明确所有权、优先级和验收标准。 在设计批准之前实现需要已完成威胁模型的体系结构评审入口，并建立拉取请求检查，以在检测到体系结构更改时触发威胁模型评审。 这可确保威胁分析在整个开发生命周期内与系统演变保持同步。

DS-1.2：自动化威胁分析集成

跨大型组织缩放威胁建模需要自动化和分布式功能，以防止安全评审成为开发瓶颈。 项目启动和拉取请求流程中嵌入的自动化威胁识别工作流可确保安全分析一致，而无需对每个项目进行手动干预。 通过启用计划在开发团队中构建安全专业知识可创建可持续的可缩放威胁建模做法。

实现这些自动化和启用功能：

  • 通过自动化和能力提升进行扩展： 通过自动化和能力提升在整个组织中扩展威胁模型。 在项目初始模板中嵌入安全问卷，这些模板可自动评估风险级别、确定威胁建模要求，并根据数据分类、外部暴露和监管范围分配适当的安全评审检查点。 自动化拉取请求工作流中的架构评审触发机制，当检测到系统边界、身份验证流程或数据处理逻辑的更改时，将这些更改路由给安全架构师进行威胁模型验证。

  • 使用安全支持者构建分布式功能： 建立安全支持者计划，在开发团队中构建分布式威胁建模功能。 训练 STRIDE 方法的支持者，为他们提供威胁建模工具和模板，并使他们能够为团队提供威胁建模会话。 安全倡导者充当第一道审查防线，将复杂情况上报给集中式安全团队，同时确保大多数威胁建模流程顺畅。

自动威胁分析实现：

  • 基于问卷的评估： 集成到 Azure DevOps 模板中的标准化安全问卷，以便进行一致的威胁识别
  • 安全冠军计划： 每个开发团队中经过威胁建模协作培训的指定安全冠军
  • 体系结构评审自动化： 在拉取请求中自动检查更新的体系结构关系图是否需要威胁模型评审
  • 威胁模型作为代码： 使用结构化格式（JSON/YAML）实现自动分析的版本控制威胁模型定义

实现示例

当攻击者利用开发期间从未识别的付款 API 中的授权缺陷，导致重大欺诈交易和监管罚款时，金融服务组织遭受了数据泄露。

挑战： 部署了大量 API 的微服务体系结构，无需进行安全审查。 开发团队缺乏识别威胁的安全专业知识。 仅在生产事故发生后才发现架构安全问题。

解决方案方法：

  • STRIDE 威胁建模： 使用数据流关系图为所有微服务和 API 终结点实现 Microsoft威胁建模工具 ，其中显示了体系结构和敏感数据流。
  • 安全支持者计划： 每个开发团队中经过训练的威胁建模促进者可实现安全设计，而不会造成中心安全团队的瓶颈。
  • 自动化工作流集成： 将威胁模型评审集成到 Azure DevOps 拉取请求工作流中，需要对体系结构更改进行安全审批。

结果： 在部署前发现了许多阻止潜在违规的安全问题。 大幅减少生产中的安全漏洞。 安全评审为开发周期增添了最短的时间。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： SA-11、SA-15、PL-8、RA-3、RA-5
  • PCI-DSS v4： 6.3.1、6.3.2、12.3.1
  • CIS 控件 v8.1： 14.2、14.3
  • NIST CSF v2.0： ID.RA-3，PR.IP-2
  • ISO 27001：2022： A.5.12、A.8.25
  • SOC 2： CC3.2、CC7.1

DS-2：保护软件供应链

安全原则

通过在集成之前验证所有第三方组件的来源、完整性和安全状况，实现对依赖项的零信任。 持续扫描依赖项是否存在漏洞，维护全面的软件材料清单（SBOM），并强制实施自动化安全更新，以最大程度地减少供应链攻击面。

待缓解风险

软件供应链攻击构成严重威胁，因为攻击者利用组织与第三方组件之间的信任关系，以最少的努力实现广泛的影响。 没有全面的供应链安全性：

  • 恶意依赖项： 攻击者将后门注入常用的开源库（SolarWinds 样式攻击），或创建在安装或运行时执行恶意代码的拼写错误包。
  • 易受攻击的第三方库： 依赖项中的已知 CVE（Log4Shell、Heartbleed、Struts 漏洞）由于缺乏可见性和自动漏洞管理，数周或几个月内仍未修补。
  • 已被篡改的构建工件：攻击者在存储或传输过程中篡改已编译的二进制文件、容器镜像或部署包，并注入能够绕过源代码审查的恶意软件。
  • 依赖项混淆攻击： 恶意参与者将包上传到与内部专用包匹配的名称的公共存储库，利用包管理器解析逻辑替换恶意代码。
  • 可传递依赖项风险： 间接依赖项（依赖项依赖项）中的漏洞仍然不可见，而无需进行深层依赖项树分析和 SBOM 生成。
  • 缺乏证明验证： 缺少加密验证可对合法包进行替换攻击，其中合法包被恶意版本替换。

供应链漏洞带来广泛影响、置入持久后门，并由于合法外观而具有高隐蔽性。

MITRE ATT&CK

  • 初始访问（TA0001）：供应链攻击（T1195.001），通过破坏软件依赖项和开发工具以实现初步入侵，并且利用组织和第三方软件供应商之间的信任关系（T1199）来提供恶意更新。
  • 执行（TA0002）：执行命令和脚本解释器（T1059），执行嵌入在依赖项安装脚本或安装后挂钩中的恶意代码。
  • 持久性（TA0003）：使用后门入侵客户端软件二进制文件（T1554），将其嵌入编译库中，能够在应用程序更新后继续发挥作用。

DS-2.1：实现依赖项扫描和管理

全面的依赖项安全管理通过保持对所有第三方组件的可见性、持续监视漏洞以及自动执行修正过程来防止供应链攻击。 新式应用程序依赖于数百或数千个依赖项（直接和可传递），使得手动安全评估是不可能的，并通过易受攻击的库创建广泛的攻击面。 使用持续监视进行自动依赖项扫描可确保组织在利用之前检测和修正漏洞。

通过以下核心功能建立持续依赖项安全性：

  • 建立全面的可见性和 SBOM 生成： 使用三个核心功能建立持续依赖项安全管理：全面可见性、自动漏洞检测和主动修正。 首先生成完整的依赖项清单，用于映射所有存储库中的直接依赖项（在包清单中显式声明）和可传递依赖项（依赖项）。 以行业标准格式（SPDX、CycloneDX）维护软件材料清单（SBOM），以确保符合法规要求和事件响应准备。

  • 实现自动漏洞扫描和修正： 实施自动漏洞扫描，持续监视针对国家漏洞数据库（NVD）、GitHub 顾问数据库和特定于语言的安全公告的依赖项。 当新的公共漏洞和暴露 (CVE) 被披露并影响您的依赖项堆栈时，配置实时警报，并根据严重性将通知分派到相应的团队。 启用使用依赖项版本升级生成拉取请求的自动化安全更新功能，包括兼容性测试和智能合并冲突解决，以减少手动修正负担。

  • 将安全验证集成到开发工作流中：通过拉取请求审查将依赖项安全验证直接集成到开发工作流中，这些审查会自动评估依赖项变更对安全的影响，并标记具有已知漏洞的新依赖项、许可证合规性问题或可疑特征（如拼写错误、维护者信誉不足）。 建立高风险依赖项更改的审批入口，并强制实施禁止具有严重漏洞的依赖项合并到受保护分支的策略。

  • 将可见性扩展到生产环境： 使用 Microsoft Defender for Cloud DevOps Security 等工具将代码依赖项与正在运行的工作负载关联，通过依赖项链识别攻击路径，并根据实际生产暴露（而不是理论风险）确定修正优先级，从而将可见性扩展到已部署的环境之外。 GitHub 高级安全性等工具提供全面的依赖项图可视化、Dependabot 驱动的自动更新和对专有包生态系统的自定义漏洞模式支持。

实现示例

医疗保健组织在生产应用程序中发现了恶意 npm 包，这些包会泄露患者数据数月。 调查显示，大量易受攻击的依赖项中存在已知的 CVE 漏洞，包括关键性的 Log4Shell 漏洞。

挑战： 数百个存储库中的数千个依赖项，无法查看漏洞或恶意包。 手动依赖性审核每个应用耗费数周时间。 监管审核确定了关键的供应链差距。

解决方案方法：

结果： 快速检测到并修正了大量易受攻击的依赖项。 通过自动验证防止多个恶意包事件。 实现了全面的SBOM文档合规。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： SR-3、SR-4、SR-6、SA-12、SA-15（9）、RA-5
  • PCI-DSS v4： 6.2.4、6.3.2、6.3.3
  • CIS 控件 v8.1： 16.1、16.2、16.11
  • NIST CSF v2.0： ID.SC-2、ID.SC-4、DE。CM-8
  • ISO 27001：2022： A.5.19、A.5.22、A.5.23
  • SOC 2： CC3.2、CC8.1

DS-3：保护 DevOps 基础结构

安全原则

通过全面的机密管理、带审批步骤的管道访问控制措施、安全构建代理配置和持续监视，深入实施构建基础架构的防御。 消除硬编码凭据并强制实施最低特权访问，以保护软件开发和部署过程的完整性。

待缓解风险

不安全的 DevOps 基础结构会创建严重漏洞，攻击者利用这些漏洞来破坏整个软件交付链。 没有全面的基础设施安全性：

  • 已泄露的 CI/CD 管道： 攻击者可以通过被盗凭据、漏洞或内部访问来获取构建管道的访问权限，从而启用影响所有下游使用者的代码注入、工件篡改或部署操作。
  • 生成日志和项目中公开的机密： 硬编码的凭据、API 密钥、证书和连接字符串通过管道日志、错误消息或已编译的项目泄露，使攻击者能够直接访问生产环境。
  • 未经授权的管道修改： 缺少更改控制和审批工作流允许恶意参与者修改管道定义、注入恶意生成步骤或更改部署配置，而无需检测。
  • 访问控制不足： 过度宽松的角色分配和职责分离不足导致 DevOps 基础设施内出现横向移动、特权升级和持久访问建立的风险。
  • 不安全的构建代理： 未修补、配置错误或受损的构建代理为攻击者提供了对构建环境和潜在进入点的持续访问。
  • 缺少审核线索： DevOps 活动的日志记录和监视不足可防止检测未经授权的访问、可疑修改或内部威胁。

基础结构泄露允许攻击者在源处注入代码，绕过受信任的管道，并影响每个下游应用程序。

MITRE ATT&CK

  • 初始访问（TA0001）：使用被盗凭据或服务主体机密访问 DevOps 平台和管道的有效帐户（T1078）。
  • 持久性（TA0003）：帐户操作（T1098）创建后门服务主体、个人访问令牌或 SSH 密钥以确保持续访问。
  • 凭据访问（TA0006）：从管道日志、环境变量或配置文件中获取机密的不安全凭据（T1552.001）。
  • 防御逃避（TA0005）：削弱防御（T1562），禁用管道定义中的安全扫描步骤、审核日志记录或审批关卡。

DS-3.1：为管道实现机密管理

集中机密管理通过从代码、配置文件和管道定义中删除硬编码的机密，消除了 DevOps 管道中的凭据公开。 管道 YAML、环境变量或源存储库中嵌入的凭据表示管道泄露的主要攻击途径，使有权访问存储库或日志的攻击者能够提取生产凭据。 使用动态检索和实时访问模式实现加密保护的机密存储可防止凭据被盗，同时保持作效率。

使用以下安全控制配置机密管理：

  • 利用集中存储消除硬编码凭据： 通过将所有机密集中存储在多层加密访问控制和全面审计追踪的专用机密管理基础设施中，从而消除管道定义和源代码中的硬编码凭据。 建立一个原则，即不得将机密存储在管道 YAML 文件中、日志中可见的环境变量或存储库中的配置文件中，这些是 DevOps 环境中凭据公开的主要途径。

  • 使用托管标识配置动态机密检索： 使用 Azure Key Vault 等解决方案实现集中式机密存储，这些解决方案提供加密机密存储、精细访问策略、自动机密轮换和全面的审核日志记录。 配置管道以通过安全服务连接在运行时动态检索机密，而不是将其嵌入管道定义中。 使用托管标识或工作负荷标识联合身份验证对机密存储的管道访问进行身份验证，从而不需要自己成为盗窃目标的长期服务主体凭据。

  • 强制实施带有审批门禁的及时访问： 强制实施仅在需要时检索机密的及时机密访问模式，并在管道完成后自动撤销，以最大程度地减少凭据的泄露风险。 实施限时访问限制，并要求多人授权（审批入口）才能访问生产机密，确保没有单个泄露的帐户可以访问敏感凭据，而无需进行额外的验证。

  • 建立分层基础结构访问控制： 为 DevOps 基础结构建立分层访问控制：将管道修改权限限制为安全评审的人员，强制实施需要批准生产部署的环境特定权限，实施存储库级服务连接限制，防止管道在预期范围内访问机密，并为敏感工作负荷部署具有网络隔离的强化自承载生成代理。 将基础结构即代码安全扫描集成到管道中，以防止部署配置不当的资源，这些资源可能会公开机密或创建未经授权的访问路径。

实现示例

当攻击者使用管道日志中发现的被盗服务主体凭据来访问生产数据库时，零售组织遭到了破坏，暴露了数百万条客户记录。

挑战： 管道变量中硬编码的数据库连接字符串和 API 密钥。 过度宽松的管道权限允许任何开发人员部署到生产环境。 生成代理泄露提供了对基础结构的持久访问。

解决方案方法：

  • 集中式机密管理： 实现了 Azure Key Vault 集成，消除了管道中的硬编码机密。 配置的托管标识身份验证消除了凭据泄露风险。
  • 管道访问控制： 使用需要安全团队批准才能进行生产部署的 Azure DevOps 环境 建立审批入口和环境特定的权限。
  • 强化的生成代理： 部署的自托管代理具有安全强化和网络隔离，用于处理受管制数据的敏感工作负载。
  • 基础结构安全扫描： ARM 模板和 Terraform 配置的集成安全验证可防止配置错误部署。

结果： 从管道日志中消除机密，防止凭据被盗。 消除了未经授权的生产部署。 在部署之前检测到并阻止了基础结构配置错误。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-3、AC-6、SC-12、SC-13、AU-2、AU-6
  • PCI-DSS v4： 8.3.2、8.6.1、8.6.3、12.3.3
  • CIS 控件 v8.1： 4.1、4.7、6.1、6.5
  • NIST CSF v2.0： PR.AC-4, PR.DS-5, DE.CM-7
  • ISO 27001：2022： A.5.15、A.5.16、A.8.3
  • SOC 2： CC6.1、CC6.6、CC6.7

DS-4：集成静态应用程序安全测试（SAST）

安全原则

通过集成到每个生成过程的多个专用静态应用程序安全测试（SAST）扫描程序实施全面的自动化安全测试。 使用多扫描程序覆盖范围进行全面检测，通过推送保护实现机密扫描，并部署语义代码分析，以在漏洞到达生产环境之前识别和阻止漏洞。

待缓解风险

在开发过程中逃避检测的代码级漏洞会创建攻击者系统利用的持久性安全漏洞。 没有全面的 SAST 集成：

  • 注入漏洞： SQL 注入、跨站点脚本（XSS）、命令注入和 LDAP 注入缺陷使攻击者能够作应用程序逻辑、提取敏感数据或执行任意代码。
  • 硬编码凭据： 开发人员无意中将密码、API 密钥、证书和连接字符串提交到源代码存储库，使攻击者能够直接访问生产系统和数据。
  • 不安全的加密实现： 弱加密算法（DES、MD5）、硬编码的加密密钥、不正确的初始化向量或密钥长度不足会损害数据机密性和完整性。
  • 缓冲区溢出和内存损坏： C/C++ 应用程序中的不安全内存作可实现任意代码执行、特权升级和拒绝服务攻击。
  • 业务逻辑缺陷： 身份验证绕过、授权差距、争用条件和输入验证不足，可提升权限、欺诈和未经授权的访问。
  • 基础设施即代码（IaC）配置错误：不安全的 Terraform、ARM 模板或 Kubernetes 清单部署使基础设施易受攻击，包括权限过于宽松、缺乏加密或管理终端公开。

如果没有自动化 SAST，漏洞会累积成技术债务，延长风险暴露时间，并增加在生产环境下修正的成本。

MITRE ATT&CK

  • 初始访问（TA0001）：利用面向公众的应用程序（T1190），通过应用程序代码中的注入漏洞或身份验证绕过。
  • 执行（TA0002）：利用客户端执行（T1203）攻击客户端漏洞，例如 XSS 或不安全反序列化。
  • 凭据访问（TA0006）：密码存储（T1555）中的凭据，从源代码、配置文件或已编译的二进制文件中提取硬编码凭据。
  • 特权提升（TA0004）：利用缓冲区溢出或内存损坏执行漏洞利用以提升访问权限（T1068）。

DS-4.1：实现多扫描 SAST 管道

集成到每个内部版本中的综合静态应用程序安全测试在到达生产环境之前提供代码级漏洞的早期检测。 新式应用程序使用多种语言、框架和基础结构即代码，要求专用分析器，无需单个扫描程序即可检测所有漏洞类。 将专用工具与自动执行和质量门相结合的多层 SAST 策略可确保全面覆盖，同时在检测到安全问题时提供开发人员即时反馈。

使用以下组件实现自动化安全测试：

  • 实现多层扫描策略： 在代码到达生产环境之前，将自动化静态应用程序安全测试嵌入到每个版本中，以检测漏洞。 实现一个多层 SAST 策略，该策略结合了多个专用扫描程序-没有单个工具可检测所有漏洞类，因此全面覆盖需要特定于语言的分析器（Python、JavaScript、C/C++）、基础结构即代码扫描程序（Terraform、ARM 模板、Kubernetes 清单）、机密检测和语义代码分析，以实现复杂的数据流漏洞。

  • 使用质量门配置自动执行： 配置 SAST 扫描以在每次提交和拉取请求时自动执行，为开发人员提供关于安全问题的即时反馈，同时代码上下文是全新的。 建立基于严重性的质量门，阻止在检测到严重或高严重性漏洞时阻止合并或部署，从而阻止易受攻击的代码通过管道前进。 将扫描程序配置为以标准化格式（SARIF）输出结果，从而支持跨工具进行一致的漏洞跟踪、重复数据删除以及与集中式安全仪表板集成。

  • 使用推送保护部署机密扫描： 使用推送保护实现专用机密扫描，防止开发人员在提交时将凭据、API 密钥、证书或令牌提交到存储库捕获机密，而不是在审核评审几周后发现机密。 支持用于专有身份验证机制的标准机密模式（AWS 密钥、Azure 令牌、数据库连接字符串）和自定义组织特定的模式。 检测到机密时，提供即时修正指南，包括凭据轮换过程和安全替代方法。

  • 对复杂漏洞使用语义代码分析： 部署语义代码分析工具（如 GitHub CodeQL ），用于执行深度数据流分析，以识别模式匹配扫描程序不可见的复杂漏洞，例如通过多个函数调用、业务逻辑中的身份验证绕过身份验证或不安全的反序列化链。 创建量身定制的安全查询，以适应您组织的框架、满足安全要求，并识别事件回顾中常见的漏洞模式。 通过具有特定行号、漏洞说明和修正建议的拉取请求注释，将 SAST 发现直接集成到开发人员工作流中。

  • 使用统一平台进行协调： 统一 SAST 平台 （如Microsoft安全 DevOps 扩展 ）可以通过单个管道任务协调多个专用扫描程序（AntiMalware、Bandit、BinSkim、Checkov、ESLint、Template Analyzer、Terrascan、Trivy），从而标准化配置管理和跨异类工具生态系统的结果聚合。

实现示例

SaaS 提供程序遭受 SQL 注入攻击，暴露了数十万条客户记录。 事后分析揭示了广泛的代码级漏洞，包括硬编码凭据和数月存在的注入缺陷。

挑战： 手动代码评审只捕获了一小部分漏洞。 开发人员缺乏安全培训来识别注入缺陷和加密弱点。 在生产部署之前，无需自动扫描。

解决方案方法：

  • 多扫描程序 SAST： 使用 CodeQL、ESLint 和 Bandit 部署 Microsoft安全 DevOps 扩展 ，提供跨语言和漏洞类型的全面覆盖。
  • 机密保护： 通过机密扫描和推送保护实现了 GitHub 高级安全性 ，防止提交中的凭据泄露。
  • 语义分析： 为 GitHub CodeQL 配置了针对业务逻辑漏洞和特定于框架的安全模式的自定义查询。
  • 安全门：在Azure Pipelines中已建立的管道安全门阻止具有高严重性发现的部署。

结果： 迅速识别和修正了广泛的漏洞。 防止了关键安全漏洞到达生产环境。 大幅减少安全债务。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： SA-11、RA-5、SI-2
  • PCI-DSS v4： 6.3.2、6.4.1、11.3.1
  • CIS 控件 v8.1： 16.3、16.6
  • NIST CSF v2.0： PR.IP-2、DE.CM-4
  • ISO 27001：2022： A.8.25、A.8.29
  • SOC 2： CC7.1、CC7.2

DS-5：集成动态应用程序安全测试（DAST）

安全原则

通过容器安全扫描容器化工作负载、针对 Web 应用程序和应用程序编程接口（API）的自动渗透测试，以及针对身份验证、授权和会话管理的专用测试，在预生产环境中实施全面的动态安全测试。 运行时验证标识静态分析无法检测到的配置弱点和集成漏洞。

待缓解风险

静态分析无法检测到的运行时的漏洞在应用程序部署后造成了攻击者可利用的关键安全漏洞。 没有全面的 DAST：

  • 部署配置弱点：配置错误的身份验证提供程序、宽松的 CORS、弱 TLS 配置或缺少安全标头 (CSP、HSTS、X-Frame-Options) 可能导致源代码审查无法检测到的攻击。
  • API 安全漏洞： 使用身份验证绕过、授权失败、数据泄露过多、速率限制缺失或不安全的直接对象引用（IDOR）的 REST 和 GraphQL API 允许未经授权的访问和数据提取。
  • 身份验证和授权绕过： 会话管理、密码重置流、多重身份验证实现或基于角色的访问控制逻辑方面的缺陷可实现特权升级和帐户接管。
  • 会话管理漏洞： 可预测会话令牌、超时强制不足、会话固定漏洞或缺少令牌撤销，使会话劫持和凭据被盗。
  • 特定于环境的安全问题： 与数据库、消息队列、外部 API 或第三方服务的集成点引入了在开发或隔离测试中不可见的运行时漏洞。
  • 业务逻辑缺陷： 竞争条件、状态操控漏洞、复杂工作流中的输入验证不足或事务完整性问题，导致欺诈和数据篡改的发生。

DAST 验证运行时行为、环境配置和集成安全，这些是静态分析无法覆盖的。

MITRE ATT&CK

  • 初始访问（TA0001）：通过运行时测试发现的漏洞，在面向公众的应用程序（T1190）中进行身份验证绕过、注入缺陷攻击或利用不安全的 API 终结点。
  • 凭据访问（TA0006）：暴力破解（T1110）利用在 DAST 期间检测到的缺失速率限制、弱密码策略或可预测的会话令牌。
  • 特权提升（TA0004）：有效帐户（T1078）滥用授权绕过或角色操控漏洞，以利用已部署应用程序中的这些弱点。
  • 集合（TA0009）：信息存储库（T1213）中的数据通过 API 响应过多、目录遍历或不安全的直接对象引用漏洞提取敏感数据。
  • 外泄（TA0010）：通过 Web 服务（T1567）外泄利用 API 安全漏洞大规模提取数据，而无需检测。

DS-5.1：在预生产环境中实施自动化 DAST

动态应用程序安全测试验证正在运行的应用程序中的安全控制，发现静态分析无法检测到的运行时漏洞。 虽然SAST检查源代码，但DAST使用类似于生产环境配置的已部署应用程序进行测试，以识别特定于部署的问题，包括身份验证配置错误、授权缺陷以及仅在操作环境中表现的集成安全漏洞。 预生产中的自动化 DAST 可确保在客户公开之前进行安全验证，同时针对集成系统测试实际攻击方案。

通过这些功能实现运行时安全验证：

  • 使用运行时验证补充 SAST： 使用动态应用程序安全测试来补充静态分析，以验证运行具有类似生产配置的应用程序的安全性。 虽然 SAST 识别源代码中的漏洞，但 DAST 发现对静态分析不可见的运行时问题：部署配置弱点（配置不当的身份验证提供程序、宽松的 CORS 策略、缺少安全标头）、特定于环境的集成缺陷（部署上下文中的数据库连接安全性、部署上下文中的 API 授权）以及仅显示在现实作条件下的业务逻辑漏洞。

  • 在类似于生产环境的过渡环境中部署： 在预生产过渡环境中部署 DAST 扫描，以镜像生产体系结构、网络拓扑、外部依赖项和配置参数。 自动化 DAST 执行应在部署到预演环境后触发，系统地测试身份验证流程、授权边界、会话管理、输入验证、API 安全性和错误处理，并在真实负载和使用模式下进行。 这验证与类似生产的外部系统（标识提供者、数据库、消息队列、第三方 API）集成时安全控制是否正常工作。

  • 实现容器的运行时监视： 对于容器化工作负荷，请实施持续运行时安全监视，将部署前映像扫描与部署后行为分析相结合。 在部署之前扫描容器映像中是否存在已知漏洞，然后监视正在运行的容器是否存在异常网络连接、未经授权的进程执行、文件系统修改和特权升级尝试。 建立正常的 Kubernetes 工作负载行为档案，以检测可能指示妥协的偏差，并持续检查和评估容器配置是否符合 CIS 基准标准和安全最佳实践。

  • 专注于高风险攻击面： 专注于高风险攻击面的专用 DAST 工作：REST 和 GraphQL API（测试身份验证绕过、授权失败、注入漏洞、过多数据泄露、不安全直接对象引用）、身份验证和会话管理（验证令牌安全性、超时强制、注销功能、密码重置流、多重身份验证）和业务逻辑工作流（测试争用条件、状态作、事务完整性问题）。 建立 SAST/DAST 相关工作流，将这两种方法的发现相结合，将通过静态和动态分析确认的漏洞确定为最高风险的优先级。

  • 利用集成平台： 对于容器化环境， Microsoft Defender for Containers 在整个容器生命周期内提供集成的运行时漏洞评估、工作负荷分析和威胁检测功能。

实现示例

电子商务组织发现了支付 API 中的身份验证绕过，允许通过未经授权的方式获得折扣。 SAST 错过了运行时配置缺陷，该缺陷仅显示在具有外部身份验证提供程序的已部署环境中。

挑战： SAST 检测到代码漏洞，但错过了运行时配置问题和 API 授权缺陷。 生产部署配置与开发不同，导致对静态分析不可见的安全差距。

解决方案方法：

  • 自动 DAST 扫描： 在预生产环境中部署了 OWASP ZAP ，测试具有类似生产配置的应用程序。
  • 容器运行时保护： 为运行时安全监视和漏洞评估实现了 Microsoft Defender for Containers 。
  • API 安全测试： 在部署的 REST 和 GraphQL 终结点中配置了验证身份验证、授权和数据验证的专用 API 测试。
  • SAST/DAST 关联： 创建了漏洞关联工作流，结合了静态和动态发现，以便进行全面的安全验证。

结果： 发现 SAST 错过的运行时漏洞，包括身份验证绕过和 API 授权缺陷。 通过预生产检测防止安全事件。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： SA-11、CA-8、RA-5
  • PCI-DSS v4： 6.4.2、11.3.2
  • CIS 控件 v8.1： 16.7、16.8
  • NIST CSF v2.0： DE.CM-4, PR.IP-12
  • ISO 27001：2022： A.8.29、A.8.30
  • SOC 2： CC7.1、CC7.3

DS-6：保护工作负荷生命周期

Azure Policy： 请参阅 Azure 内置策略定义：DS-6。

安全原则

通过容器注册表和安全扫描容器工作负载、黄金映像管理和虚拟机（VM）工作负载的自动化构建，以及使用自动隔离进行持续漏洞扫描，实现不可变基础结构，实现全面的映像安全性。 验证加密签名、维护最少的基础映像，并在工作负荷生命周期内强制实施安全基线。

待缓解风险

不安全的工作负荷生命周期管理允许易受攻击或泄露的项目到达生产环境，从而创建攻击者系统利用的持续攻击途径。 缺乏全面的工作负荷安全保障：

  • 易受攻击的生产 VM 映像： 未修补的 OS 基线或配置错误的黄金映像在所有已部署的 VM 中传播弱点。
  • 未修补的易受攻击的基础映像： 基于受 CVE 影响的基础构建的容器使工作负载面临被利用或逃逸的风险。
  • 过时易受攻击的项目： 未扫描的映像和软件包会累积多个 CVE，从而扩展攻击面。
  • 图像验证不足： 缺乏加密签名和证明验证使对手能够将合法映像替换为包含后门或恶意软件的已泄露版本。
  • 扩大的攻击面： 包含不必要的软件包、开发工具或调试实用工具的容器映像会增加漏洞曝光风险，并为攻击者提供额外的攻击工具。
  • 缺少安全基线： 部署的 VM 和容器映像没有 CIS 基准符合性、安全性强化或最小特权配置，在深度防御方面造成了可利用的漏洞。

被入侵的制品会成为持久的攻击途径，促成攻击者横向移动，并让防御者误以为是合法的。

MITRE ATT&CK

  • 初始访问（TA0001）：利用应用程序容器或 Web 服务中未修补的漏洞利用面向公众的应用程序（T1190）。
  • 执行（TA0002）：部署容器（T1610），部署由于映像验证不足而看起来合法的恶意容器。
  • 特权升级（TA0004）：利用容器漏洞逃逸至主机（T1611），打破容器隔离并攻击主机系统。
  • 横向移动（TA0008）：利用远程服务（T1210），跨从受攻击映像部署的易受攻击的 VM 或容器。

DS-6.1：实现容器映像安全性

容器和 VM 映像表示关键攻击面，需要在整个生命周期内进行全面的安全控制。 易受攻击的基础映像将弱点传递到每个已部署的实例，从而扩大了在整个基础架构中的危害。 将工作负载工件与源代码以相同的安全严格性对待，包括进行扫描、签名和安全存储，这可以确保组织仅部署经过验证、可信的映像，同时防止攻击者利用已知漏洞或替换成恶意映像。

通过以下做法保护工作负载工件：

  • 建立不可变基础结构原则： 将容器映像和 VM 映像视为需要与源代码易受攻击的基础映像相同的安全严谨性的关键项目，将弱点传播到每个已部署的实例。 建立不可变的基础结构原则，在其中生成一次工作负荷项目、全面扫描、加密签名并部署，而无需修改，以确保整个生命周期的一致性和可跟踪性。

  • 将最小基础映像与多阶段版本配合使用： 对于容器工作负载，从仅包含基本运行时组件的最小基础映像开始实现分层映像安全性，与完整的作系统映像相比，大幅减少攻击面。 使用多阶段生成将生成时依赖项与运行时映像分开，在功能丰富的映像中编译和生成，然后仅将最终项目复制到最小的运行时映像，消除开发工具、包管理器和生成依赖项，从而增加漏洞暴露，并向攻击者提供利用工具。

  • 将自动扫描与隔离策略集成： 将自动漏洞扫描集成到映像生成管道中，该管道在注册表存储前扫描每个映像、针对全面的 CVE 数据库进行检查，并在披露新漏洞时持续重新扫描存储的映像。 实施自动隔离策略，防止具有关键或高严重性漏洞的映像进行部署。例外流程需经安全团队批准和记录的风险接受。 发布安全修补程序时，使用自动化管道触发器建立基本映像刷新策略，确保映像不会随时间推移累积 CVE。

  • 强制实施加密签名和验证： 在生成时通过加密签名和验证强制实施映像完整性，在部署前验证签名，并自动拒绝未签名或篡改的映像。 这可以防止攻击者使用图像替换攻击，将合法图像替换为含有后门的受损版本。 使用网络访问控制（专用终结点、虚拟网络集成）、基于角色的访问策略（限制谁可以推送/拉取映像）以及所有注册表作的综合审核日志记录，将映像存储在受保护的容器注册表中。

  • 维护 VM 的强化黄金映像： 对于 VM 工作负荷，请使用符合 CIS 基准的强化基础映像来维护集中式黄金映像存储库，这些映像会定期进行安全修补和符合性验证。 实现自动化映像生成管道，其中包含安全更新、删除不必要的服务、强制实施最低特权配置，并按定义的计划生成新映像，而不是修补正在运行的系统。

  • 利用集成安全平台：使用 Microsoft Defender for Containers 集成的 Azure 容器注册表等解决方案提供自动扫描、隔离工作流、内容信任和具有一致安全策略的多区域复制。

实现示例

一个物流组织部署的容器应用程序，其中未修补的基础映像包含关键的远程代码执行漏洞。 攻击者在部署后不久就利用了漏洞，损害了传送数据。

挑战： 许多没有漏洞扫描的容器镜像。 几个月前构建的图像累积了许多 CVE，包括严重漏洞。 缺乏验证，无法阻止恶意图像替换。

解决方案方法：

  • 容器注册表安全性： 在部署之前，通过漏洞扫描隔离具有高严重性 CVE 的映像实现了 Azure 容器注册表 。
  • 强化的 VM 映像： 已部署的 Azure 共享映像库 ，其中包含符合 CIS 基准的 VM 映像，适用于受管制工作负荷。
  • 运行时保护：Microsoft Defender for Containers 配置，用于持续威胁检测和偏移监视。
  • 项目完整性： 建立加密签名和验证，确保整个生命周期内的映像真实性。

结果： 阻止有漏洞的镜像投入生产使用。 大幅减少每个容器映像中的 CVE。 通过签名验证阻止图像替换攻击。

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： CM-2、CM-3、SI-2、SI-7、RA-5
  • PCI-DSS v4： 6.2.4、6.3.3、11.3.1
  • CIS 控件 v8.1： 4.1、7.3、7.4
  • NIST CSF v2.0： PR.IP-1、PR.IP-3、DE.CM-8
  • ISO 27001：2022： A.8.9、A.8.31、A.8.32
  • SOC 2： CC7.2、CC8.1

DS-7：实现 DevOps 日志记录和监控

安全原则

通过审核流实现全面的 DevOps 活动日志记录，并集成到集中式安全信息和事件管理（SIEM）平台，以便进行安全分析、实时威胁检测和自动响应。 建立行为分析、异常检测和安全指标，以实现快速事件响应和维护合规性审核线索。

待缓解风险

DevOps 日志记录和监视不足会创建关键盲点，攻击者利用这些盲点来作未检测到、建立持久性并泄露敏感代码或凭据。 没有全面的可见性：

  • 未检测到的管道泄漏： 攻击者修改 CI/CD 管道以注入恶意代码、外泄机密或建立后门，而不会触发由于缺少或审核日志记录不足而触发警报。
  • 内部威胁修改代码或基础结构： 恶意内部成员或遭到入侵的帐户在不检测的情况下对源代码、基础结构定义或部署配置进行未经授权的更改。
  • 缺乏全面的审核线索： 缺少详细的活动日志阻碍了在安全事件发生时进行取证调查、影响评估和根本原因分析，导致事件驻留时间延长并增加漏洞影响。
  • 延迟的事件响应： 平均检测时间（MTTD）从数小时扩展到数周，安全团队缺少实时警报、异常检测和 DevOps 安全事件的自动关联。
  • 合规性审核失败： 如果不进行集中式 DevOps 监视，则无法满足法规要求（SOX、PCI-DSS、HIPAA、ISO 27001）要求全面审核线索、更改跟踪和访问日志记录。
  • 特权升级盲目： 未经行为分析和特权监视，未经授权的权限提升、创建后门帐户或修改访问控制将继续未检测到。

日志空白掩盖了高特权开发路径中的恶意管道变更、权限提升和长期访问尝试。

MITRE ATT&CK

  • 防御逃避（TA0005）：削弱防御措施（T1562）禁用审核日志记录、安全扫描步骤或监视代理以在盲区中运行，以及指示器删除（T1070）清除审核日志或流水线执行历史以隐藏恶意活动。
  • 持久性（TA0003）：帐户操纵（T1098）创建其他服务主体、个人访问令牌或 SSH 密钥，不被检测到。
  • 集合（TA0009）：信息存储库（T1213）中的数据通过管道访问外泄源代码、机密或知识产权。
  • 凭据访问（TA0006）：通过不安全的凭据（T1552）提取管道日志或执行历史记录中暴露的机密。

DS-7.1：为 DevOps 平台实施日志审计

具有对生产基础结构和敏感源代码的特权访问权限的 DevOps 平台需要全面的安全监视来检测攻击者活动和内部威胁。 审核日志记录的差距使恶意行为者能够在长时间内不被检测地运行，而集中式日志聚合能够与更广泛的安全遥测进行关联，从而揭示复杂的攻击链。 实时行为分析可识别隔离事件中不可见的可疑模式，将原始审核数据转换为可作的安全智能。

通过这些功能建立全面的 DevOps 安全监视：

  • 捕获全面的安全相关活动： 建立全面的审核日志记录，用于捕获所有与安全相关的 DevOps 活动：用户身份验证和授权事件、源代码提交和分支作、管道创建和修改、部署执行、机密访问、权限更改、服务主体创建和管理作。 DevOps 平台对生产基础设施拥有特权访问权限，敏感代码的日志记录差距使攻击者和恶意内部人员能够长时间在未被检测到的情况下活动。

  • 实时将日志转发到集中式 SIEM： 将审核日志实时转发到集中式 SIEM 平台，而不是依赖于 DevOps 平台本机保留期（通常为 90 天），从而实现长期取证分析、合规性报告，并与来自其他系统的安全事件关联。 通过采用结构化格式（JSON）的标准化协议（/azure 事件中心、syslog）将日志流式传输到安全作中心，无需手动查看日志即可实现自动化分析、分析和警报。

  • 部署行为分析和异常情况检测： 在 DevOps 审核数据上实现行为分析和异常检测，以识别单个事件中不可见的可疑模式：小时后管道修改、对敏感存储库的异常访问、快速特权升级、服务主体创建，然后执行可疑部署、来自意外位置的管道执行或机密访问的异常模式。 为用户和服务建立基线行为配置文件，针对可能表示泄露或内部威胁的统计显著偏差发出警报。

  • 为高风险活动配置自动警报： 为高风险活动配置自动警报，并立即通知安全团队：生产部署失败、受保护分支中的管道修改、新的服务主体创建、权限提升事件、禁用安全扫描步骤、审核日志转发配置更改或尝试从未经授权的管道访问机密。 实施基于严重性的升级处理，确保关键警报立即到达安全运营中心，而常规事件则进行批处理分析。

  • 与更广泛的安全遥测集成： 将 DevOps 审核日志与 SIEM 平台中更广泛的安全遥测集成，以便与终结点检测、网络安全、标识事件和威胁情报源相关联。 这样就可以检测复杂的攻击链，其中 DevOps 泄露是多阶段作中的一个阶段，例如，将网络钓鱼凭据与后续管道修改和异常的云资源预配相关联。

  • 利用集成的 SIEM 平台：Azure DevOps 审核流式处理和 Microsoft Sentinel 集成等平台提供实时日志转发、DevOps 威胁预生成的检测规则、用于调查的安全工作簿和自动响应业务流程。

实现示例

原承包商修改 CI/CD 管道，将后门代码注入生产应用程序时，制造企业发现了内部威胁。 由于审核日志记录不足，事件仍未检测到数月。

挑战： 不集中记录 DevOps 活动。 管道修改和特权访问更改不受监视。 法医调查因缺乏审计线索而受阻。 由于更改跟踪不足，合规性审核失败。

解决方案方法：

  • 集中式审核日志记录：已启用 Azure DevOps 审核流，将事件转发到 Microsoft Sentinel 以进行安全分析和长期保留。
  • 行为分析： 实现了异常检测，识别异常访问模式、下班时间的管道修改以及表明内部威胁的权限升级。
  • 自动警报： 为可疑活动配置警报，包括未经授权的生产部署和服务主体创建路由到安全作。
  • 合规性报告： 创建自动化审核跟踪，满足法规要求，并进行了全面的更改跟踪。

结果： 快速检测并阻止后续未经授权的管道修改。 通过全面的审核线索大幅缩短了事件调查时间。 实现了与记录的变更管理相容性。

严重性级别

应该有。

控件映射

  • NIST SP 800-53 Rev.5： AU-2、AU-3、AU-6、AU-12、SI-4
  • PCI-DSS v4： 10.2.1、10.2.2、10.3.4
  • CIS 控件 v8.1： 8.2、8.5、8.11
  • NIST CSF v2.0： DE.CM-1、DE.CM-7、RS.AN-1
  • ISO 27001：2022： A.8.15、A.8.16
  • SOC 2： CC7.2、CC7.3
  • Last updated on