SDLC

概念

SDLC（Software Development Life Cycle，软件开发生命周期）是对软件从想法形成到最终退役全过程的组织方法。它回答的是：

为什么做
  → 做什么
  → 怎么设计
  → 怎么实现
  → 怎么验证
  → 怎么发布和运营
  → 什么时候下线

SDLC 本身不是某一种固定开发模型。瀑布、迭代、敏捷、DevOps、持续交付都可以属于 SDLC 的不同组织方式。区别主要在于阶段划分、反馈频率、交付节奏和责任分工。

SDL（Security Development Lifecycle）则是安全视角下对 SDLC 的增强，重点解决软件生命周期中的安全风险。可以简单理解为：

SDLC = 软件如何被规划、构建和运营
SDL  = 如何在上述过程中持续降低安全风险

典型阶段

1. 立项与需求

明确业务目标、用户范围、数据类型、合规要求、可用性目标和生命周期成本。安全相关问题包括：

• 是否处理身份、支付、健康、隐私或企业敏感数据；
• 是否需要多租户、跨地域或对外开放；
• 哪些角色可以访问和修改数据；
• 是否有审计、留存、加密和数据删除要求；
• 发生安全事件时，业务允许的恢复时间和数据丢失范围。

2. 架构与设计

确定系统边界、组件、接口、数据流、部署方式和依赖关系。此阶段适合进行威胁建模、信任边界分析、权限模型设计和安全架构评审。

3. 开发与集成

开发人员实现功能并接入第三方组件、云服务、数据库和 CI/CD 流水线。重点包括代码评审、依赖治理、密钥管理、输入校验、错误处理和安全编码规范。

4. 测试与验证

通过单元测试、集成测试、回归测试、性能测试和安全测试验证软件质量。安全验证可能包括 SAST、DAST、IAST、SCA、模糊测试、渗透测试和人工代码审查。

5. 发布与变更

确认版本、配置、部署权限、回滚方案、监控和应急联系人。发布并不意味着安全工作结束，生产配置、镜像、依赖和权限仍需持续检查。

6. 运营与维护

处理漏洞、缺陷、配置变化、依赖升级、用户反馈和安全事件。需要持续监控日志、指标、告警、资产和暴露面。

7. 退役

软件或组件下线时，需要撤销访问权限、删除或迁移数据、下线接口、回收密钥、清理基础设施并保留必要审计记录。

常见开发模型

模型	特征	安全风险	适合的安全做法
瀑布	阶段边界清晰，反馈较晚	安全问题集中到后期发现	在需求和设计阶段设置安全评审门禁
敏捷	小步迭代、持续交付	安全工作容易被排到迭代之外	将安全任务纳入 Backlog 和 Definition of Done
DevOps	开发、测试、运维自动化协同	自动化错误可能快速扩散	将安全检查嵌入流水线和部署策略
DevSecOps	安全与开发、运维共同负责	工具堆叠但缺乏治理	以风险、责任和反馈闭环为中心

SDLC 中的安全责任

安全不应被理解为安全团队在发布前的单点审批。更合理的责任分布是：

产品：定义业务风险和安全目标
研发：实现安全设计并修复代码问题
架构：控制系统边界、身份和数据流风险
测试：验证安全要求和异常场景
运维：保证配置、权限、监控和响应有效
安全：提供方法、工具、评审、验证和风险度量
管理层：决定风险接受、资源投入和责任边界

评估 SDLC 是否有效

不能只看是否存在流程文档或扫描工具。更有价值的是观察：

• 安全要求是否能追溯到需求、设计和测试；
• 高风险变更是否有明确责任人和审批依据；
• 工具发现的问题能否进入缺陷系统并闭环；
• 生产漏洞是否能反馈到设计规范和检测规则；
• 安全门禁是否根据风险分级，而不是一律阻断或一律放行；
• 团队能否持续、低成本地修复问题，而不是依赖少数安全专家。

小结

SDLC 是软件工程的总生命周期，SDL 是其中的安全工程体系。成熟的组织不会把安全只放在测试阶段，而是让安全要求从需求开始，贯穿设计、开发、发布、运营和退役。