安全开发生命周期（Security Development Lifecycle，SDL），将安全的考虑集成在软件开发的每一个阶段，利用威胁模型改进安全流程。基于对各厂商的SDL实践研究，绿盟科技以安全厂商的视角，凭借自身在安全评估、渗透测试、代码审计等领域的积累，推出绿盟SDL解决方案-ADSL，为客户的安全开发落地实践提供有力支撑。
一、SDL的意义
SDL使设计、代码和文档中与安全相关的漏洞减到最少，在软件开发的生命周期中尽可能早地清除漏洞。SDL是一种规范，指导，约束。由人制定，监管，执行。但SDL不是万能的。
二、各厂SDL实践
2.1、 Juniper Networks
Juniper Networks安全开发生命周期(SDL)是开发安全且永续的产品的流程。Juniper Networks的 SDL 计划由六个核心实践组成。
实践1：安全编码培训
安全编码培训是实施安全开发生命周期的第一步。所有Juniper Networks软件开发人员都必须参加此培训，这是构建弹性更高的软件的基础。培训提供多种编码语言版本，各开发人员可以参加相应的课程。
安全编码培训涵盖与安全编码、安全设计、安全测试和隐私有关的基本概念。
Juniper Networks相信，参与软件开发的每一个人都要为软件产品的安全性负责。这其中包括经理、项目经理、测试人员和IT人员。考虑到这一点，安全开发生命周期培训将全天候对所有员工开放，此外还提供一系列涵盖安全编码基础的其他培训。
实践2：设计中的安全考虑事项
定义Juniper Networks工程师和产品经理在产品开发的规划阶段必须采用的安全相关步骤。在此阶段中，工程师和产品经理必须在Juniper Networks规划文档（例如功能规范和产品要求文档等）中正式说明安全风险。
实践3：威胁建模
威胁建模评估产品的潜在威胁。威胁建模确定这些威胁造成的风险，并界定一系列适当的缓解措施。
威胁模型将帮助开发人员定义产品攻击表面，即入侵威胁的宽度和深度。例如，弱密码可能会被暴力破解攻击所利用，使用可预测的TCP/IP临时端口，可能允许攻击者启动TCP重置攻击。
威胁建模通过识别和枚举问题构建深度安全评估框架。
实践4：渗透测试
确定产品的安全状况之后，Juniper Networks的SDL通过渗透测试发起安全风险评估和验证。渗透测试是一种安全评估方法，由文明的黑客模拟实际攻击，以确定绕开应用程序、系统或网络安全功能的方法。其中涉及到利用攻击者常用的工具和技术，在测试系统上启动实际攻击。
渗透测试利用威胁模型，基于枚举出的攻击表面和威胁设计渗透测试计划。
实践5：发布安全审核
发布安全审核即在产品发布之前检查产品的安全状况，目的在于确定和评估残余的安全风险和SDL所有部分的发现结果。结果应为整体安全状态，不仅包括软件发布，还包括制作软件并负责支持其整个生命周期的的人员、系统以及流程。
实践6：事件响应计划
发布时无已知漏洞的产品随着时间推移会成为威胁主体。事件响应计划概述Juniper Networks如何响应潜在产品漏洞，以及如何将这些威胁和规避措施告知客户。
此实践以Juniper Networks获得业界尊重的Juniper Networks安全事件响应团队（Juniper Networks SIRT）框架为基础，从而响应安全问题。在响应安全事件时，计划依靠现有SIRT工具、最佳实践、流程和关系。
2.2、Microsoft SDL 优化模型
将安全开发概念整合到现有开发过程时，如果方式不当，可能会造成不利的局面且成本高昂。成功还是失败通常取决于组织规模、资源（时间、人才和预算）以及高层支持等因素。理解良好安全开发实践的要素，根据开发团队的成熟度水平确定实施优先级，可以控制这些无形因素的影响。Microsoft 创建了 SDL 优化模型，以帮助解决这些问题。
SDL优化模型围绕五个功能领域构建，这些领域大致与软件开发生命周期的各个阶段相对应：
- 培训、政策和组织功能
- 要求和设计
- 实施
- 验证
- 发布和响应
流程图如下所示：
SDL实施前要求：安全培训
实践1：培训要求
软件开发团队的所有成员都必须接受适当的培训，了解安全基础知识以及安全和隐私方面的最新趋势。直接参与软件程序开发的技术角色人员（开发人员、测试人员和程序经理）每年必须参加至少一门特有的安全培训课程。
基本软件安全培训应涵盖的基础概念包括：
安全设计，包括以下主题：
- 减小攻击面
- 深度防御
- 最小权限原则
- 安全默认设置
威胁建模，包括以下主题：
- 威胁建模概述
- 威胁模型的设计意义
- 基于威胁模型的编码约束
安全编码，包括以下主题：
- 缓冲区溢出（对于使用 C 和 C++ 的应用程序）
- 整数算法错误（对于使用 C 和 C++ 的应用程序）
- 跨站点脚本（对于托管代码和 Web 应用程序）
- SQL 注入（对于托管代码和 Web 应用程序）
弱加密安全测试，包括以下主题：
- 安全测试与功能测试之间的区别
- 风险评估
- 安全测试方法
隐私，包括以下主题：
- 隐私敏感数据的类型
- 隐私设计最佳实践
- 风险评估
- 隐私开发最佳实践
- 隐私测试最佳实践
第一阶段：要求
实践2：安全要求
“预先”考虑安全和隐私是开发安全系统过程的基础环节。为软件项目定义信任度要求的最佳时间是在初始计划阶段。尽早定义要求有助于开发团队确定关键里程碑和交付成果，并使集成安全和隐私的过程尽量不影响到计划和安排。对安全和隐私要求的分析在项目初期执行，所做工作涉及为设计在计划运行环境中运行的应用程序确定最低安全要求，并确立和部署安全漏洞/工作项跟踪系统。
实践3：质量门/Bug栏
质量门和Bug栏用于确立安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全Bug。项目团队必须协商确定每个开发阶段的质量门（例如，必须在签入代码之前会审并修复所有编译器警告），随后将质量门交由安全顾问审批。安全顾问可以根据需要添加特定于项目的说明以及更加严格的安全要求。另外，项目团队须阐明其对商定安全门的遵从性，以便完成最终安全评析。
实践4：安全和隐私风险评估
安全风险评估和隐私风险评估是必需的过程，用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息：
1.（安全）项目的哪些部分在发布前需要威胁模型？
2.（安全）项目的哪些部分在发布前需要进行安全设计评析？
3.（安全）项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试？
4.（安全）是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险？
5.（安全）模糊测试要求的具体范围是什么？
6.（隐私）隐私影响评级如何？
第二阶段：设计
实践5：设计要求
影响项目设计信任度的最佳时间是在项目生命周期的早期。在设计阶段应仔细考虑安全和隐私问题，这一点至关重要。如果在项目生命周期的开始阶段执行缓解措施，则缓解安全和隐私问题的成本会低得多。项目团队应避免到项目开发将近结束时再“插入”安全和隐私功能及缓解措施。
此外，项目团队还必须理解“安全的功能”与“安全功能”之间的区别。实现的安全功能实际上很可能是不安全的。“安全的功能”定义为在安全方面进行了完善设计的功能，比如在处理之前对所有数据进行严格验证或是通过加密方式可靠地实现加密服务库。“安全功能”描述具有安全影响的程序功能，如 Kerberos 身份验证或防火墙。
设计要求活动包含一些必需行动。示例包括创建安全和隐私设计规范、规范评析以及最低加密设计要求规范。设计规范应描述用户会直接接触的安全或隐私功能，如需要用户身份验证才能访问特定数据或在使用高风险隐私功能前需要用户同意的那些功能。此外，所有设计规范都应描述如何安全地实现给定特性或功能所提供的全部功能。针对应用程序的功能规范验证设计规范是个好做法。功能规范应：
- 准确完整地描述特性或功能的预期用途。
- 描述如何以安全的方式部署特性或功能。
实践6：减小攻击面
减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问、应用最小权限原则以及尽可能进行分层防御。
实践7：威胁建模
威胁建模用于存在重大安全风险的环境之中。这一实践使开发团队可以在其计划的运行环境的背景下，以结构化方式考虑、记录并讨论设计的安全影响。通过威胁建模还可以考虑组件或应用程序级别的安全问题。威胁建模是一项团队活动（涉及项目经理、开发人员和测试人员），并且是软件开发设计阶段中执行的主要安全分析任务。
第三阶段：实施
实践8：使用批准的工具
所有开发团队都应定义并发布获准工具及其关联安全检查的列表，如编译器/链接器选项和警告。此列表应由项目团队的安全顾问进行批准。一般而言，开发团队应尽量使用最新版本的获准工具，以利用新的安全分析功能和保护措施。
实践9：弃用不安全的函数
许多常用函数和 API 在当前威胁环境下并不安全。项目团队应分析将与软件开发项目结合使用的所有函数和 API，并禁用确定为不安全的函数和 API。确定禁用列表之后，项目团队应使用头文件（如 banned.h 和 strsafe.h）、较新的编译器或代码扫描工具来检查代码（在适当情况下还包括旧代码）中是否存在禁用函数，并使用更安全的备选函数替代这些禁用函数。
实践10：静态分析
项目团队应对源代码执行静态分析。源代码静态分析为安全代码评析提供了伸缩性，可以帮助确保对安全代码策略的遵守。静态代码分析本身通常不足以替代人工代码评析。安全团队和安全顾问应了解静态分析工具的优点和缺点，并准备好根据需要为静态分析工具辅以其他工具或人工评析。
第四阶段：验证
实践11：动态程序分析
为确保程序功能按照设计方式工作，有必要对软件程序进行运行时验证。此验证任务应指定一些工具，用以监控应用程序行为是否存在内存损坏、用户权限问题以及其他重要安全问题。
实践12：模糊测试
模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定以应用程序的预期用途以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试或扩大模糊测试的范围和增加持续时间。
实践13：威胁模型和攻击面评析
应用程序经常会严重偏离在软件开发项目要求和设计阶段所制定的功能和设计规范。因此，在给定应用程序完成编码后重新评析其威胁模型和攻击面度量是非常重要的。此评析可确保考虑到对系统设计或实现方面所做的全部更改，并确保因这些更改而形成的所有新攻击平台得以评析和缓解。
第五阶段：发布
实践14：事件响应计划
受 SDL 要求约束的每个软件发布都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的程序也可能面临日后新出现的威胁。事件响应计划应包括：
单独指定的可持续工程团队；或者，如果团队太小以至于无法拥有可持续工程团队资源，则应制定紧急响应计划，在该计划中确定相应的工程、市场营销、通信和管理人员充当发生安全紧急事件时的首要联系点。
- 与决策机构的电话联系（7 x 24 随时可用）。
- 针对从组织中其他小组继承的代码的安全维护计划。
- 针对获得许可的第三方代码的安全维护计划，包括文件名、版本、源代码、第三方联系信息以及要更改 的合同许可（如果适用）。
实践15：最终安全评析
最终安全评析是在发布之前仔细检查对软件应用程序执行的所有安全活动。最终安全评析由安全顾问在普通开发人员以及安全和隐私团队负责人的协助下执行。最终安全评析不是“渗透和修补”活动，也不是用于执行以前忽略或忘记的安全活动的时机。最终安全评析通常要根据以前确定的质量门或 Bug 栏检查威胁模型、异常请求、工具 输出和性能。
实践16：发布/存档
发布软件的生产版本还是 Web 版本取决于 SDL 过程完成时的条件。指派负责发布事宜的安全顾问必须证明项目团队已满足安全要求。
此外，必须对所有相关信息和数据进行存档，以便可以对软件进行发布后维护。这些信息和数据包括所有规范、源代码、二进制文件、专用符号、威胁模型、文档、紧急响应计划、任何第三方软件的许可证和服务条款以及执行发布后维护任务所需的任何其他数据。
三、绿盟SDL方案-ADSL
基于对各厂商的SDL实践研究，绿盟科技以安全厂商的视角，凭借自身在安全评估、渗透测试、代码审计等领域的积累，推出绿盟SDL解决方案-ADSL，为客户的安全开发落地实践提供有力支撑。
绿盟ADSL解决方案，完全贴合安全开发生命周期（SDL）,主要涉及部门为开发和运维科，具体如下：
安全需求：
安全需求主要从安全标准和最佳实践两方面得出，安全标准包括企业内部标准、行业标准、等级保护测评指南、ISO 27000等；最佳实践则从OWASP Development Guide、OWASP Testing Guide、OWASP Code Review Guide、项目积累知识库等方面出发。
安全设计：
安全设计主要根据威胁建模结果，制定安全控制措施，抵御或降低安全威胁。
设计中遵循的原则包括：最小权限、权限分离、深度防御、安全容错、经济原则、开放设计、最少启用、心里接受、组件重用、薄弱环节等。
绿盟安全设计实践包括：数据验证、认证管理、会话管理、授权管理、日志审计、异常处理、配置管理、数据加密等。
安全编码：
安全编码针对安全设计出发，对不同编程语言定制安全编码规范，通过安全编码规范的约束，使开发人员能够养成良好的编程习惯，减少系统安全漏洞的发生。
同时针对编码规范做开发人员的安全编码培训，提升安全意识，避免编码中出现安全漏洞。
安全测试：
安全测试阶段主要包括两部分内容：1、安全测试用例专项安全功能测试，2、测试环境中的渗透测试。
测试用例主要是针对各项安全设计做安全功能测试，因安全功能与业务的强相关性，绿盟以测试用例的方式交付客户，并指导客户完成相应测试。渗透测试则在测试集成环境下做黑盒测试，以发现应用在实际运行中的问题。
上线测试：
业务实际上线前，需对整个业务运行环境做安全评估，评估内容包括：web类应用扫描、业务承载环境扫描、基线核查等。
安全运行：
成功上线后，针对业务系统需做持续的安全监测和应急响应，并周期性的进行安全评估，做到对业务资产的持续态势感知。