最近在学习安全测试相关内容，目前大部分公司安全体系借鉴了SDL进行设计和改良，本文通过网络文章成文，用于学习安全基础基础知识。

SDL的是安全开发生命周期，Security Development Lifecycle。由微软最早提出，是一种专注于软件开发的安全保障流程。为实现保护最终用户为目标，它在软件开发流程的各个阶段引入安全和隐私问题。

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

安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

1、培训

开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识。培训对象：开发人员、测试人员、项目经理、产品经理；培训内容：安全设计、威胁建模、安全编码、安全测试、隐私等。

2、安全要求

2.1确定安全计划

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

2.2 设立安全基线和安全分级。

安全基线用于确定安全风险的最低可接受级别，安全分级用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。安全基线和安全分级一经设定，便绝不能放松。

2.3安全和隐私风险评估。

对系统可能面临的威胁、存在的弱点、造成的影响，以及三者综合作用所带来风险的可能性的评估，量化系统遭受攻击带来的影响或损失的可能程度。

安全风险评估（SRA）和隐私风险评估(PRA)是一个必需的过程，用于确定软件中需要深入评析的功能环节。包括：

① 项目的哪些部分在发布前需要建立威胁模型？

② 哪些部分在发布前需要进行安全设计评析？

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

④ 是否存在安全顾问认为有必要增加的测试或分析？

⑤ 模糊测试的具体范围？

⑥ 隐私对评级的影响。

3、设计阶段

3.1设计要求

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

3.2减小攻击面

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

减小攻击面与威胁建模紧密相关。它通过减少攻击者利用潜在弱点或漏洞的机会来降低风险，包括关闭或限制对系统服务的访问，应用“最小权限原则”，尽可能分层防御。

3.3威胁建模

微软的 STRIDE 模型。所谓STRIDE为Spoofing（假冒），Tampering（篡改），Repudiation（否认），Information Disclosure（信息泄漏），Denial of Service（拒绝服务），Elevation of Privilege（提升权限）。此乃微软的安全建模的模型，微软的产品就是基于它考虑安全问题的哦。STRIDE模型几乎是可以涵盖现在世界上绝大部分的安全问题。下面给上STRIDE模型对于安全属性的图

4.实施阶段

4.1使用指定的工具

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

4.2弃用不安全的函数

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

4.3静态分析

静态分析可以帮助软件开发人员、质量保证人员查找代码中存在的结构性错误、安全漏洞等问题，从而保证软件的整体质量。

5 验证阶段

5.1动态分析

态分析是静态分析的补充，用在程序运行时，测试验证程序的安全性，也称作“黑箱测试”。通过模拟黑客行为对系统进行动态攻击，分析系统的反应，从而确定该系统是否易受攻击。

5.2 模糊测试

模糊测试是一种特定的动态分析方法，通过故意向应用程序引入不良格式或随机数据诱发程序故障。测试策略的制定以应用程序的预期用途、功能、设计规范为基础。

5.3 威胁模型和攻击面评析

项目因需求变更等因素导致最终产出偏离原定目标，为此项目后期有必要对威胁模型和攻击面进行重新评析。

6.发布阶段

6.1事件响应计划

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

6.2最终安全评析(FSR)

最终安全评析指在产品发布之前对软件执行的安全活动，对比安全基准确定产品不符合安全基准、缺少功能和其他要求的区域，然后进行以下三种决策：

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

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

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

6.3 发布/存档

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

7．响应

当软件发布后遭受攻击时，根据制定的应急响应计划快速采取措施，把事件造成的损失降到最小。这里还可以加入应急响应演练，以加强公司对抗信息安全攻击的能力。

如果你喜欢我的文章，欢迎关注扫描公众账号：MiniStarClub