什么是安全软件开发生命周期？

传统上，软件开发遵循线性流程：规划、编码、测试、部署。数十年来，安全考量仅在测试阶段才被纳入，而此时数千行代码早已编写完毕。

SSDLC 打破了这一传统模式，从项目启动之初就将安全能力嵌入软件开发生命周期 (SDLC) 的各个阶段。SSDLC 通常分为九个阶段：需求、分析、规划、设计、开发、文档、测试、部署与维护。

团队首先同步研讨安全需求与功能需求，开发人员则通过规范的输入校验和身份验证标准，编写安全代码。测试工作持续开展，并非仅在发布前进行，通常通过自动化代码审查来实现。

这种“左移”模式，即将安全环节前置到开发流程早期，有助于转变组织的软件开发方式。团队不再等到测试阶段才追问“这是否安全”，而是在编写第一行代码前就思考“如何确保其安全”。

以银行应用程序为例。传统开发模式中，SQL 注入漏洞可能在发布前测试才被发现，这就需要开发人员重写数百个文件中的数据库交互逻辑。而采用 SSDLC 模式，团队更易提前发现此类漏洞，因为安全检查会贯穿设计、构建与测试的全流程。

最新数据充分说明，这种主动防护模式至关重要。近期一项供应链安全研究显示，软件供应链攻击在短短三年内激增 1300%。¹

SSDLC 可以通过提前检测漏洞（此时修复难度最低、成本也最少），帮助组织抵御此类及其他各类网络攻击。同时，它还能帮助组织持续符合《通用数据保护条例》(GDPR)、《健康保险流通和责任法案》 (HIPAA) 等法规要求。

SSDLC 通常包含九个阶段，与 SDLC 模型高度一致，不同之处在于每个阶段均融入了安全考量：

• 要求
• 分析
• 规划
• 设计
• 开发
• 文档
• 测试
• 部署
• 维护

团队会研讨最终软件的功能定位，从项目启动之初就同步明确安全需求与功能需求，例如加密敏感数据字段、建立基于角色的访问控制 (RBAC) 体系。研讨内容包括评估潜在安全风险，以及落实 GDPR 数据保护标准等合规要求。

组织会量化潜在漏洞、梳理威胁态势，基于最坏情况制定应对预案，而非仅局限于理想场景的假设。例如，医疗类应用程序会分析患者数据泄露、勒索软件攻击、内部威胁等各类风险，并针对性制定应对方案。

安全团队与利益相关方会明确岗位职责、分配相关资源，并根据潜在的业务影响，设定可接受的基准标准。这类规划既能优先处理高风险漏洞，又能确保开发进度如期达成。同时，还能让团队在编码启动前，完成安全工具采购与人员培训的预算规划。

设计阶段会开展威胁建模工作，即对规划架构中的潜在安全漏洞进行系统性分析。这种做法能确保安全设计融入系统整体蓝图，从平台选型到理想用户界面均覆盖安全能力，无需后期花费高昂成本进行改造。

开发人员会遵循开放式 Web 应用程序安全项目 (OWASP) 等机构制定的安全编码规范，落实各项安全编码实践。这类规范涵盖各类输入校验、身份验证技术落地、规范 API 调用、代码仓库扫描以及安全异常处理等内容。

开发人员通常会使用搭载安全插件的集成开发环境 (IDE)，以便尽早发现潜在问题。

团队会对软件依赖项进行评估，降低安全风险，同时在开发阶段就同步启动安全测试。例如，支付处理模块在构建过程中就会开展安全测试，而非完成整合后再进行。

团队会记录安全管控措施与相关流程，用于审计、合规核查及安全评审工作，进而实现事件快速响应与持续合规。

测试工作融合了代码审查与安全测试两大环节。团队会在部署前对软件的功能与安全性进行双重验证。

测试包含静态分析，如静态应用程序安全测试 (SAST)，无需运行程序即可分析源代码，以及动态应用程序安全测试 (DAST)，即在应用程序运行时开展测试。

高级测试可包括由道德黑客开展代码攻防测试、验证数据安全的渗透测试，以及 API 运行模拟测试。同时，还可同步开展软件成分分析 (SCA)，助力识别存在漏洞的开源依赖项与许可合规问题。

团队在软件发布前，会先对部署环境（服务器、配置项、中间件）进行安全加固。此举可有效避免因基础设施配置不当而引入漏洞。

许多团队还会收集软件遥测数据（指标、日志、链路追踪），以监测代码在实际环境中的运行状态。OpenTelemetry (OTel) 是云原生计算基金会 (CNCF) 旗下的开源项目，可支持供应商中立的指标、日志与链路追踪采集和传输，保障各服务、管道与环境的数据信号一致性。

持续监控有助于及早检测到各类威胁与漏洞，确保在软件全生命周期内实现快速修复。该阶段对于防范针对零日漏洞的利用、快速响应新发现的漏洞而言，尤为关键。

组织通常会依托成熟框架启动安全软件开发生命周期落地工作，这类综合方法论包含安全基准、安全最佳实践及风险评估工具。常用框架主要有以下几种：

美国国家标准与技术研究院提供政府支持的安全开发实践与基准，其中就包括安全软件开发框架 NIST SP 800-218。

该框架可以帮助组织为所有开发团队统一设定基础安全要求。与其他框架相比，它的联邦标准更加具体明确，因此更适合政府承包商和受监管行业使用。与联邦机构合作的组织，通常需要按照合同要求遵守 NIST 标准。

开放 Web 应用程序安全项目 (OWASP) 提供了一个开源框架，即软件保障成熟度模型 (SAMM)。

OWASP SAMM 可以帮助组织评估现有的软件安全实践，并根据自身风险状况量身制定迭代改进方案。

因此，很多希望采用灵活、基于成熟度的方案，而非僵化合规要求的组织，都更倾向于使用它。例如，初创企业可以先从身份验证等关键领域的基础安全实践做起，再随着团队和预算的扩大，逐步开展全面的安全测试。

OWASP DevSecOps 指南详细介绍了如何在管道中集成安全测试工具，包括 SAST、DAST、SCA（软件成分分析）和 IAST（交互式应用程序安全测试）。遵循这份指南，可以更轻松地将安全测试嵌入现有的持续整合与持续交付 (CI/CD) 管道，同时不影响开发工作流。

因此，那些希望在不放慢发布节奏的前提下实现安全自动化的组织，往往会选择 OWASP DevSecOps 指南，比如每天部署更新并保持 PCI DSS 合规的金融科技企业。

许多组织通过 DevOps 和 DevSecOps 实践落地 SSDLC，将安全测试自动化并整合到 CI/CD 管道中，在保证安全标准的同时提升开发效率。通过 DevSecOps 技术，开发团队除了负责安全设计、构建、运营和维护之外，还要负责应用程序安全。为了实现快速迭代、避免流程瓶颈，团队通常会采用自动化方式开展安全测试。

SLSA（读作 salsa）是一个社区化框架，最初由 Google 提出，目前由 OpenSSF 负责维护，用于保障软件供应链安全。

它的指导准则可以帮助组织防范篡改、验证构件完整性，并自动校验构建过程和依赖项。希望加强供应链安全、建立溯源能力的组织，可以通过部署 SLSA 来证明软件在构建过程中未被篡改。例如，软件供应商在发布企业级应用程序时，需要向客户证明版本真实有效、未被篡改。

SSDLC 能够为组织带来多方面的关键优势。

SSDLC 的“左移”方法可帮助组织在漏洞最容易修复、成本最低的设计和开发阶段就发现并解决问题，而不是等到部署之后。

例如，在设计阶段的评审中，就可能发现规划的架构会通过不安全的 API 端点泄露客户敏感数据。尽早发现这类问题，可以从一开始就构建更安全的架构，避免数据泄露带来的潜在损失，也省去了高昂的安全改造费用。

即便发生数据泄露，相关组织的损失成本也会更低。《数据泄露成本报告》显示，采用 DevSecOps 模式（包含 SSDLC）是降低泄露损失的最主要因素。采用该模式的组织，单次数据泄露的成本平均减少 227,192 美元。

SSDLC 可以在部署前就发现安全问题，减少系统停机时间，避免紧急修复，从而提升软件稳定性。在各个阶段开展威胁建模和细致的代码审查，还能进一步提升稳定性。

SSDLC 有助于保护软件供应链，覆盖从开发、CI/CD 管道到部署全过程中所有涉及代码的基础设施和相关人员。它将威胁建模、依赖项扫描等风险管理手段，与访问限制、代码签名等网络安全控制措施相结合，在全生命周期内防范漏洞。

例如，SSDLC 可以帮助组织落地软件物料清单 (SBOM)，对所有组件和依赖项进行追踪。这样一来，当第三方库中发现漏洞时，组织可以更方便地完成识别和修复。

SSDLC 在每个开发阶段都融入安全控制和文档记录，帮助组织保持合规。对于需要持续满足行业安全标准（如《通用数据保护条例》(GDPR)、《健康保险流通和责任法案》 (HIPAA)、《加州消费者隐私法案》(CCPA) 等）的组织来说，这一流程至关重要。可靠的合规状态可以有效减少法律风险和罚款可能。

在实施 SSDLC 的过程中，开发、运营和安全团队需要密切协作，在软件开发中汇集多方视角。这种必要的协作能够打破部门壁垒，提前防范那些后期可能造成高额损失的安全问题。

尽管 SSDLC 优势众多，但组织在落地过程中仍会遇到一些挑战。

希望产品尽快上市的利益相关者，往往会将安全要求看作影响开发速度的障碍。他们甚至可能要求将安全测试推迟到后续阶段。

这种做法虽然能加快前期开发，但在部署后暴露漏洞时，往往会造成代价更高的延期。

例如，在设计阶段跳过威胁建模，会导致关键攻击路径暴露在外。如果缺少系统化的威胁分析，团队可能会忽视授权系统、数据访问控制或第三方服务整合中的安全漏洞，这类漏洞在生产环境中的修复成本会成倍增加。

随着威胁态势持续变化，开发团队必须持续更新安全知识。没有专职安全团队的组织，需要加强培训、招聘专业人员或引入外部顾问，才能有效落地 SSDLC。

例如，刚接触安全编码的开发人员，可能不清楚何时使用静态分析工具，也不知道如何解读检测结果。如果缺乏相应培训，工具检出的高危漏洞可能得不到处理，或是产生误报，浪费开发时间。即使是经验丰富的开发人员，通常也需要持续学习，才能跟上最新的威胁形势和安全实践。

存在多处整合的复杂软件架构，往往需要专业的安全工具和流程，可能会增加开发时间和成本。例如，整合使用不同数据格式和通信协议的 IoT 设备，会产生新的攻击面，需要团队做好安全防护。

以加密 API 的实现为例，API 需要在最小权限下运行，同时支持各种用例。有些服务可能只需要加密功能，不需要配置解密权限。这就需要围绕访问控制、身份验证和传输层安全 (TLS) 进行周密规划，提升了各整合点的处理复杂度，团队需要在不影响安全和功能的前提下妥善解决。