本文可帮助安全和技术团队建立和现代化开发安全规则。 此规则可帮助安全、工程和技术团队确保软件经过安全设计、构建、集成和部署，而不会降低创新速度。
安全规则 是相关安全工作的分组，可帮助组织在整个技术资产中持续提供安全成果。 在安全采用模型中，规则有助于在业务方案和技术实施之间提供桥梁，确保安全投资转化为安全采用模型一部分的实际可衡量结果。
为什么选择这一学科？
软件与标识、数据、基础结构和业务流程密切相关。 当开发安全性薄弱或不一致时，每个软件版本都可能会引入攻击者利用的新漏洞来获取对更广泛的组织资产的访问权限。
如果没有有效的开发安全规则，组织通常会遇到：
- 开发过程中引入的软件漏洞的风险增加。
- 应用程序遭到入侵，从而能够跨身份和数据进行横向移动。
- 业务运营和收入中断。
- 暴露或滥用客户和管控数据。
- 增加长期风险和修正成本的技术债务积累。
强大的开发安全规则可确保每个版本都降低风险，而不是增加风险。
任务和结果
开发安全领域通过确保所有软件（无论是内部开发还是由合作伙伴开发）在设计、构建、集成和部署过程中均符合安全标准，在不拖慢交付速度或创新步伐的情况下，降低组织风险。
在这一领域发展成熟的组织可实现：
- 将安全性内置到开发流程中，而不是在后期再添加。
- 早期识别和修正设计和实现缺陷。
- 更可预测的安全发布周期。
- 减少了返工、紧急修复和操作中断。
- 随着时间推移，技术和安全债务的积累较低。
开发安全可确保每次发布安全状况持续改善，而不是定期重置。
团队工作更改
开发安全规则必须满足开发人员和产品团队的要求，将安全性集成到现有开发工作流中，而不是引入后期控制、摩擦密集型评审流程，甚至跳过开发流程中的安全性。
此方法通常被描述为 向左移动，在问题更容易且成本更低的情况下，在思路、设计和实现中引入早期的安全思维。 左移并不意味着只是在流程的更早阶段说“不”。 相反，它会提前引入安全信息的讨论，以提高产品决策并确保解决方案满足安全性和业务需求。
关键原则包括：
- 早期集成：考虑在设计和设计过程中的安全性，而不仅仅是测试
- 与开发者协同：在开发和产品团队现有的工作流程中与他们协作
- 小型增量更改：首选自动化和低摩擦改进
- 持续改进：将安全性视为一项持续规则，而不是里程碑
随着时间的推移，一致的集成可减少火力演练并加速交付，而不是减慢交付速度。
如何应用此规则
若要有效应用开发安全规则，请重点建立一致的方法来在整个组织中构建和维护安全应用程序和服务：
-
定义符合业务风险的安全发展战略
建立明确的方法来设计、构建和维护应用程序和服务，以减少泄露和保护关键业务功能的风险。 -
将安全性嵌入开发和工程流程
确保安全做法集成到规划、设计、开发和部署活动中，而不是在事后应用。 -
建立标准化的安全开发做法
提供明确的指导，确保跨团队和项目一致地应用安全编码、测试和发布做法。 -
将开发安全性与关键资产和业务方案保持一致
优先保护支持高价值资产和关键业务运营的应用程序和服务。 -
根据风险、漏洞和反馈持续改进
使用来自漏洞、事件和测试结果的见解来加强开发实践，并随时间推移降低风险。
管理更改
新式开发安全性通常通过 DevSecOps 方法实现，该方法将敏捷交付与发布前的基本治理和质量做法相结合。
DevSecOps 不选择速度和安全性，而是侧重于保护开发生命周期的关键方面，以缓解紧急风险，同时不妨碍快速发布周期：
保护设计 – 使用经过验证的安全设计模式并通过威胁建模验证设计。 保护代码 – 遵循安全编码做法并验证软件和依赖项。 保护管道 – 验证管道进程并保护 CI/CD 系统免受入侵和未经授权的更改。 确保对管道的更改和通过管道的软件的可跟踪性。 安全操作 – 确保部署的工作负载遵循配置、修补和操作最佳做法。
团队可以通过不断优化开发、安全和运营之间的协作，平衡功能交付目标，实现可靠性和风险降低，从而改善结果。
这种持续增量改进应应用于工作生产（生命周期中生成的软件代码）以及开发生命周期本身的成熟。
定义 DevSecOps 过程
开发安全性通常通过 DevSecOps 操作模型实现，该模型会随着时间推移而演变，而不是完全形成。 DevSecOps 将开发、安全性和操作汇集在一起，通过持续改进实现更好的结果。
大多数组织都通过以下阶段进行：
开发（开发） - 第一个生产版本侧重于提供满足核心业务需求的最小可行产品（MVP）。 DevOps – 初始发布后，团队专注于通过持续交付实现快速迭代、运营稳定性和治理。 DevSecOps – 随着协作的成熟，开发、安全性和操作协同工作，不断优化流程并平衡速度、风险和可靠性。
这种进展允许组织在不牺牲敏捷性或创新的情况下改善安全成果。
建立安全的 MVP 基线
此模型中的关键步骤是从开发、安全和操作角度定义构成最小可行产品（MVP）的内容。 建立此共享基线可以跨团队明确，并随时间推移实现一致的改进。
| 组件 | 详细信息 |
|---|---|
| Dev(elopment) | 确保软件满足最低业务和功能要求。 |
| Sec（urity） | 确保软件满足最低安全性和合规性要求。 |
| Op（eration）s | 确保软件满足最低质量、可靠性和运营就绪性要求。 |
MVP 要求因组织和行业而异，受风险偏好、监管暴露和业务关键性的影响。 随着组织、威胁格局和交付模型的变化，这些要求通常会演变。
持续软件改进
首次正式投产发布后，工作负载将进入持续优化循环。 在此阶段，开发、安全性和操作可优化软件和交付过程。 安全工作侧重于：
- 将安全性原生集成到开发工作流程中，并使用与其他工程工作相同的工具和优先级模型
- 作为标准发布周期的一部分，快速识别、排定优先级并修复安全漏洞。
此方法与 Microsoft 安全未来计划 （SFI） 学习（例如 prPaved Paths 保持一致，其中安全做法内置于平台和流程中，而不是在外部强制执行。
随着时间的推移，这种持续学习有助于团队优化需求、简化协作，更好地平衡交付速度、安全性和可靠性。
规则角色和协作者
开发安全规则通常由执行应用和产品开发的团队运行。
该领域中的主要角色通常包括：
- 技术交付和产品经理
- 软件开发人员（包括 AI 开发）
- 软件安全工程师
- DevOps 和平台工程师
- 测试和质量工程角色
- 供应链与依赖关系安全角色
主要协作者包括：
- 业务和技术领导 - 提供赞助和优先顺序
- 体系结构角色 - 指导安全设计和集成决策
- 安全策略、集成和治理规则角色 - 提供策略、教育和监督
- 基础结构和平台团队 - 启用安全开发环境
- 安全操作 （SecOps） - 监视和响应应用程序受到攻击时
与其他学科的一致性
开发安全与其他 SAF 规则紧密集成：
- 访问和标识 – 保护开发人员、工作负荷和服务标识。
- 基础结构安全性 - 保护运行应用程序和管道的平台。
- 数据安全性 – 确保在整个软件生命周期内保护敏感数据。
- SecOps – 检测和响应应用程序级攻击。
- 安全策略、集成和治理 - 使开发实践与企业风险优先级保持一致。
这些规则共同确保软件安全性支持更广泛的业务和安全成果。
与技术支柱的一致性
执行开发安全规则的策略需要跨多个技术支柱进行安全控制。
与技术支柱的一致性包括：
- 标识：保护开发人员和工作负荷标识和凭据。
- 端点：保护开发人员工作站和构建系统。
- 基础结构：保护托管代码、管道和工作负载的平台。
- 应用：为开发安全实践提供主要关注对象。
- 数据：保护应用程序使用、生成和存储的数据。
- 网络：设计用于在不受信任的网络上安全运行的软件。
- AI：保护新式应用程序中使用的 AI 组件和模型。
这种广度确保该学科能够应对现实世界中的攻击路径。
接下来会发生什么？
其他开发安全策略指南位于 “开发安全策略”中。
参加研讨会
Microsoft Unified 提供专家主导的研讨会，帮助组织现代化其开发安全规则。 这些研讨会包括：
- 体系结构和策略研讨会 - 安全采用框架 （SAF） - 体系结构设计研讨会：基础结构和发展安全研讨会 侧重于加快开发安全现代化并与基础结构安全性的集成。 此研讨会提供不到四个小时的讨论，重点讨论关键学习和最佳做法。
技术采用研讨会 ：Microsoft统一的研讨会可帮助组织了解、规划、实施和优化使用Microsoft开发安全技术，如下图所示。
查看 Microsoft 安全开发生命周期
Microsoft持续安全开发生命周期提供了一种安全开发软件的方法。 安全开发生命周期（SDL）是Microsoft用于将安全性集成到 DevOps 流程（有时称为 DevSecOps 方法）的方法。 SAF 开发安全指南可帮助你根据组织调整 SDL 方法和做法。
可以将 SDL 方法中所述的做法应用于所有类型的软件开发和所有平台，从经典瀑布式到新式 DevOps 方法。 这种一般适用的软件安全方法适用于任何类型的软件和平台。
有关详细信息，请参阅 Microsoft 安全开发生命周期 （SDL）。
有效的开发安全性需要遵循安全开发生命周期（SDL），例如 Microsoft 安全开发生命周期 （SDL）
后续步骤
了解 从 DevOps 到 DevSecOps 的转变。