0x01 SDL介绍

安全开发生命周期（SDL）即Security Development Lifecycle，是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。

0x02 SDL流程框架

自2004年起，SDL就成为Microsoft全公司的计划和强制施行政策，其核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动与规范，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

Microsoft 安全开发生命周期 – 简化（英文版）

Microsoft 安全开发生命周期 – 简化（中文版）

SDL的安全活动包括：

阶段1：培训

开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员、测试人员、项目经理、产品经理等。

阶段2：安全要求

在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。

阶段3：质量门/bug栏

质量门和bug栏用于确定安全和隐私质量的最低可接受级别。

Bug栏是应用于整个开发项目的质量门，用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定，便绝不能放松。

阶段4：安全和隐私风险评估

安全风险评估（SRA）和隐私风险评估(PRA)是一个必需的过程，必须包括以下信息：

1、（安全）项目的哪些部分在发布前需要威胁模型？

2、（安全）项目的哪些部分在发布前需要进行安全设计评析？

3、（安全）项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试？

4、（安全）是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险？

5、（安全）模糊测试要求的具体范围是什么？

6、（安全）隐私影响评级如何？

阶段5：设计要求

在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。

阶段6：减小攻击面

减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险，减小攻击面包括：关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能进行分层防御。

阶段7：威胁建模

为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面。

阶段8：使用指定的工具

开发团队使用的编辑器、链接器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。

阶段9：弃用不安全函数

许多常用函数可能存在安全隐患，应当禁用不安全的函数和API，使用安全团队推荐的函数。

阶段10：静态分析

代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合。

阶段11：动态程序分析

动态分析是静态分析的补充，用于测试环节验证程序的安全性。

阶段12：模糊测试（Fuzzing Test）

模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试，或者扩大模糊测试的范围和增加持续时间。

阶段13：威胁模型和攻击面评析

项目经常会因为需求等因素导致最终的产出偏离原本设定的目标，因此在项目后期对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。

阶段14：事件响应计划

受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。需要注意的是，如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。

阶段15：最终安全评析

最终安全评析（FSR）是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同不同结果。

1、 通过FSR。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解。

2、 通过FSR但有异常。在FSR过程中确定所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来，在下次发布时更正。

3、 需上报问题的FSR。如果团队未满足所有SDL要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可解决的问题，或者上报高级管理层进行抉择。

阶段16：发布/存档

在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档，为紧急响应和产品升级提供帮助。从以上的过程可以看出，微软的SDL的过程实施非常细致。微软这些年来也一直帮助公司的所有产品团队，以及合作伙伴实施SDL，效果相当显著。

SDL 过程图示：

0x03 SDL实战经验

准则：

• 与项目经理进行充分沟通，排除足够的时间

• 规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏

• 树立安全部门的权威，项目必须由安全部门审核完成后才能发布

• 将技术方案写入开发、测试的工作手册中

• 给工程师培训安全方案

• 记录所有的安全bug，激励程序员编写安全的代码

0x04 总结

SDL中的方法，试图从安全漏洞产生的根源上解决问题，通过对软件工程的控制，保证产品的安全性。本文简单介绍了一下微软SDL，但流程复杂，落地难，借鉴微软SDL流程框架，思考如何构建符合自己公司的SDL流程框架。接下来会写几篇关于SDL的学习与思考，待续。

最后

欢迎关注个人微信公众号：Bypass--，每周原创一篇技术干货。 

参考文献：

[1]【软件安全设计】安全开发生命周期（SDL） http://blog.nsfocus.net/sdl/
[2] 微软SDL官方地址
http://www.microsoft.com/security/sdl/default.aspx
[3] Microsoft SDL 的简化实施 
https://www.microsoft.com/zh-cn/download/confirmation.aspx?id=12379
[4] 应用安全与微软SDL-IT流程
https://blogs.technet.microsoft.com/gcrsec/2008/09/22/sdl-it/ 
[5] SDL 威胁建模工具入门
https://msdn.microsoft.com/zh-cn/magazine/dd347831.aspx

​