安全开发生命周期详解（SDL：Security Development Lifecycle）

Posted 2021-08-29 虎子

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

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

1、培训

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

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

2、安全要求

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

3、质量门/bug 栏

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

4、安全和隐私风险评估

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

5、设计要求

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

6、减小攻击面

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

7、威胁建模

微软的 STRIDE 模型

8、使用指定的工具

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

9、弃用不安全的函数

禁用不安全的函数或 API

10、静态分析

可以由工具辅助完成

11、动态分析

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

12、模糊测试

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

13、威胁模型和攻击面评析

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

14、事件响应计划

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

15、最终安全评析

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

16、发布/存档

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

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

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

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

 敏捷 SDL

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

 互联网公司 SDL 实践经验

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

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

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

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

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

准则六、记录所有的安全 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 安全扫描器，性能优异，可以用于二次开发。

分类: InternetSecurityv