创建或现代化 开发安全规则时，本文概述了如何将安全性集成到开发实践中，使开发人员操作（DevOps）向开发人员安全运营（DevSecOps）转变，并帮助保护应用程序交付。
现代组织依靠快速软件开发来交付创新，应对不断变化的业务需求，保持竞争优势。 DevOps 通过持续集成和交付实现这种敏捷性。 但是，速度的提高也带来了新的安全风险。
持续发布周期减少了设计决策与生产部署之间的时间，增加了将弱点引入生产环境的可能性，包括：
- 应用程序设计弱点
- 易受攻击的依赖项
- 配置错误
- 基础结构自动化缺陷
- 机密管理或卫生状况不佳。
DevOps 风险
新式 DevOps 环境跨开发、管道和生产系统扩展攻击面。 DevOps 工具（如源代码存储库、管道和自动化系统）是攻击者的高价值目标。
如果提前引入恶意代码，它可能会通过现有的安全检查并到达生产系统。
常见攻击目标包括：
- 将恶意代码注入构建产物中。
- 损害开发人员标识或服务帐户。
- 访问或泄露生产数据。
攻击者通常以自定义应用程序和开发环境为目标，以访问：
- 敏感的组织或客户数据。
- 专有业务逻辑和知识产权。
- 抵挡住遭入侵的开发系统的生产基础结构。
- 抵挡住软件供应链入侵的下游客户。
下图汇总了潜在的安全风险：
应用程序和开发风险
应用程序工作负载可以通过开发过程中引入的弱点或破坏用于生成和部署它们的基础结构而遭到入侵。
| 风险 | 目标 | 潜在结果 |
|---|---|---|
| 应用设计/实现 | 在设计或开发过程中引入的安全问题可能会向攻击技术公开工作负载，例如： - 输入验证不正确 - 不安全的身份验证或授权逻辑 - 弱或未正确实现加密 - 通过应用程序逻辑公开敏感数据 |
这些弱点可能允许攻击者： - 访问或操作应用程序数据 - 执行未经授权的操作 - 通过植入的逻辑缺陷保持持久访问。 |
| 开发基础结构/自动化 | 攻击可能针对： - 源代码存储库 - 构建流水线 - 部署自动化 - 基础结构即代码 （IaC） 模板 - 开发终结点或服务标识 |
入侵可能会使攻击者能够： - 将恶意代码插入构建产物 - 修改部署配置 - 通过植入逻辑缺陷维持持久访问权限 - 获取生产环境中使用的凭据或机密。 |
| 开发软件供应链 | 应用程序通常依赖于： - 第三方库 - 开源包 - 容器映像 - 平台服务 |
通过这些依赖项引入的漏洞或恶意代码可能会影响： - 组织生产工作负荷 - 客户或合作伙伴环境 |
将安全性集成到开发流程可以减少这些风险传播到生产发布的可能性。
向左移动
左移是一种安全工程方法，用于在开发生命周期早期集成安全性。
组织无需在过程中后期验证安全性，而是将其嵌入：
- 构想
- Design
- 发展
- Operations
这可降低修正成本和风险暴露。
若要支持此方法，组织应
- 应在流程早期采用结构化最佳实践，例如 安全开发生命周期（SDL），而不要等到后期，因为那时问题的修复成本高且难以解决。
- 为了维持此方法，将治理、风险和合规性（GRC）集成到发展战略中。
什么是 DevSecOps？
DevSecOps 通过扩展 DevOps 并将安全性嵌入到软件开发生命周期的每个阶段（从创意开始到设计、开发和操作）来实现 Shift Left 方法。
在传统的开发方法中，安全验证通常在发布前作为最终质量门执行。 这会造成延迟、增加修正成本，并允许漏洞持续到生命周期后期。
DevSecOps 会提前转移安全性，并将其持续嵌入开发和操作流程中。
DevSecOps 可减少开发、运营和安全团队之间的摩擦，使其与创新速度、可靠性和安全复原能力的共同目标保持一致，并使团队能够尽早、持续地解决最重要的问题。
DevSecOps 将安全性集成到：
- 建筑设计
- 应用程序实现
- 基础结构自动化
- 部署和操作过程
Benefits
DevSecOps 使开发、安全性和运营团队能够：
- 识别并修正生命周期前面的问题。
- 减少生产中的暴露。
- 在管理风险的同时保持交付速度。
安全性成为软件生成和交付方式的一部分，而不是在交付后应用的控件。
安全创新生命周期
创新通常通过两个生命周期阶段进行：
| 阶段 | 详细信息 |
|---|---|
| 创意孵化 | 为初始生产使用设计、实现和验证功能。 它从一个新的想法开始 |
| 初始版本 |
第一个生产版本满足安全产品使用的最低产品标准。 - 开发：功能满足最低业务需求。 - 安全性：功能满足生产使用的法规合规性、安全性和安全要求。 - 操作： 功能满足生产系统的最低质量、性能和可支持性要求。 |
初始发布后，随着工作负载不断演变，开发将转变为迭代式进行：
- 更改风险容忍度
- 应用程序要求和成熟度
- 监管义务
- 威胁条件
将安全性集成到开发中
传统开发方法在生命周期后期验证安全性，作为设计和实现完成后发布前的最终入口。 在现代开发环境中，延迟验证会增加：
- 漏洞复杂性
- 修正成本
- 操作延迟和中断
- 面临主动攻击的风险敞口增加
DevSecOps 在整个开发和操作中持续集成安全性，以尽早解决问题、降低风险并提高一致性。
关键做法
安全性必须嵌入到现有开发流程中，才能有效、可缩放且可持续。 它应直接集成到应用的设计、生成、部署和操作方式中，而不是在单独的或并行工作流中实现。 我们建议：
- 梳理从构思到开发、部署和持续运维的端到端工作流。
- 在生命周期的每个阶段定义明确的安全角色、工具和责任。
- 为漏洞、缺陷和设计问题建立一致的修正路径。
根据工作负荷风险定制安全做法。 业务关键型应用程序需要更严格，而风险较低的方案可以遵循简化的方法。
至少确保：
- 确定开发生命周期中涉及的阶段、人员和技术。
- 定义安全活动如何集成到每个阶段，而不是将它们视为单独的检查点。
- 建立在整个生命周期内处理重大更改和例行修复的过程。
在开发和部署中自动实现安全性
自动化对于在整个开发和操作中一致、大规模地强制实施安全性至关重要。
- 将安全控件和工具直接集成到 CI/CD 管道中。
- 自动执行威胁建模、代码扫描、验证和策略强制等关键活动。
- 使用基础设施即代码（IaC）实现可重复且安全的部署。
Azure登陆区域等平台基础可以通过以下方式支持此方法
Azure登陆区域等平台基础可以通过提供标准化的安全、治理和 DevOps 集成模式来支持此方法。
预期结果
从 DevOps 迁移到 DevSecOps 的组织可以：
- 减少将漏洞引入生产工作负荷的可能性
- 限制攻击者利用开发基础结构或自动化的能力
- 提高应用程序对不断演变的攻击技术的复原能力
- 支持法规和组织合规性要求
- 在不增加运营或安全风险的情况下保持创新速度
导航旅程的提示
采用 DevSecOps 需要组织和文化更改。
教育和文化变化
这些都是关键的早期步骤。 你拥有的团队必须培养新的技能，并采用新的视角来了解 DevSecOps 模型。
教育和文化变革需要时间、重点、执行赞助和定期跟进，以帮助个人充分理解和了解变化的价值。
改变文化和技能有时可以充分利用个人的专业身份，从而产生强烈的抵抗潜力。 了解和表达每个人及其情况的变化原因、原因和方式至关重要。
更改需要时间
推进速度仅取决于团队适应以新方式做事所带来影响的速度。 团队在转换时必须完成现有工作。
必须仔细确定最重要的事项的优先级，并管理此更改的发生速度的预期。
采用循序渐进的“爬、走、跑”策略，优先落实最重要、最基础的要素，将最有利于贵组织。
更改引入（临时）摩擦
所有新技术、方法和其他变化都引入了摩擦和混乱。 关键是要专注于能够促进批判性思考、从而降低风险的良性摩擦，同时避免那些虽会拖慢流程却几乎不能带来收益或降低风险的不良摩擦。
有限的资源
组织通常面临的一个挑战是寻找安全和应用程序开发方面的人才和技能。
随着组织开始更有效地协作，他们可能会发现隐藏的人才，例如具有安全思维模式的开发人员或具有开发背景的安全专业人员。
持续转变
应用正在快速变化。 除了新功能之外，应用程序的技术定义和构成在引入云、无服务器和 AI 等技术方面也发生了根本变化。
这种转变正在改变开发实践、应用程序安全性，甚至使非开发人员能够创建应用程序。
考虑 SRE 模型
某些 DevSecOps 实现将操作和安全责任合并到 站点可靠性工程师（SRE） 角色中。
虽然这种模型可以正常工作，但通常与现有企业文化和做法存在极端变化。
如果你正在考虑 SRE 模型，我们建议首先使用本指南中概述的实际快速胜利和增量进度将安全性嵌入 DevOps，以确保获得良好的投资回报（ROI），并满足即时需求。
这逐渐增加了运营和开发人员的安全责任，使团队更接近 SRE 结束状态。
后续步骤
了解 安全开发最佳做法。