什么是SDL

SDL其实是由微软提出并应用一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程，侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

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

为什么要做SDL

举个例子：

在大部分企业中，传统的做法是在产品快要上线前经过安全测试或者安全扫描，这种做法比较局限。在发现安全问题和解决问题都是在整个流程的后期，这样就会导致项目交付时间紧迫，安全活动往往被牺牲在紧张的交付时间期限内，导致大量安全活动被压缩。

而且在大型企业中，有众多的产品线，而这些产品线只能靠投入人力资源去跟踪测试，随着开发需求的不断增多，投入的安全人力资源也需要增多，给企业增加大量的成本负担。

那SDL可以为企业带来什么？

首先SDL是将安全活动嵌入到整个流程中去，从立项需求评审、开发代码扫描、测试漏洞扫描、发布基础环境检查、上线实时安全监控与检查这些环节逐步保证研发流程的安全，做到尽可能将安全问题往前移，建立流水线的日常安全任务保证安全横向(全面覆盖所有的研发项目)、纵向(对一个研发项目各个环节加入安全检查)的覆盖率。

SDL好处之一是在全流程中介入安全，越早发现漏洞问题，修复成本越低；产品的安全状态可以在整个开发过程得到更精准的反馈，有助于产品的安全进度管理。

这是一张在各个时期修复漏洞所产生的成本

可以看到在软件发布运行一段时间后，才发现的漏洞，需要运维，发布的介入，修复成本成几何级数上升，给企业带来相当大的风险和成本压力，若漏洞已被黑客发现或利用，造成的损失和影响将更大。

而在研发阶段，发现的漏洞可以由开发直接修复，成本低，效率高。

所以越早发现漏洞问题，修复成本越低。

微软SDL

微软官网上的SDL实施流程图

下面来解释下这些安全步骤

1. 培训： 管理制度，提供安全培训， 增强安全意识，确保人员了解安全基础知识。
2. 需求： 安全要求，定义安全隐私要求与安全门限要求，包括法律和行业要求，内部标准和编码惯例，对先前事件的审查以及已知威胁等，安全门限要求指安全质量 的最低可接受级别，明确定义安全漏洞的严重性阈值；
3. 设计： 安全隐私 需求分析与设计，具体措施包括执行威胁建模，建立设计要求，明确加密标准；
4. 实施： 管理使用第三方组件的安全风险，拥有准确的第三方组件清单，并了解其安全漏洞可能对集成它们的系统的安全性产生影响；
5. 验证： 安全研发与验证，具体举措包括使用经过安全性检查，认可 的工具，执行静态应用程序与动态应用程序安全性测试，进行渗透测试；
6. 发布： 发布部署阶段，建立标准的事件响应流程；
7. 响应： 针对运营安全， 通过人员权限认证，数据加密存储、传输，安全监控，定期更新安全策略，抵御常见网络攻击，执行渗透测试等手段保证上线运营阶段的安全。

培训Training

核心安全培训

提高团队安全意识，对齐安全需求。

开发团队的所有成员都需要接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员，测试人员、项目经理、产品经理等。项目的中期可开展针对性的培训，例如代码中经常出现的问题，测试过程中多次出现的漏洞等等。

需求Requirements

1.确认安全需求

安全研发与验证，具体举措包括使用经过安全性检查，认可 的工具，执行静态应用程序与动态应用程序安全性测试，进行渗透测试；

2.创建质量标准及Bug栏

用于确定安全和隐私质量的最低可接受级别，在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全bug。

项目团队必须协商确定每个开发阶段的质量门，随后将质量门交由给安全顾问审批，安全顾问可以根据需要添加特定于项目的说明，以及更加严格的安全要求。

3.安全&隐私风险评估

项目的哪些部分在发布前需要威胁模型；

项目的哪些部分在发布前需要进行安全设计评析；

项目的哪些部分需要不属于项目团队且双方认可的小组进行渗透测试；

是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险；

模糊测试的具体范围；

隐私对评级的影响。

设计Design

1.确认设计要求

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

2.分析攻击面

减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险。

3.威胁建模

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

实施Implementation

1.使用批准工具

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

2.弃用不安全的函数

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

3.对代码进行静态安全检查（静态分析）

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

验证Verification

1.动态安全测试（动态分析）

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

2.模糊测试

模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。

3.攻击面评审

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

发布Release

1.制定安全应急响应计划

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

2.最终安全评审（FSR）

是在发布之前仔细检查对软件执行的所有安全活动。

3.发布归档

在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档，为紧急响应和产品升级提供帮助。

响应Response

执行安全应急响应计划

安全设计核心原则

微软多年的实践和经验，软件的安全问题很大一部分是由于不安全的设计而引入的。

在设计阶段造成的安全缺陷在后期修复的成本和时间都相对较高。

相应的微软SDL也提出了若干核心的安全设计原则，并提出了如攻击面最小化、STRIDE 威胁建模等多种方法辅助安全人员对软件进行安全设计。

威胁模型

在SDL模型里，还有个很重要的执行要点，那就是威胁建模，威胁建模是在需求设计阶段的一项识别和消减威胁的重要手段。关于威胁建模，微软提出的一个方法叫做“STRIDE”。

STRIDE威胁建模基于数据流图去识别不同环节是否存在仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升几个维度的安全威胁，并制定对应的消减措施，落实并验证的一个过程。

SDL困难

• 实施SDL导致整个流程线延长，安全开发软件所需的时间也随之延长，但碍于项目交付时间有限，最终会导致安全在活动中流于形式。
• 由于开发人员安全意识以及能力欠缺，仅靠人工实现效果差强人意，所以还需要配合自动化平台工具使用。
• 部分企业由于没有符合自身的一套安全开发流程，按照SDL模型照猫画虎去实现安全活动往往也没办法使得安全活动很好的落地，这样导致的结果就是整个安全研发流程流于形式。

总结

实施SDL不能照搬照的实际情况。 SDL只是一个方法指导，具体如何实施还是需要依赖于自己公司的业务，还是得结合公司务情况。

应该做到以人为本，尽可能的为研发团队着想，为研发团队安全赋能，降低其安全实施门槛，能够轻轻松松的应付各种安全问题。

SDL实施是一个从上到下的过程，不仅需要对开发以及安全等人员进行培训，还需要让高层领导了解到实施SDL的重要性。

reference：

微软SDL流程终极整理总结 https://blog.csdn.net/weixin_43965597/article/details/122882914

从SDL到DevSecOps：始终贯穿开发生命周期的安全 https://zhuanlan.zhihu.com/p/146149814