安全开发流程，能够帮助企业以最小的成本提高产品的安全性。它符合“Secure at theSource”的战略思想。实施好安全开发流程，对企业安全的发展来说，可以起到事半功倍的效果。
SDL的全称是 Security Development Lifecy-cle，即：安全开发生命周期。它是由微软最早提出的，在软件工程中实施，是帮助解决软件安全问题的办法。SDL是一个安全保证的过程，其重点是软件开发，它在开发的所有阶段都引入了安全和隐私的原则。自2004年起，SDL一直都是微软在全公司实施的强制性策略。SDL的大致步骤如下：
SDL中的方法，试图从安全漏洞产生的根源上解决问题。通过对软件工程的控制，保证产品的安全性。
SDL对于漏洞数量的减少有着积极的意义。根据美国国家漏洞数据库的数据显示，每年发现的漏洞趋势有以下特点：每年有数千个漏洞被发现，其中大多数漏洞的危害程度高，而复杂性却反而较低；这些漏洞多出现于应用程序中，易于被利用的漏洞占了大多数。
而美国国家标准与技术研究所（NIST）估计，如果是在项目发布后再执行漏洞修复计划，其修复成本相当于在设计阶段执行修复的30倍。For-rester Research, Inc.和Aberdeen Group研究发现，如果公司采用像Microsoft SDL这样的结构化过程，就可以在相应的开发阶段系统地处理软件安全问题，因此更有可能在项目早期发现并修复漏洞，从而降低软件开发的总成本。
微软历来都是黑客攻击的重点，其客户深受安全问题的困扰。在外部环境不断恶化的情况下，比尔·盖茨在2002年1月发布了他的可信任计算备忘录。可信任计算的启动从根本上改变了公司对于软件安全的优先级。来自高级管理层的这项命令将安全定位为Microsoft 最应优先考虑的事情，为实现持续稳定的工程文化变革活动提供了所需的动力。而SDL就是可信任计算的重要组成部分。
从上图中可以看到，微软的SDL过程大致分为16个阶段（优化后）。
开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识。培训的环节在SDL中看似简单，但其实不可或缺。通过培训能贯彻安全策略和安全知识，并在之后的执行过程中提高执行效率，降低沟通成本。培训对象包括开发人员、测试人员、项目经理、产品经理等。
微软推荐的培训，会覆盖安全设计、威胁建模、安全编码、安全测试、隐私等方面知识。
在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布——这是任何项目经理都讨厌发生的事情。
质量门和bug栏用于确定安全和隐私质量的最低可接受级别。在项目开始时定义这些标准可加强对安全问题相关风险的理解，并有助于团队在开发过程中发现和修复安全bug。项目团队必须协商确定每个开发阶段的质量门（例如，必须在checkin代码之前进行review并修复所有的编译器警告），随后将质量门交由安全顾问审批，安全顾问可以根据需要添加特定于项目的说明，以及更加严格的安全要求。另外，项目团队需阐明其对安全门的遵从性，以便完成最终安全评析（FSR）。
bug栏是应用于整个软件开发项目的质量门，用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。bug栏一经设定，便绝不能放松。
安全风险评估（SRA）和隐私风险评估（PRA）是一个必需的过程，用于确定软件中需要深入评析的功能环节。这些评估必须包括以下信息：
（1）（安全）项目的哪些部分在发布前需要威胁模型？
（2）（安全）项目的哪些部分在发布前需要进行安全设计评析？
（3）（安全）项目的哪些部分（如果有）需要由不属于项目团队且双方认可的小组进行渗透测试？
（4）（安全）是否存在安全顾问认为有必要增加的测试或分析要求以缓解安全风险？
（5）（安全）模糊测试要求的具体范围是什么？
（6）（隐私）隐私影响评级如何？
在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。
减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减少攻击者利用潜在弱点或漏洞的机会来降低风险。减小攻击面包括关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能地进行分层防御。
为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面。微软提出了STRIDE模型以帮助建立威胁模型，这是非常好的做法。
开发团队使用的编译器、链接器等相关工具，可能会涉及一些安全相关的环节，因此在使用工具的版本上，需要提前与安全团队进行沟通。
许多常用函数可能存在安全隐患，应该禁用不安全的函数或API，使用安全团队推荐的函数。
代码静态分析可以由相关工具辅助完成，其结果与人工分析相结合。
动态分析是静态分析的补充，用于测试环节验证程序的安全性。
模糊测试是一种专门形式的动态分析，它通过故意向应用程序引入不良格式或随机数据诱发程序故障。模糊测试策略的制定，以应用程序的预期用途，以及应用程序的功能和设计规范为基础。安全顾问可能要求进行额外的模糊测试，或者扩大模糊测试的范围和增加持续时间。
项目经常会因为需求变更等因素导致最终的产出偏离原本设定的目标，因此在项目后期重新对威胁模型和攻击面进行评析是有必要的，能够及时发现问题并修正。
受SDL要求约束的每个软件在发布时都必须包含事件响应计划。即使在发布时不包含任何已知漏洞的产品，也可能在日后面临新出现的威胁。需要注意的是，如果产品中包含第三方的代码，也需要留下第三方的联系方式并加入事件响应计划，以便在发生问题时能够找到对应的人。
最终安全评析（FSR）是在发布之前仔细检查对软件执行的所有安全活动。通过FSR将得出以下三种不同结果。
通过FSR。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解。
通过FSR但有异常。在FSR过程中确定的所有安全和隐私问题都已得到修复或缓解，并且/或者所有异常都已得到圆满解决。无法解决的问题将记录下来，在下次发布时更正。
需上报问题的FSR。如果团队未满足所有SDL要求，并且安全顾问和产品团队无法达成可接受的折中，则安全顾问不能批准项目，项目不能发布。团队必须在发布之前解决所有可以解决的问题，或者上报高级管理层进行抉择。
在通过FSR或者虽有问题但达成一致后，可以完成产品的发布。但发布的同时仍需对各类问题和文档进行存档，为紧急响应和产品升级提供帮助。
从以上的过程可以看出，微软的SDL过程实施非常细致。微软这些年来也一直帮助公司的所有产品团队，以及合作伙伴实施SDL，效果相当显著。在微软实施了SDL的产品中，被发现的漏洞数量大大减少，漏洞利用的难度也有所提高。
相对于微软的SDL，OWASP推出了SAMM（Software Assurance MaturityModel），帮助开发者在软件工程的过程中实施安全。
SAMM和微软SDL的主要区别在于，SDL适用于软件开发商，他们以贩售软件为主要业务；而SAMM更适用于自主开发软件的使用者，如银行或在线服务提供商。软件开发商的软件工程往往较为成熟，有着严格的质量控制；而自主开发软件的企业组织，则更强调高效，因此在软件工程的做法上也存在差异。
就微软的SDL过程来看，仍然显得较为厚重。它适用于采用瀑布法进行开发的软件开发团队，而对于使用敏捷开发的团队，则难以适应。
敏捷开发往往是采用“小步快跑”的方式，不断地完善产品，并没有非常规范的流程，文档也尽可能简单。这样做有利于产品的快速发布，但是对于安全来说，往往是一场灾难。需求无法在一开始非常明确，一些安全设计可能也会随之变化。
微软为敏捷开发专门设计了敏捷SDL。
敏捷SDL的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化，代码可能也在发生变化，这要求在实施SDL时需要在每个阶段更新威胁模型和隐私策略，在必要的环节迭代模糊测试、代码安全分析等工作。
对于互联网公司来说，更倾向于使用敏捷开发，快速迭代开发出产品。因此微软的SDL从各方面来看，都显得较为厚重，需要经过一些定制和裁剪才能适用于各种不同的环境。
这些年来，笔者根据在公司实施SDL的经验，总结出以下几条准则。
一个项目的安全评估，在开发的不同环节有着不同的安全要求，而这些安全要求都需要占用开发团队的时间。因此在立项阶段与项目经理进行充分沟通是非常有必要的。
明确在什么阶段安全工程师需要介入，需要多程，SDL就有可能在这一阶段覆盖到公司的所有项目。相对于测试阶段和发布阶段来说，在立项阶段就有安全团队介入，留给开发团队的反应时间也更加富足。
预留出必要的时间，对于项目的时间管理也具有积极意义。否则很容易出现项目快发布了，安全团队突然说还没有实施安全检查的情况。这种情况只能导致两种结果：一是项目因为安全检查而延期发布，开发团队、测试团队的所有人都一起重新做安全检查；二是项目顶着安全风险发布，之后再重新建个小项目专门修补安全问题，而在这段时间内产品只能处于“裸奔”状态。
这两种结果都是非常糟糕的，因此为了避免这种情况的发生，在立项初期就应该与项目经理进行充分沟通，留出足够多的时间给安全检查。这是SDL实施成功的基础。
如果根据以往发生的安全事件，回过头来看安全问题是如何产生的，则往往会发现这样一个现象：安全事件产生的原因并不复杂，但总是发生在大家疏忽的一些地方。
在实施SDL的过程中，技术方案的好坏往往不是最关键的，最糟糕的事情是SDL并没有覆盖到公司的全部项目，乃至一些边边角角的小项目发布后，安全团队都不知道，最后导致安全事件的发生。
如何才能保证公司的所有项目都能够及时通知到安全团队呢？在公司规模较小时，员工沟通成本较低，很容易做到这件事情。但当公司大到一定的规模时，出现多个部门与多个项目组，沟通成本就大大增加。在这种情况下，从公司层面建立一个完善的“立项制度”，就变得非常有必要了。
前文提到，SDL是依托于软件工程的，立项也属于软件工程的一部分。如果能集中管理立项过程，SDL就有可能在这一阶段覆盖到公司的所有项目。相对于测试阶段和发布阶段来说，在立项阶段就有安全团队介入，留给开发团队的反应时间也更加富足。
在实施SDL的过程中，除了教育项目组成员（如项目经理、产品经理、开发人员、测试人员等）实施安全的好处外，安全部门还需要树立一定的权威。
必须通过规范和制度，明确要求所有项目必须在安全审核完成后才能发布。如果没有这样的权威，对于项目组来说，安全就变成了一项可有可无的东西。而如果产品急着发布，很可能因此砍掉或者裁减部分安全需求，也可能延期修补漏洞，从而导致风险升高。
这种权威的树立，在公司里需要从上往下推动，由技术总负责人或者产品总负责人确认，安全部门实施。在具体实施时，可以依据公司的不同情况在相应的流程中明确。比如负责产品的质量保障部门，或者负责产品发布的运维部门，都可以成为制度的执行者。
当然，“项目必须由安全部门审核完成后才能发布”，这句话并非绝对，其背后的含义是为了树立安全部门的权威。因此在实际实施SDL的过程中，安全也可能对业务妥协。比如对于不是非常严重的问题，在业务时间压力非常大的情况下，可以考虑事后再进行修补，或者使用临时方案应对紧急状况。安全最终是需要为业务服务的。
对于开发、测试团队来说，对其工作最有效的约束方式就是工作手册。对于开发来说，这个手册可能是开发规范。开发规范涉及的方面比较广，比如函数名的大小写方式、注释的写法等都会涵盖。笔者观察过很多开发团队的规范，其内容鲜有涉及安全的，少量有安全规范的，其内容也存在各种各样的问题。
因此，与其事后通过代码审核的方式告知开发者代码存在漏洞，需要修补，倒不如直接将安全技术方案写入开发者的代码规范中。比如规定好哪些函数是要求禁用的，只能使用哪些函数；或者封装好一些安全功能，在代码规范中注明在什么情况下使用什么样的安全API。
对于程序员们来说，记住代码规范中的要求，远比记住复杂的安全原理要容易得多。一般来说，程序员们只需要记住如何使用安全功能就行，而不必深究其原理。
对于测试人员的要求是类似的。在测试的工作手册中，可以加入安全测试的方法，清楚地列出每一个测试用例，第一步、第二步做什么。这样一些基础的安全测试就可以交由测试人员完成，最后生成一份安全测试报告即可。
在微软的SDL框架中，第一项就是培训。培训的作用不可小视，它是技术方案与执行者之间的调和剂。
在“准则四”中提到，需要将安全技术方案最大程度地写入代码规范等工作手册中，但同时让开发者有机会了解安全方案的背景也是很有意义的事情。通过培训可以达到这个目的。
培训最重要的作用是，在项目开发之前，能够使开发者知道如何写出安全的代码，从而节约开发成本。因为如果开发者未经培训，可能在代码审核阶段会被找出非常多的安全bug，修复每一个安全bug都将消耗额外的开发时间；同时开发者若不能理解这些安全问题，由安全工程师对每个问题进行解释与说明，也是一份额外的时间支出。
因此在培训阶段贯彻代码规范中的安全需求，可以极大地节约开发时间，对整个项目组都有着积极的意义，并不是可有可无的事情。
为了更好地推动项目组写出安全的代码，可以尝试给每个开发团队设立绩效。被发现漏洞最少的团队可以得到奖励，并将结果公布出来。如此，项目组之间将产生一些竞争的氛围，开发者们将更努力于遵守安全规范，写出安全的代码。此举还能帮助不断提高开发者的代码质量，形成良性循环。
以上这六条准则，是笔者在互联网公司中实施SDL的一些经验与心得。互联网公司对产品、用户体验的重视程度非常高，大多数的产品都要求在短时间内发布，因此在SDL的实施上有着自己的特色。
在互联网公司，产品开发生命周期大致可以划分为需求分析阶段、设计阶段、开发阶段、测试阶段。下面将就这几个不同的阶段，介绍一些常用的SDL实施方法和工具。
需求分析阶段与设计阶段是项目的初始阶段。需求分析阶段将论证项目的目标、可行性、实现方向等问题。
在需求阶段，安全工程师需要关心产品主要功能上的安全强度和安全体验是否足够，主要需要思考安全功能。比如需要给产品设计一个“用户密码取回”功能，那么是通过手机短信的方式取回，还是邮箱取回？很多时候，需要从产品发展的大方向上考虑问题。
需要注意的是，在安全领域中，“安全功能”与“安全的功能”是两个不同的概念。“安全功能”是指产品本身提供给用户的安全功能，比如数字证书、密码取回问题等功能。
而“安全的功能”，则指在产品具体功能的实现上要做到安全，不要出现漏洞而被黑客利用。
比如在“用户取回密码”时常用到的功能：安全问题，这个功能是一个安全功能；但若是在代码实现上存在漏洞，则可能成为一个不安全的功能。
在需求分析阶段，可以对项目经理、产品经理或架构师进行访谈，以了解产品背景和技术架构，并给出相应的建议。从以往的经验来看，一份checklist可以在一定程度上帮助到我们。下面是安全专家Lenny Zeltser给出的一份checklist，可以用于参考。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219#1: BUSINESS REQUIREMENTS Business Model What is the application's primary businesspurpose? How will the application make money? What are the planned business milestones fordeveloping or improving the application? How is the application marketed? What key benefits does the application offerusers? What business continuity provisions havebeen defined for the application? What geographic areas does the applicationservice? Data Essentials What data does the application receive, pro-duce, and process? How can the data be classified into categoriesaccording to its sensitivity? How might an attacker benefit from captur-ing or modifying the data? What data backup and retention require-ments have been defined for the application? End‐Users Who are the application's end‐users? How do the end‐users interact with the ap-plication? What security expectations do the end‐usershave? Partners Which third‐parties supply data to the ap-plication? Which third‐parties receive data from theapplications? Which third‐parties process the applica-tion's data? What mechanisms are used to share data withthird‐parties besides the application itself? What security requirements do the partnersimpose? Administrators Who has administrative capabilities in the ap-plication? What administrative capabilities does the ap-plication offer? Regulations In what industries does the application oper-ate? What security‐related regulations apply? What auditing and compliance regulationsapply? #2: INRASTRUCTURE REQUIREMENTS Network What details regarding routing, switching,firewalling, and load‐balancing have been de-fined? What network design supports the applica-tion? What core network devices support the appli-cation? What network performance requirements ex-ist? What private and public network links sup-port the application? Systems What operating systems support the applica-tion? What hardware requirements have been de-fined? What details regarding required OS compo-nents and lock‐down needs have been defined? Infrastructure Monitoring What network and system performance mon-itoring requirements have been defined? What mechanisms exist to detect maliciouscode or compromised application components? What network and system security monitor-ing requirements have been defined? Virtualization and Externalization What aspects of the application lend them-selves to virtualization? What virtualization requirements have beendefined for the application? What aspects of the product may or may notbe hosted via the cloud computing model? #3: APPLICATION REQUIREMENTS Environment What frameworks and programming lan-guages have been used to create the application? What process, code, or infrastructure depen-dencies have been defined for the application? What databases and application servers sup-port the application? Data Processing What data entry paths does the applicationsupport? What data output paths does the applicationsupport? How does data flow across the application'sinternal components? What data input validation requirementshave been defined? What data does the application store andhow? What data is or may need to be encrypted andwhat key management requirements have beendefined? What capabilities exist to detect the leakage ofsensitive data? What encryption requirements have been de-fined for data in transit over WAN and LAN links? Access What user identification and authenticationrequirements have been defined? What session management requirementshave been defined? What access requirements have been definedfor URI and Service calls? What user authorization requirements havebeen defined? How are user identities maintained through-out transaction calls? What user access restrictions have been de-fined? What user privilege levels does the applica-tion support? Application Monitoring What application performance monitoring re-quirements have been defined? What application security monitoring re-quirements have been defined? What application error handling and loggingrequirements have been defined? How are audit and debug logs accessed,stored, and secured? What application auditing requirements havebeen defined? Application Design How many logical tiers group the applica-tion's components? How is intermediate or in process data storedin the application components’ memory and incache? What application design review practiceshave been defined and executed? What staging, testing, and Quality Assurancerequirements have been defined? #4: SECURITY PROGRAM REQUIRE-MENTS Operations What access to system and network adminis-trators have to the application's sensitive data? What security incident requirements havebeen defined? What physical controls restrict access to theapplication's components and data? What is the process for granting access to theenvironment hosting the application? What is the process for identifying and ad-dressing vulnerabilities in network and systemcomponents? How do administrators access production in-frastructure to manage it? What is the process for identifying and ad-dressing vulnerabilities in the application? Change Management What mechanisms exist to detect violations ofchange management practices? How are changes to the infrastructure con-trolled? How are changes to the code controlled? How is code deployed to production? Software Development How do developers assist with troubleshoot-ing and debugging the application? What requirements have been defined forcontrolling access to the applications source code? What data is available to developers for test-ing? What secure coding processes have been es-tablished? Corporate Which personnel oversees security processesand requirements related to the application? What employee initiation and terminationprocedures have been defined? What controls exist to protect a compromisedin the corporate environment from affecting pro-duction? What security governance requirements havebeen defined? What security training do developers and ad-ministrators undergo? What application requirements impose theneed to enforce the principle of separation of du-ties? What corporate security program require-ments have been defined?
此外，在项目需求分析或设计阶段，应该了解项目中是否包含了一些第三方软件。如果有，则需要认真评估这些第三方软件是否会存在安全问题。很多时候，入侵是从第三方软件开始的。如果评估后发现第三方软件存在风险，则应该替换它，或者使用其他方式来规避这种风险。
在需求分析与设计阶段，因为业务的多样性，一份checklist并不一定能覆盖到所有情况。check-list并非万能的，在实际使用时，更多的要依靠安全工程师的经验做出判断。
一个最佳实践是给公司拥有的数据定级，对不同级别的数据定义不同的保护方式，将安全方案模块化。这样在review项目的需求和设计时，根据项目涉及的数据敏感程度，可以套用不同的等级化保护标准。
开发阶段是安全工作的一个重点。依据“安全是为业务服务”这一指导思想，在需求层面，安全改变业务的地方较少，因此应当力求代码实现上的安全，也就是做到“安全的功能”。
要达到这个目标，首先要分析可能出现的漏洞，并从代码上提供可行的解决方案。在本书中，深入探讨了各种不同漏洞的原理和修补方法。根据这些经验，可以设计一套适用于企业自身开发环境的安全方案。
OWASP的开源项目OWASP ESAPI也为安全模块的实现提供了参考。如果开发者没有把握实现一个足够好的安全模块，则最好是参考OWASPESAPI的实现方式。
ESAPI目前有针对多种不同Web语言的版本，其中又以Java版本最为完善。
下面为Java版本ESAPI的Packages列表，从中可以了解ESAPI实现的功能。
在“Web框架安全”一章中谈到，很多安全功能放到开发框架中实现，会大大降低程序员的开发工作量。这是一种值得推广的经验。
在开发阶段，还可以使用的一个最佳实践就是制定出开发者的开发规范，并将安全技术方案写进开发规范中，让开发者牢记开发规范。
比如在“Web框架安全”一章中曾提到，在对抗XSS攻击时，需要编码所有的变量再进行渲染输出。为此我们在模板中实现了安全宏：
XML编码输出，将会执行 XML Encode输出
1#SXML($xml)
JS编码输出，将会执行JavaScript Encode输出
1#SJS($js)
又比如微软在面对同样问题时，为开发者提供了安全函数库：
这些写法需要开发者牢记，因此需要将其写入开发规范中。在代码审核阶段，可以通过白盒扫描的方式检查变量输出是否使用了安全的函数，没有使用安全函数的可以认为不符合安全规范。这个过程也可以由开发者自检。
这种申明是非常有必要的。因为如果开发者按照自己的喜好来写，比如自定义一个输出HTML页面的过程，而这个过程的实现可能是不安全的。安全工程师若要审计这样的代码，则需要通读所有的代码逻辑，将耗费巨大的时间和精力。
将安全方案写入开发规范中，就真正地让安全方案落了地。这样不仅仅是为了方便开发者写出安全的代码，同时也为代码安全审计带来了方便。
常见的一些代码审计工具，在面对复杂项目时往往会束手无策。这一般是由两个原因造成的——
首先，函数的调用是一个复杂的过程，甚至常有一个函数调用另外一个文件中函数的情况出现。当代码审计工具找到敏感函数如eval()时，回溯函数的调用路径时往往会遇到困难。
其次，如果程序使用了复杂的框架，则代码审计工具往往也缺乏对框架的支持，从而造成大量的误报和漏报。
代码自动化审计工具的另外一种思路是，找到所有可能的用户输入入口，然后跟踪变量的传递情况，看变量最后是否会走到危险函数（如eval()）。这种思路比回溯函数调用过程要容易实现，但仍然会存在较多的误报。
目前还没有比较完美的自动化代码审计工具，代码审计工具的结果仍然需要人工处理。下表列出了一些常见的代码审计工具。
代码的自动化审计比较困难，而半自动的代码审计仍然需要耗费大量的人力，那有没有取巧的办法呢？
实际上，对于甲方公司来说，完全可以根据开发规范来定制代码审计工具。其核心思想是，并非直接检查代码是否安全，而是检查开发者是否遵守了开发规范。
这样就把复杂的“代码自动化审计”这一难题，转化为“代码是否符合开发规范”的问题。而开发规范在编写时就可以写成易于审计的一种规范。最终，如果开发规范中的安全方案没有问题的话，当开发者严格遵守开发规范时，产出的代码就应该是安全的。
这些经验对于以Web开发为主的互联网公司来说，具有高度的可操作性。
测试阶段是产品发布前的最后一个阶段，在此阶段需要对产品进行充分的安全测试，验证需求分析、设计阶段的安全功能是否符合预期目标，并验证在开发阶段发现的所有安全问题是否得到解决。
安全测试应该独立于代码审计而存在。“安全测试”相对于“代码审计”而言，至少有两个好处：一是有一些代码逻辑较为复杂，通过代码审计难以发现所有问题，而通过安全测试可以将问题看得更清楚；二是有一些逻辑漏洞通过安全测试，可以更快地得到结果。
安全测试，一般分为自动化测试和手动测试两种方式。
自动化测试以覆盖性的测试为目的，可以通过“Web安全扫描器”对项目或产品进行漏洞扫描。
目前Web安全扫描器针对“XSS”、“SQL In-jection”、“Open Redirect”、“PHP File Include”等漏洞的检测技术已经比较成熟。这是因为这些漏洞的检测方法主要是检测返回结果的字符串特征。
而对于“CSRF”、“越权访问”、“文件上传”等漏洞，却难以达到自动化检测的效果。这是因为这些漏洞涉及系统逻辑或业务逻辑，有时候还需要人机交互参与页面流程。因此这类漏洞的检测更多的需要依靠手动测试完成。
Web应用的安全测试工具一般是使用Web安全扫描器。传统的软件安全测试中常用到的fuzzing测试（模糊测试），在Web安全测试领域比较少见。从某种程度上来说，Web扫描也可以看做是一种fuzzing。
优秀的Web安全扫描器，商业软件的代表有“IBM Rational Appscan”、“WebInspect”、“Acunetix WVS”等；在免费的扫描器中，也不乏精品，比如“w3af”、“skipfish”等。扫描器的性能、误报率、漏报率等指标是考核一个扫描器是否优秀的标准，通过不同扫描器之间的对比测试，可以挑选出最适合企业的扫描器。同时，也可以参考下表所示的一份公开的评测报告，以及业内同行的使用经验。
skipfish是Google使用的一款Web安全扫描器，Google开放了其源代码：Google的skipfish扫描结果页面
skipfish的性能非常优秀，由于其开放了源代码，且有Google的成功案例在前，因此对于想定制扫描器的安全团队来说，是一个二次开发的上佳选择。
安全测试完成以后，需要生成一份安全测试报告。这份报告并不是扫描器的扫描报告。扫描报告可能会存在误报与漏报，因此扫描报告需要经过安全工程师的最终确认。确认后的扫描报告，结合手动测试的结果，最终形成一份安全测试报告。
安全测试报告中提到的问题，需要交给开发工程师进行修复。漏洞修补完成后，再迭代进行安全测试，以验证漏洞的修补情况。由此可见，在项目初期与项目经理进行充分沟通，预留出代码审计、安全测试的时间，是一件很重要的事情。
本章讲述了如何在项目开发的过程中实施SDL（安全开发流程）。SDL是建立在公司软件工程基础之上的，公司的软件工程实施越规范，SDL就越容易实施，反之则难度越大。
互联网公司不同于传统软件公司，它更注重产品的快捷与时效性，因此在产品开发的路线上大多选择敏捷开发，这也给SDL的实施带来了一定的难度。
SDL需要从上往下推动，归根结底，它仍然是“人”的问题。实施SDL一定要得到公司技术负责人与产品负责人的全力支持，并通过完善软件发布流程、工程师的工作手册来达到目的。SDL实施的成功与否，与来自高级管理层的支持力度有很大关系。
Copyright ©2010-2022 比特日记 All Rights Reserved.