安全开发流程（SDL）

SDL：Security Development Lifecycle 安全开发生命周期

培训	要求	设计	实施	验证	发布	响应
核心安全培训	肯定安全要求 建立质量门/错误标尺 安全和隐私风险评估	肯定设计要求 分析攻击面 威胁建模	使用批准的工具 弃用不安全的函数 静态分析	动态分析 模糊测试 攻击面评析	事件响应计划 最终安全评析 发布存档	执行事件响应计划

一、培训

培训对象：开发人员、测试人员、项目经理、产品经理

培训内容：安全设计、威胁建模、安全编码、安全测试、隐私等

二、安全要求

项目确立前与项目经理或产品全部者进行沟通，肯定安全的要求。

三、质量门/bug 栏

质量门和 bug 栏用于肯定安全和隐私质量的最低可接受级别。项目团队必须协商肯定每一个开发阶段的质量门。bug 栏是应用于整个软件开发项目的质量门，用于定义安全漏洞的严重性阈值。

四、安全和隐私风险评估

安全风险评估（SRA）和隐私风险评估（PRA）用于肯定软件中须要深刻评析的功能环节。包括 ① 项目的哪些部分在发布前须要创建威胁模型？② 哪些部分在发布前须要进行安全设计评析？③ 哪些部分须要由不属于项目团队且双方承认的小组进行渗透测试？④ 是否存在安全顾问认为有必要增长的测试或分析？⑤ 模糊测试的具体范围？⑥ 隐私对评级的影响。

五、设计要求

在设计阶段仔细考虑安全和隐私问题。

六、减少攻击面

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

七、威胁建模

微软的 STRIDE 模型

八、使用指定的工具

开发团队使用的编译器、连接器等工具及其版本应由安全团队肯定安全性。

九、弃用不安全的函数

禁用不安全的函数或 API

十、静态分析

能够由工具辅助完成

十一、动态分析

在测试环节验证程序安全性

十二、模糊测试

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

1三、威胁模型和攻击面评析

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

1四、事件响应计划

每一个软件在发布时都必须包含事件响应计划。尤为若是产品中包含第三方的代码，要求留下第三方的联系方式并加入事件响应计划。

1五、最终安全评析

在产品发布以前对软件执行的安全活动。

1六、发布/存档

在经过最终安全评析后能够完成产品的发布。同时，对各种问题和文档进行存档，为紧急响应和产品升级提供帮助。

 

SAMM：Software Assurance Maturity Model，OWASP 推出的软件认证成熟模型 

参考连接：http://www.opensamm.org/

 

SDL 适用于软件开发商，他们以贩售软件为主要业务；SAMM 适用于自主研发软件的组织，如银行、在线服务提供商。软件开发商的软件工程比较成熟，有严格的质量控制；而自主开发软件的企业组织更强调效率。

 

 敏捷 SDL

 对于使用敏捷开发的团队，需求和功能一直在变化，代码也在发生变化，这要求在实施 SDL 的过程当中在每一个阶段更新威胁模型和隐私策略，在必要的缓解迭代模糊测试、代码安全分析等工做。

 

 互联网公司 SDL 实践经验

准则1、与项目经理进行充分沟通，排出足够时间

准则2、规范公司的立项流程，确保全部项目都能通知到安全团队，避免遗漏

准则3、树立安所有门的权威，项目必须由安所有门审核完成后才能发布

准则4、将技术方案写入开发、测试的工做手册中

准则5、给工程师培训安全方案

准则6、记录全部的安全 bug，激励程序员编写安全的代码

 

产品研发阶段的安全

需求分析与设计阶段

需求分析阶段能够对项目经理，产品经理或架构师进行访谈，了解产品背景和技术架构，并给出相应的建议。

应该了解项目中是否包含了第三方软件，认真评估第三方软件是否存在安全问题。规避第三方软件带来的安全风险。

参考连接：https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet

 

开发阶段

提供安全的函数

OWASP 的开源项目 OWASP ESAPI 为安全模块的实现提供了参考。若是开发者没有把握实现一个足够好的安全模块，最好参考 OWASP ESAPI 的实现方式。（其中 Java 版本最为完善）。

不少安全功能能够放到开发框架中实现，这样能够大大下降程序员的开发工做量。

定制开发者的开发规范，并将安全技术方案写进开发规范中，让开发者牢记。在代码审计阶段，能够经过白盒扫描的方式检查变量输出是否使用了安全的函数。将安全方案写入开发规范中让安全方案实际落地，不只方便开发者写出安全的代码，同时为代码审计带来方便。

代码安全审计工具

常见的代码审计工具对复杂项目的审计效果很差：① 函数调用是个复杂的过程，当审计工具找到敏感函数时，回溯函数的调用路径经常会遇到困难；② 若是程序使用了复杂框架，代码审计工具每每因为缺少对框架的支持，从而形成误报或漏报。

代码自动化审计工具的一个思路：找到全部可能的用户输入入口，而后跟踪变量的传递状况，看变量最后是否会走到危险函数。

对于甲方公司来讲，能够根据开发规范来定制代码审计工具 —— 并不是直接检查代码是否安全，而是检查开发者是否遵照了开发规范。

测试阶段

安全测试应该独立于代码审计。有些代码逻辑较为复杂，经过代码审计难以发现全部问题，而经过安全测试能够将问题看清楚；有些逻辑漏洞经过安全测试能够更快地获得结果。

安全测试分为自动化测试和手动测试两种。

自动化测试能够经过 web 安全扫描器对项目或产品进行漏洞扫描：XSS、SQL  Injection、Open Redirect、PHP File Include；CSRF、越权访问、文件上传等漏洞因为涉及系统逻辑或业务逻辑，有时须要人机交互参与页面流程，所以须要依靠手动的方式完成测试。

skipfish 是 Google 使用的一款 Web 安全扫描器，性能优异，能够用于二次开发。