安全开发流程（SDL）
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、越权访问、文件上传等漏洞由于涉及系统逻辑或业务逻辑，有时需要人机交互参与页面流程，因此需要依靠手动的方式完成测试。