目录
微软软件安全开发流程（SDL）
一、微软SDL(Security Development Lifecycle)流程框架
二、主要步骤
1.安全培训Training
1.1 Core Security Training核心安全培训
2.需求分析Requirements
2.1 建立安全需求分析Establish Security Requirements
在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。
2.2 创建质量标准及Bug栏Create Quality Gates/ Bug Bars
2.3 安全&隐私风险评估（SRA&PRA）
3.系统设计Design
3.1 制定设计规范Establish Design Requirements
3.2 分析攻击面Analyze Attack Surface
3.3 威胁建模Threat Modeling
4.实现Implementation
4.1 使用优选工具Use Approved Tools
4.2 消减危险函数Deprecate Unsafe Functions
4.3 对代码进行静态安全检查（静态分析）Static Analysis
5.验证Verification
5.1 动态安全测试Dynamix Analysis
5.2 模糊测试Fuzz Testing
5.3 供给面评审Attack Surface Review
6.发布Release
6.1 制定安全应急响应计划Incident Response Plan
6.2 最终安全评审（FSR）Final Security Review
6.3 发布归档Release Archive
7.响应Response
三、SDL实战经验准则
1.与项目经理进行充分沟通，排除足够的时间
2.规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏
3.树立安全部门的权威，项目必须由安全部门审核完成后才能发布
4.将技术方案写入开发、测试的工作手册中
5.给工程师培训安全方案
6.记录所有的安全bug，激励程序员编写安全的代码
四、与SAMM对比
五、常用SDL实施方法和工具
1、需求分析与设计阶段
#1:BUSINESS REQUIREMENTS
#1:业务需求
#2：INRASTRUCTURE REQUIREMENTS
内部结构要求
#3：APPLICATION REQUIREMENTS
应用程序要求
#4:SECURITY PROGRAM REQUIREMENTS
安全程序要求
2.开发阶段
(1)提供安全的函数
(2)代码安全审计工具
(3)测试阶段
六、敏捷SDL
七、软件安全开发流程新增的安全活动
八、附件《安全选项表》
一、微软SDL(Security Development Lifecycle)流程框架
安全保证的过程，重点是软件开发，但每个阶段都引入了安全和隐私的原则。
二、主要步骤
1.安全培训Training
1.1 Core Security Training核心安全培训
提高团队安全意识，对齐安全需求。
开发团队的所有成员都需要接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员，测试人员、项目经理、产品经理等。项目的中期可开展针对性的培训，例如代码中经常出现的问题，测试过程中多次出现的漏洞等等。
2.需求分析Requirements
针对系统业务要求实施风险评估工作，根据需求文档与项目经理确定安全需求，制定安全需求表，供后期检测时使用。
2.1 建立安全需求分析Establish Security Requirements
在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。
2.2 创建质量标准及Bug栏Create Quality Gates/ Bug Bars
用于确定安全和隐私质量的最低可接受级别，在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全bug。项目团队必须协商确定每个开发阶段的质量门，随后将质量门交由给安全顾问审批，安全顾问可以根据需要添加特定于项目的说明，以及更加严格的安全要求。另外，项目团队需阐明其对安全门的遵从性，以便完成最终安全评析（FSR）。
Bug栏是应用于整个开发项目的质量门，用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定，便决不能放松。
2.3 安全&隐私风险评估（SRA&PRA）
Security & Privacy Risk Assessment
- 项目的哪些部分在发布前需要威胁模型
- 项目的哪些部分在发布前需要进行安全设计评析
- 项目的哪些部分需要不属于项目团队且双方认可的小组进行渗透测试
- 是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险
- 模糊测试的具体范围
- 隐私对评级的影响
3.系统设计Design
3.1 制定设计规范Establish Design Requirements
在设计阶段应该仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。
3.2 分析攻击面Analyze Attack Surface
减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险。方法包括：关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能进行分层防御。
3.3 威胁建模Threat Modeling
为项目或产品面临的威胁建立模型，明确分析攻击可能来自哪里。微软提出的STRIDE模型以帮助建立危险模型，是非常好的做法，从6个维度展开：
Spoofing（假冒）
Tampering（篡改）
Repudiation（否认）
Information Disclosure（信息泄漏）
Denial of Service（拒绝服务）
Elevation of Privilege（权限提升）。
其他主流威胁建模框架见文章《威胁建模主流框架》
4.实现Implementation
4.1 使用优选工具Use Approved Tools
开发团队使用的编辑器、链接器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。
4.2 消减危险函数Deprecate Unsafe Functions
许多常用函数可能存在安全隐患，应当禁用不安全的函数API，使用安全团队推荐的函数。
4.3 对代码进行静态安全检查（静态分析）Static Analysis
代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合。
5.验证Verification
5.1 动态安全测试Dynamix Analysis
动态分析是静态分析的补充，用于测试环节验证程序的安全性。
5.2 模糊测试Fuzz Testing
专门形态的动态分析，通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试，或者扩大模糊测试的范围，增加持续的时间。
5.3 供给面评审Attack Surface Review
项目经常会因为需求等因素导致最终的产出偏离原本设定的目标，因此在项目后期对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。
所有新项目上线前要经过三步检查——代码审计、Web应用扫描、人工渗透扫描。
代码审计：使用Jekens拉Github代码放入Fortify中扫描。开发过程中，开发人员每次更新代码都要进行扫描，并有权限查看Fortify相关项目漏洞情况，进行整改（不允许有中高危以上漏洞）。开发有权对漏洞进行忽略处理，但需要承担相应后果。若不知道如何处理，可以请安全组提供解决方案。
Web应用扫描：Web应用扫描不需要安全基础即可操作。安全人员比测试人员少，一般交予测试人员协助处理。扫描器可选择项很多，包括开源或者商用。
人工渗透扫描：针对不同应用的发布情况，若是应用为新应用则需要对总体项目进行渗透测试。
6.发布Release
6.1 制定安全应急响应计划Incident Response Plan
受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。
6.2 最终安全评审（FSR）Final Security Review
FSR是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同结果：
- 通过FSR。在FSR过程中确定所有安全和隐私问题都以得到修复或缓解。
- 通过FSR但有异常。在FSR过程中确定的所有安全和隐私问题都以得到修复或缓解，并且/或者所有异常都已得到圆满解决，无法解决的问题将记录下来，在下次发布时更正。
- 需上报问题的FSR。如果团队未满足所有SDL要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可解决的问题，或者上报高级管理层进行抉择。
6.3 发布归档Release Archive
在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各种问题和文档进行存档，为紧急响应和产品升级提供帮助。
7.响应Response
Execute Incident Response Plan执行安全应急响应计划。
三、SDL实战经验准则
1.与项目经理进行充分沟通，排除足够的时间
项目的安全评估，在开发的不同环节有着不同的安全要求，而这些安全要求都需要占用开发团队的时间，因此在立项阶段与项目经理进行充分沟通十分重要。
明确在什么阶段安全工程师需要介入，需要多长时间完成安全工作，同时预留多少时间给开发团队用以开发安全功能或者修复安全漏洞。
预留出必要时间对项目的时间管理也具有积极意义，否则很容易出现项目快发布，安全团队突然说还没有实施安全检查的情况。这种情况只能导致两种结果：项目因为安全检查而延期发布，开发团队、测试团队全员一起重新做安全检查；项目顶着风险发布，专门建立小项目专门修复安全问题。
两种结果都十分糟糕，为避免发生此类情况，在立项初期就应该与项目经理进行充分沟通，留出足够多的时间给安全检查。
2.规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏
安全事件产生的原因并不复杂，往往发生在大家忽略的地方。在实施SDL的过程中，技术方案的好坏不是最关键的，最关键的是要覆盖到全部项目，防止边边角角的小项目没有被覆盖到导致安全事件的发生。
公司规模较小时，员工沟通成本低，很容易保证所有项目都能及时通知到安全团队。但公司大到一定规模时，出现多个部门和多个项目组，沟通成本大大增加，这种情况下就很有必要从公司层面建立完善的“立项制度”。
SDL依托于软件工程，立项也属于软件工程的一部分。如果能集中管理立项过程，SDL就有可能在这一阶段覆盖到公司所有项目。相对于测试阶段和发布阶段来说，在立项阶段就有安全团队介入，留给开发团队的反应事件也更加富足。
3.树立安全部门的权威，项目必须由安全部门审核完成后才能发布
实施SDL的过程中，除了教育项目组成员（项目经理、产品经理、开发人员、测试人员等）实施安全的好处外，安全部门还需要树立一定的权威。
必须通过规范和制度，明确要求所有项目必须在安全审核完成后才能发布。如果没有这样的权威，对于项目组来说，安全就变成了一项可有可无的东西。如果产品急着发布，很可能因此砍掉或裁减部分安全需求，也可能延期修补漏洞，从而导致风险升高。
权威的树立在公司里需要从上往下推动，由技术总负责人或者产品总负责人确认安全部门实施。在具体实施时可以依据公司的不同情况在相应的流程中明确。负责产品的质量保障部门，负责产品发布的运维部门，都可以称为制度的执行者。
“项目必须由安全部门审核完成之后才能发布”这句话并非绝对，背后含义实为树立安全部门的权威。因此在实际实施SDL的过程中，安全也可能对业务妥协。因此在业务时间压力非常大，问题不是很严重的情况下，可以考虑事后再进行修补，或使用临时方案应对紧急情况。安全最终是为业务服务的。
4.将技术方案写入开发、测试的工作手册中
对于开发、测试团队，对工作最有效的约束方式即工作手册。对于开发来说手册即为开发规范。开发规范涉及的方面比较广，如函数名的大小写方式、注释的写法等。（腾讯开源开发安全指南链接如下：腾讯代码安全指南开源，涉及CC++、Go等六门编程语言 – FreeBuf网络安全行业门户）
但开发团队的规范内容鲜有涉及到安全规范，因此与其事后通过代码审核的方式告知开发者代码中存在漏洞，需要修补，不如直接将安全技术方案写入开发者的代码规范当中。比如规定好哪些函数禁用，只能使用哪些函数；或封装好安全功能，在代码规范中注明什么情况下使用什么样的安全API。
对于程序员来说，记住代码规范中的要求远比记住复杂的安全原理要容易得多。一般程序员只需要记住如何使用安全功能即可，无需深究原理。
对于测试人员的要求是相似的。在测试的工作手册中加入安全测试的方法，清楚列出每一个测试用例，每一步实现什么功能，这样一些基础的安全测试就可以交由测试人员完成，最后生成一份安全测试报告即可。
5.给工程师培训安全方案
微软SDL框架中，第一项就是培训。培训的作用不可小视，它是技术方案与执行者之间的调和剂。在准则四中提到，要将安全技术方案最大程度地写入代码规范等工作手册中，但同时要让开发者有机会了解到安全方案地背景，这也是很有意义的，可以通过培训达到这个目的。
培训最重要的目的是在项目开发之前，能够让开发者之傲如何写出安全的代码，从而节约开发成本。如果开发者未经培训，可能在代码审核阶段会被找出非常多的安全bug，修复每一个安全bug都将消耗额外的开发时间；同时开发者若不理解这些开发问题，由安全工程师对每一个问题进行解释和说明也是一份额外的时间支出。
因此在培训阶段贯彻代码规范中的安全需求，可以极大地节约开发时间，对整个项目组都有着积极的意义。
6.记录所有的安全bug，激励程序员编写安全的代码
为了更好地推动项目组写出安全的代码，可以尝试给每个开发团队设立绩效。被发现漏洞最少的团队可以得到奖励，并将结果公布出来。如此，项目组之间将产生竞争氛围，开发者更努力于遵守安全规范，写出安全的代码，还能帮助不断提高开发者的代码质量，形成良性循环。
四、与SAMM对比
相对于微软的SDL，OWASP推出了SAMM（Software Assurance Maturity Model），帮助开发者在软件工程的过程中实施安全。
SAMM与SDL的主要区别在于，SDL适用于软件开发商，他们以贩售软件为主要业务；而SAMM更适用于自主开发软件的使用者，如银行或在线服务提供商。软件开发商的软件工程往往较为成熟，有着严格的质量控制；而自主开发软件的企业组织，则更强调高效，因此在软件工程的做法上也存在差异。
OWASP SAMM | OWASP Foundation
五、常用SDL实施方法和工具
1、需求分析与设计阶段
项目初始阶段，将论证项目的目标、可行性、实现方向等。在需求阶段，安全工程师需要关心产品主要功能上的安全强度和安全体验是否足够，主要需要思考安全功能。在此阶段可以对项目经理、产品经理或者架构师进行访谈，以了解产品背景和技术架构，并给出相应的建议，以下是安全专家Lenny Zeltser给出的一份cheklist
#1:BUSINESS REQUIREMENTS
#1:业务需求
Business Model
商业模型
1.What is the application’s primary business purpose/p>
这款应用的主要业务目的是什么/p>
2.How will the application make money/p>
这款应用如何盈利/p>
3.What are the planned business mlestones for developing or imporving the application/p>
开发或者改进这款应用的业务计划是什么样的/p>
4.How is the application marketed/p>
该应用是如何进行营销的/p>
5.What key benefits does the application offer users/p>
这款应用给用户提供的核心功能是什么/p>
6.What business continuity provisions have been defined for the application/p>
已经为该应用制定了哪些业务连续性规定/p>
7.What geographic areas does the application service/p>
这款应用提供服务的主要地区/p>
Data Essentials
必要数据
1.What data does the application receive, produce and process/p>
这款应用接收、产生、处理了什么数据/p>
2.How can the data be classified into categories according to sensitivity/p>
哪些属于敏感数据/p>
3.How might an attacker benefit from capturing or modifying the data/p>
捕获并修改数据将如何有利于攻击者/p>
4.What data backup and retention requirements have been defined for application/p>
已经为应用制定了哪些数据备份和保留要求/p>
End – Users
终端用户
1.Who are the application’s end – users/p>
哪些人是应用的最终用户/p>
2.How do the end – user interact with the application/p>
最终用户如何与应用交互/p>
3.What security expectations do the end – users have/p>
最终用户有哪些安全期望/p>
Partners
搭档
1.Which third – parties supply data to the application/p>
哪些第三方组织为应用提供数持/p>
2.Which third – parties receive data from the applications/p>
哪些第三方组织从应用中收集数据/p>
3.Which third – parites process the application’s data/p>
哪些第三方组织处理应用数据/p>
4.What mechanisms are used to share data with third – parties besides the application itself/p>
除了应用本身，还有那些机制被用来和第三方共享数据/p>
5.What security requirements do the partners impose/p>
合作伙伴实施了哪些安全要求/p>
Administrators
管理层
1.Who has administrative capabilities in the application/p>
谁对应用有着管理员权限/p>
2.What administrative capabilities does the application offer/p>
应用提供哪些管理员权限功能/p>
Regulations
规章制度
1.In what industries does the application operate/p>
该应用在哪些行业中使用/p>
2.What security – related regulations apply/p>
适用哪些与安全相关的法规/p>
3.What auditing and compliance regulations apply/p>
适用于哪些审计和法规/p>
#2：INRASTRUCTURE REQUIREMENTS
内部结构要求
Network
网络
1.What details regarding routing, switching, firewalling, and l
来源：Zichel77
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！