安全开发周期，即Security Development Lifecycle(SDL),是微软提出的从安全角度指导软件开发过程的管理模型。SDL不是一个空想的理论模型。它是微软为了面对现实世界中安全挑战，在实践中的一步步发展起来的软件开发模式。
典型的软件开发流程中，如瀑布模型，中心围绕着产品功能，完全没有安全方面的考虑。这样的开发流程可以造就功能上相对完善的软件，但是无法满足在安全上的需要。由于软件开发过程中未进行任何有效的安全控制措施，导致软件开发国恒中未进行任何有效的安全控制措施，导致软件开发后由于固有的安全隐患所引起的安全事件频频发生，给黑客及恶意人员可趁之机，由此导致的经济损失不可估量。
虽然目前企业和组织已经逐步意识到软件安全的重要性，但是他们目光更多的聚焦到了软件开发后的漏洞扫描或渗透测试，尽管这个过程能够发现和解决大多数的安全隐患，但是后期的安全评估和安全整改，将带来更大的成本投入和人力投入；甚至由于软件开发人员的流动导致许多安全漏洞无法得到解决。据美国国家标准局（NIST）早年发表的一份调查报告估计，更好的安全控制措施将为后期安全整改的总体成本节省三分之一以上的费用，且有效规避70%以上由于软件安全隐患所引发的安全事件。
安全开发生命周期 (SDL) 是侧重于软件开发的安全保证过程 ，SDL 致力于减少设计，开发中软件的漏洞数量和严重性问题。通过预防、检测和监控措施相结合的方式，从而降低应用安全开发和维护的总成本，保证系统的安全性。
产品线安全经理：推动和协调产品线与安全研发部工程师共同完成SDL流程，负责产品线SDL流程的推动落地，并对执行过程进行安全把控;
规划人员：做好安全规划，将安全需求分配到版本落地;
项目经理 :在项目中严格推动和落实SDL流程，是产品安全质量的关键负责人 架构师/设计人员/:预使用组件的安全、合规选型、威胁建模与安全设计等相关工作;
开发人员:严格遵守公司的安全编码规范，并完成相关的安全活动 安全研发部 安全工程师：负责产品的安全测试用例设计、源代码安全审计、渗透测试等一些列的安全活动的执行;
测试经理：负责产品转测前、预发布的安全把控工作 SQA：对SDL流程的执行过程进行安全检视
一、规划阶段
控制目标
开发团队的所有成员都必须接受适当的安全培训，了解安全基础知识以及安全和隐私漏洞方面的最新趋势，树立安全风险意识。培训对象包括开发人员、测试人员、项目经理、产品经理等。
控制措施
(1)制定强制性的最低的培训周期；设定最低培训门槛（例如：在项目开始之前100%的项目开发员工都必须接受培训）；
(2)安全不是一成不变的，应对开发人员进行持续不断的培训；
(3)培训内容应包括基本安全知识培训（针对开发，测试人员）和高级安全知识培训（针对产品经理，核心开发人员），课程包括安全技术、安全意识及安全规范，形式包括内部培训和外部机构、专家培训（如OWASP安全开发生命周期（SDL）培训）；
(4)培训结束后应进行考核，考核成绩应记入人员绩效考核成绩；
输入 培训教材 培训考卷
输出 培训记录表 考核成绩记录表
二、需求分析阶段
控制目标
在项目执行之初就要考虑安全问题，确定应用程序安全方面的需求
控制措施
(1)进行需求开发活动时，项目人员应考虑该系统的业务特点，识别系统的安全需求，并文档化形成安全基线 ，通常包括用户操作日志的保存、审计和查询、用户帐户管理、帐户资源配额、消 息内容对管理人员是否可见、帐号和密码的保存形式（明文或密文）等；
(2)建立每个开发阶段的质量门（如必须在check in 代码之前会审并修复所有编译器警告），确定最低BUG标准（如不允许有SQL注入、XSS 、文件上传 、CSRF 、Open Redirect (url跳转) ）；
(3)还应进行风险评估，明确针对业务上可能面临的较大的业务安全风险（如资金损失、交易事务一致性被破坏）；
(4)需求分析或需求规格应和业务代表确认，确保项目组和业务对需求的理解保持一致.
输入 应用程序安全需求表 质量门checklist 风险评估
输出 XX应用程序安全需求表 XX应用系统质量门checklist XX应用系统安全风险列表
三、设计阶段
控制目标
将识别出的信息系统安全需求落实到应用技术框架及结构设计中，并形成相关规范
控制措施
(1) 制定安全设计规范，包括通用型安全设计规范和针对特定系统的业务安全设计规范。规范内容通常包括加密技术的使用、敏感数据文件长期备份以及恢复措施、数据库明文或加密存储等安全级别、评估第三方软件的许可等；
(2)制定安全部署方案，包括网络环境、系统环境、中间件、数据库、安全防护措施、开放端口、第三方接口、软件版本等内容；；
(3)进行ASA(Attack Surface Analysis，受攻击面分析)，制定ASR(Attack Surface Reduction，受攻击面降低)措施
(4)进行威胁分析，建立威胁模型，帮助理解系统中潜在的安全威胁，明确风险并建立相应消减机制；
输入 安全设计规范 安全部署方案（含安全配置基线） 威胁分析模型
输出 XX系统安全设计规范 XX系统安全部署方案（含安全配置基线） XX系统威胁分析模型
四、开发阶段
控制目标
确保安全设计规范中描述的安全控制设计、方案及威胁消减原则在开发过程中得以贯彻执行
控制措施
(1)充分了解并建立可靠的安全开发工具库（包括语言、虚拟机、IDE环境、引用的第三方工具包）；
(2)制定安全开发最佳实践，指导开发人员进行安全编码；
(3) 建立安全开发规范；
(4) 建立常见安全漏洞、不安全函数、危险的API列表；
输入 安全开发工具清单 安全开发规范 安全开发最佳实践 安全开发培训
输出 安全开发工具库 安全开发培训考卷 常见安全漏洞、不安全函数、危险的API列表(建立工具库不断积累)
五、测试阶段
控制目标
评估安全设计、威胁模型、攻击面消减是否达到了设计的要求。应用程序经常会严重偏离在软件开发项目要求和设计阶段所制定的功能和设计规范，因此，在应用程序完成编码后重新进行评估其是非常重要的。
控制措施
(1) 对应用程序进行白盒测试，通过对代码进行静态安全审计，发现系统的安全漏洞和风险；
(2) 对应用程序进行黑盒测试， 通过模拟的攻击渗透测试，发现系统的安全漏洞和风险；
(3) 录制项目功能流程，遍历项目在威胁模型中涉及到功能或流程，测试其输入输出数据在内存或其它场景下产生的变化，发现可能存在的安全漏洞；
(4)对应用程序进行性能压力测试，通过测试发现系统的性能瓶颈，验证是否达到设计的指标， 发现系统中可能被恶意用户利用的业务RDS漏洞；
输入 安全测试方案
输出 代码审计报告 渗透测试报告 压力测试报告 安全整改方案
相关工具 代码审计软件 渗透测试软件
六、发布阶段
控制目标
在项目正式上线前确认各方面安全要求已经满足，并经过正式评审可以发布
控制措施
(1)制定安全应急响应预案，建立应急响应流程/处理列表；
(2)对照“系统安全部署方案”对网络拓扑，网络设备，安全设备，操作系统，Web和中间件服务器，数据库，其它第三方服务应用等进行安全配置，以达到方案中的要求；
(3)建立上线审核机制，进行最终安全评审，在软件或项目发布之前根据质量门、设计规范进行评审确定是否正式发布；
输入 通用应急响应预案 安全配置基线 上线评审制度、流程、质量门要求
输出 应急响应计划 运维规范（包括上线审核制度）
相关工具 安全配置基线
业务系统上线后做好版本控制、安全合规基线标准控制，形成常态化安全运维管控机制
控制目标
确定项目上线后的安全运维，保证系统安全的持续性
控制措施
(1)开展安全监控运维，从各层次监控应用系统安全状况；
(2)开展安全巡检运维，定期检查系统各层次（OS、DB、中间件、网络等）安全配置变化情况，并根据安全基线予以修正；
(3)开展安全扫描运维，定期对系统进行OS、应用进行漏洞扫描和渗透测试，发现最新漏洞并予以修正；
(4)建立应急事件响应程序，对系统发生的安全事件予以响应处置；
输入 安全巡检手册 安全漏洞管理制度
输出 应急响应流程 安全运维规范（包括扫描、巡检、监控制度）
相关工具 安全配置基线
