SDL(安全开发生命周期)

0x0 前言

最近在读《互联网企业安全高级指南》里面的一章SDL有感，结合工作经验之谈，遂写此文。

0x01 SDL概念

当我们谈到SDL（Security Development Lifecycle）安全开发生命周期，就不得不说到微软，因为SDL是微软在2004年提出来的一个从安全角度指导软件开发过程的管理模式。微软当时的最受欢迎产品是OS和Office，在2004年之前病毒横行霸道，严重影响了微软的客户，而且美国政府是微软的最大客户，当时因为事情美国政府限制了微软产品的发布。

微软为了降低风险和挽回市场，2004年将SDL引入其内部软件开发流程中，目的是减少其软件中的漏洞数量和降低其严重级别。SDL侧重于长期维护、流程改进并能够帮助开发过程应对不断变化的威胁状况，Windows Vista是 第一个通过完整 SDL的操作系统。

总的来说SDL是在传统软件开发生命周期的各 个阶段增加了一些必要的安全活动，软件开发的不同阶段所执行的安全活动也 不同，每个活动就算单独执行也都能对软件安全起到一定作用。

SDL、SDLC和S-SDLC

有很多刚入门的小伙伴一开始看到这些名词的时候也一脸懵，下面来介绍这三个名词的含义：

• SDL：Security Development Lifecycle，安全开发生命周期
• SDLC：Software Development Life Cycle，软件开发生命周期
• S-SDLC：Secure Software Development Life Cycle，安全软件开发生命周期，是由开源Web安全组织OWASP推出的一个项目

0x02 SDL实践

SDL 的核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段都增加相应 的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。其流程分为以下七部分:

安全培训、安全需求、安全设计、安全开发、安全测试、发布审核、安全响应。

1、安全培训

安全是每个人的工作。开发人员、服务工程师以及程序和产品经理必须了解安全基础知识，并知道如何将安全性构建到软件和服务中，以使产品更加安全，同时仍能满足业务需求并提供用户价值。

有效的培训将补充和加强安全政策、SDL 实践、标准和软件安全要求，并以从数据或新可用技术能力中获得的见解为指导。

尽管安全是每个人的工作，但重要的是要记住，并不是每个人都需要成为安全专家，也不是每个人都需要努力成为熟练的渗透测试人员。然而，确保每个人都了解攻击者的观点、他们的目标和可能的艺术将有助于吸引每个人的注意力并提高集体知识水平。

基础软件安全培训应该包含的基础概念如下：

• 安全设计，包括以下主题：
  • 减小攻击面
  • 深度防御
  • 最小权限原则
  • 安全默认设置
• 威胁建模，包括以下主题：
  • 威胁建模概述
  • 威胁模型的设计意义
  • 基于威胁模型的编码约束
• 安全编码，包括以下主题：
  • 缓冲区溢出（对于使用 C 和 C++ 的应用程序）
  • 整数算法错误（对于使用 C 和 C++ 的应用程序）
  • 跨站点脚本（对于托管代码和 Web 应用程序）
  • SQL 注入（对于托管代码和 Web 应用程序）
• 弱加密安全测试，包括以下主题：
  • 安全测试与功能测试之间的区别
  • 风险评估
  • 安全测试方法
• 隐私，包括以下主题：
  • 隐私敏感数据的类型
  • 隐私设计最佳实践
  • 风险评估
  • 隐私开发最佳实践
  • 隐私测试最佳实践

2、安全需求

为减少安全问题带来的损失，以及线上安全问题整改带来的成本，需要将 安全工作进行前置。在需求分析阶段，应该对软件产品的风险进行评估，建立 安全需求。由于产品多且功能繁杂、项目管理未覆盖到每条业务线、安全团队 人员少等诸多因素，ROI 是最头疼的难题。不过可以因地制宜，借助纵深防御 思想并落实到该阶段，建立基本或通用的安全需求。

• 安全需求：“预先”考虑安全和隐私是开发安全系统过程的基础环节。为软件项目定义信任度要求的最佳时间是在初始计划阶段。尽早定义要求有助于开发团队确定关键里程碑和交付成果，并使集成安全和隐私的过程尽量不影响到计划和安排。对安全和隐私要求的分析在项目初期执行，所做工作涉及为设计在计划运行环境中运行的应用程序确定最低安全要求，并确立和部署安全漏洞/工作项跟踪系统。
• 质量门/Bug栏：用于确立安全和隐私质量的最低可接受级别。
• 安全和隐私风险评估：安全风险评估 (SRA) 和隐私风险评估 (PRA) 是必需的过程，用于确定软件中需要深入评析的功能环节。

3、安全设计

SDL 安全设计核心原则:

• Attack Surface Reduction:攻击面最小化

• Basic Privacy: 基本隐私

• Least Privilege: 权限最小化

• Secure Defaults: 默认安全

• Defense in Depth:纵深防御

• Threat Modeling:威胁建模

攻击面最小化

攻击面是指程序任何能被用户或者其它程序所访问到的部分，这些暴露给用 户的地方往往也是最可能被恶意攻击者攻击的地方。
攻击面最小化即是指尽量减少暴露恶意用户可能发现并试图利用的攻击面 数量。

软件产品的受攻击面是一个混合体，不仅包括代码、接口、服务，也包括 对所有用户提供服务的协议。尤其是那些未被验证或者远程的用户都可以访问到的协议，安全人员在攻击面最小化时首先要对攻击面进行分析，攻击面分析就是 枚举所有访问入库、接口、协议一剂可执行代码的过程，从高层次来说，攻击面 分析着重于:

• 降低默认执行的代码量

• 限制可访问到代码的人员范围

• 限定可访问到代码的人员身份

• 降低代码执行所需权限

基本隐私

用户使用软件时无可避免个人信息被收集、使用甚至分发，企业则有责任和 义务建立保护个人信息的保护措施，抵御敌对攻击行为，确保用户基本隐私的安 全性。隐私安全是建立可信任应用程序的关键因素。

在软件设计时考虑用户基本隐私的必要性及意义有:

• 履行法律规定和义务

• 增加客户的信赖

• 防止堵塞部署

权限最小化

如果一个应用程序或网站被攻击、破坏，权限最小化机制能够有效的将潜在 损害最小化。常见的权限最小化实践如:

• 普通管理员/系统管理员等角色管理
• 文件只读权限/文件访问权限等访问控制
• 进程/服务以所需最小用户权限运行

在进行软件设计时，安全设计人员可以评估应用程序的行为及功能所需的最
低限度权限及访问级别，从而合理分配相应的权限。如果程序特定情况必须要较 高级别的权限，也可以考虑特权赋予及释放的机制。即便程序遭到攻击，也可以 将损失降到最低。

默认安全

默认安全配置在客户熟悉安全配置选项之前不仅有利于更好的帮助客户掌 握安全配置经验，同时也可以确保应用程序初始状态下处于较安全状态。而客户 可根据实际使用情况而决定应用程序安全与隐私的等级水平是否降低。

纵深防御

与默认安全一样，纵深防御也是设计安全方案时的重要指导思想。纵深防御 包含两层含义:首先，要在各个不同层面、不同方面实施安全方案，避免出现疏 漏，不同安全方案之间需要相互配合，构成一个整体;其次，要在正确的地方做 正确的事情，即在解决根本问题的地方实施针对性的安全方案。
纵深防御并不是同一个安全方案要做两遍或多遍，而是要从不同的层面、不 同的角度对系统做出整体的解决方案。

威胁建模

威胁建模是一种分析应用程序威胁的过程和方法。这里的威胁是指恶意用户 可能会试图利用以破坏系统，和我们常说的漏洞并不相同。漏洞是一个特定的可 以被利用的威胁，如缓冲区溢出、sql 注入等。
作为 SDL 设计阶段的一部分安全活动，威胁建模允许安全设计人员尽在的 识别潜在的安全问题并实施相应缓解措施。在设计阶段把潜在的威胁发现有助于威胁的全面和更有效的解决，同时也有助于降低开发和后期维护的成本。威胁建 模的一般流程如下:
与系统架构师及设计人员沟通，了解设计详情

• 使用成熟的威胁建模方法分析当前设计潜在的安全问题
• 提出安全建议及对潜在威胁的缓解措施
• 对安全设计进行验证并对整个设计方案进行回顾并再次确认 微软使用的威胁建模方法是STRIDE威胁建模方法。为了便于安全人员快速便捷的进行威胁建模，微软开发基于 STRIDE 威胁建模方法的 SDL Threat Modeling Tool2威胁建模工具，该工具可以帮助安全人员画数据流图、分析威胁、 生成并导出威胁建模报告。

STRIDE威胁建模：STRIDE威胁建模是由微软提出的一种威胁建模方法，该方法将威胁类型分为Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄漏）、Denial of Service（拒绝服务）和 Elevation of Privilege（权限提升）。STRIDE威胁模型几乎可以涵盖目前绝大部分安全问题。

相关概念解释如下表：

威胁	定义	对应的安全属性
Spoofing	冒充他人身份	认证
Tampering	修改数据或代码	完整性
Repudiation	否认做过的事	不可抵赖性
Information Disclosure	机密信息泄露	机密性
Denial of Service	拒绝服务	可用性
Elevation of Privilege	未经授权获得许可	授权

STRIDE威胁建模流程和前面介绍的一样：

• 绘制数据流图
• 识别威胁
• 提出缓解措施
• 安全验证

4、安全开发

在确定产品原型与功能之后，便交由开发负责推进。然而他们的关注点大多仅在于业务流程与功能点的实现，具体使用的技术决定于公司技术栈和个人能力，对于带着安全意识去编码这件事儿，大多都没太在意。

本块主要包含了安全开发规范、安全组件接入、静态代码扫描三方面：

安全开发规范

从隐私和安全角度两方面出发，结合当前发现的高危问题;参考业界的安全开发规范，融合公司当前的技术栈;站在开发视角，进行安全开发规范的编写。规范项不在多，关键是需要清晰、易懂、针对性强、易判断是否违规。

安全组件接入

分析企业中存在的常见安全漏洞，来源可能是内部安全测试结果、外部漏洞收集(SRC、第三方漏洞平台、CVND 等)，并结合漏洞影响、开发难易程度、加固效果，对业务部门输出统一的安全组件，快速、高效、低成本解决普遍存在的安全问题。常见的可能有:统一登录安全网关、短信安全网关、CSRF-token 组件、XSS 过滤器(适用于非富文本框场景)等。

静态代码扫描

代码的白盒测试，最好是嵌入到发布流程中。一方面对源代码起到保护作用，不用另辟蹊径存放源代码，打破源代码统一管控的好局势;另一方面可以在流程中设置卡点，形成强有力的抓手。不少人对代码分析存在恐惧，觉得是效率低并且要求高的工作，但是在代码层面找出问题对于整个 SDL 都是十分必 要、有效的一环。市面上的代码审计工具不少，商业的包括 checkmarx、fortify、coverity，开源的有 check style、findbugs、cobra、Rips 等，需要从语言的支持、误报率、购买以及维护成本等不同维度进行综合评估。

5、安全测试

SDL 可视作为软件安全方面的纵深防御，到了测试阶段也就代表着软件架构与设计已经定型、第三方开源组件的引用已基本不太可能改变、前面各环节 的漏网安全 bug 已迎来最后一次发布前的检测。

安全提测信息

• 测试环境一致:确保待测系统与生产环境一样，是保证安全测试质量 的基础，但往往却较难实现。
• 测试环境可访问:由于网络 ACL 限制等因素导致安全测试人员一时不能访问，也是常见的一种现象，将安全测试时间花费在环境的准备上比较可惜。
• 测试账号提供:待测系统通常会有不同权限的账号，如果业务方不能完整提供，可能会导致越权、SQLi、信息泄露等常见安全 bug 漏测。
• 测试范围确定:指明安全提测类型是全量还是增量，如果是增量需要 说明新增功能点至关重要，可提升安全测试的速度并保证一定的安全 质量。

解决安全提测信息中可能遇到的各类问题，可以通过规范提测信息填写要求、提测信息核对处理流程、设置专人校对(刚入门不久的外包、实习生等)
来解决。

安全测试思路

• 安全测试用例:在实现自动化安全测试前，沉淀一份具有本公司特点、集成团队成员测试技能的安全测试用例，变得十分有必要。首先，一定程度上能弥补团队成员因能力层次不齐而导致的安全测试质量不一，再者可以为实现自动化提供高命中规则。其次，可提供给新人快速上手，帮助新人成长至胜任安全测试工作;最后，对外输出给测试团队，赋能测试团队减轻安全团队的压力。

• 安全测试工具:被动测试工具，在团队内部越来越收到青睐，特别是 面对多工单任务繁重的场景。将针对性强检测的插件集成到
  BurpSuite，进行被动式扫描，不失为一种简单高效的方法。

• 安全测试方法论:标准的安全测试流程不能督促团队成员去标准作 业，亦不能弥补团队成员的能力差异。自动化安全测试，或许是解决 这些问题的最佳方案。

安全漏洞管理

漏洞的产生到修复离不开安全人员和业务方，然而串联起他们之间的便是 漏洞的管理流程和扭转状态。

前者需要流程管理系统来支持，比如 jira;后者需要自定义漏洞状态以及状态改变的触发动作，整个环节最终目标就是让漏洞被及时修复。

6、发布审核

在本环节中，已经不再涉及到 SDL 中的“工具”，转而到“流程”。产品 发布前的最后一道关卡，做最终的安全验收。无论是否能满足安全质量要求，产品均有可能发布上线，但一定得有兜底的措施。

对于符合安全部门要求的产品，放行发布上线;对不符合安全要求的产品，理论上则不允许上线。然而在实际的场景中，业务和安全孰轻孰重一直是热议的话题，即使是在大型互联网公司也会存在部分业务优先。但在放行不达标产品前，需要将安全风险降低和安全责任抛出，并制定一系列的第二或第三选择安全方案进行兜底，切实起到公司安全投入有产出、安全赋能产品的初衷。

主要分为以下三项：

事件响应计划

受SD要求约束的每个软件发布都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的程序也可能面临日后新出现的威胁。事件响应计划应包括：

• 单独指定的可持续工程 (SE) 团队；或者，如果团队太小以至于无法拥有 SE 资源，则应制定紧急响应计划 (ERP)，在该计划中确定相应的工程、市场营销、通信和管理人员充当发生安全紧急事件时的首要联系点。
• 与决策机构的电话联系（7 x 24 随时可用）。
• 针对从组织中其他小组继承的代码的安全维护计划。
• 针对获得许可的第三方代码的安全维护计划，包括文件名、版本、源代码、第三方联系信息以及要更改的合同许可（如果适用）。

最终安全评审

最终安全评析 (FSR) 是在发布之前仔细检查对软件应用程序执行的所有安全活动。FSR 由安全顾问在普通开发人员以及安全和隐私团队负责人的协助下执行。FSR 不是“渗透和修补”活动，也不是用于执行以前忽略或忘记的安全活动的时机。FSR 通常要根据以前确定的质量门或 Bug 栏检查威胁模型、异常请求、工具输出和性能。

发布/存档

指派负责发布事宜的安全顾问必须证明（使用 FSR 和其他数据）项目团队已满足安全要求。此外，必须对所有相关信息和数据进行存档，以便可以对软件进行发布后维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档、紧急响应计划、任何第三方软件的许可证和服务条款以及执行发布后维护任务所需的任何其他数据。

7、安全响应

漏洞总是在不断的涌现，即使是前面的各项安全活动中均已达标，产品在上线后依旧会面临新增漏洞的攻击。对于安全风险的警觉和发现能力以及渠道，需要逐步建立并完善、运营。

在传统软件开发生命周期中，与技术相关的最后一阶段是响应，微软在该阶段所推崇的安全活动为执行事件响应计划。在实际落地时，可针对响应的渠 道进行扩展，比如从漏洞预警信息监测、从 SRC 接收到产品相关的漏洞信息等入手;也可将被动式接收产品漏洞信息，转变为每季度进行漏洞扫描，主动发现已上线产品的漏洞并进行安全响应。

0x03 结尾

其实要推动整个SDL落地还是比较难的，所以现在很多公司都从SDL过度到DevSecOps主要还是因为现在的DevOps的交付模式、历史问题、业务模式、SDL的门槛等等。

0x04 参考

1、浅谈SDL与DevSecOps-Mi1k7ea

2、SDL的最初实践-aerfa

---