0x00 前言
作为笔记记录SDL相关基础知识。
SDL:Security Development Lifecycle 安全开发生命周期
0x01 正文
1.什么是SDL
SDL:Security Development Lifecycle 安全开发生命周期,将安全融入到开发的每一个过程中去,以减少软件中漏洞的数量并将安全缺陷降低到最小程度。
那么问题就来了,为什么要做这个东西,有什么好处。
由于SDL将安全进行左移,在源头就发现漏洞,可以直接进行修复,从而减少后期维护成本,以及和软件功能冲突的问题。
2.SDL活动简图
微软SDL安全活动简图

2.1 培训
2.2 需求
2.2.1 安全需求
- 定义软件隐私,以及信任度
- 确认最低安全要求
- 确立和部署安全漏洞跟踪系统,通过什么方式跟踪(可以通过jira)
2.2.2 创建质量标准及Bug栏
- 此标准主要用来确立安全和隐私质量的最低可接受级别
- 比如需要满足何种需求
所谓的Bug栏可以理解对漏洞的标准,对软件的最低标准,对漏洞的标准,比如不能出现中危以上的漏洞
2.2.3 安全&隐私风险评估
- 项目的哪些部分在发布前需要威胁模型?
- 项目的哪些部分在发布前需要进行安全设计评析?
- 项目的哪些部分(如果有)需要由不属于项目团队且双方认可的小组进行渗透测试?
- 是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险?
- 模糊测试要求的具体范围是什么
- 隐私影响评级如何?应基于以下准则回答此问题:
- P1 高隐私风险。功能、产品或服务将存储或传输 PII,更改设置或文件类型关联,或是安装软件。
- P2 中等隐私风险。功能、产品或服务中影响隐私的唯一行为是用户启动的一次性匿名数据传输(例如,软件在用户单击链接后转到外部网站)。
- P3 低隐私风险。功能、产品或服务中不存在影响隐私的行为。不传输匿名或个人数据,不在计算机上存储 PII,不代表用户更改设置,并且不安装软件。
2.3 设计
2.3.1 设计要求
- 创建安全和隐私设计规范
- 规范评析以及最低加密设计要求规范
- 功能规范
- 准确完整地描述特性或功能的预期用途。
- 描述如何以安全的方式部署特性或功能。
2.3.2 减小攻击面
- 减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。
- 减小攻击面包括关闭或限制对系统服务的访问、应用最小权限原则以及尽可能进行分层防御
这里其实可以从软件的最底层来进行处理,比如从启动权限,以及站库分离,弱口令入手
2.3.3 威胁建模
威胁建模用于存在重大安全风险的环境之中。
开发团队可以在其计划的运行环境的背景下,以结构化方式考虑、记录并讨论设计的安全影响。
实际上威胁建模可以贯穿整个需求以及设计
2.4 实施
2.4.1 使用批准的工具
- 使用工具
- 开发工具
- 编译工具
- 第三方库(这里涉及到供应链安全问题)
2.4.2 弃用不安全的函数
- 禁用确定为不安全的函数和 API(这里实际上需要一版不安全的函数和API的标准:如开发SDL指南)
- 通过静态扫描器来扫描代码
2.4.3 静态分析
项目团队应对源代码执行静态分析。
通常情况下就是
2.5.验证
2.5.1 动态程序分析
对软件程序进行运行时验证
- 监控应用程序行为是否存在内存损坏
- 用户权限问题以及其他重要安全问题
- 工具
2.5.2 模糊测试
对可输入点进行fuzz测试
2.5.3 威胁模型和攻击面评析
成品和最初的内容可能不一定一样,所以需要重新进行威胁模型的建立和攻击面的评析。
2.6 发布
2.6.1 事件响应计划
受 SDL 要求约束的每个软件发布都必须包含事件响应计划
事件响应计划应包括:
- 单独指定的可持续工程 (SE) 团队。
- 7*24小时联系
- 代码的安全维护
- 第三方代码的安全维护计划
2.6.2 最终安全评析
最终安全评析 (FSR)
- 通过 FSR
- 通过 FSR 但有异常
- 需上报问题的 FSR
2.6.3 发布/存档
对所有相关信息和数据进行存档,以便可以对软件进行发布后维护
信息和数据包括:
- 所有规范
- 源代码
- 二进制文件
- 专用符号
- 威胁模型
- 文档
- 紧急响应计划
- 第三方软件的许可证
- 服务条款
- 维护任务所需的任何其他数据
3. 流程图

0x02 其他
SDL主要还是考虑在基于瀑布模式的开发进行安全的左移,但是现在SaaS化时代,所以SDL需要再次改进,但是有很多东西是可以进行相互继承的,之后的内容也会在这里进行补充。