早期修复VS 发布后修复
Gartner，IBM和NIST的研究表明在设计/开发阶段清除应用的安全漏洞要比在生产阶段清除这些漏洞少花费30-60倍的成本。在软件开发生命周期内（SDLC）整合安全进程的关键目标是确保我们能查找并修复早期安全漏洞。
许多企业不了解寻找和修复软件漏洞的成本，因为他们没有跟踪并权衡这项工作。如果他们有的话，可能会对开发软件的真正成本表示惊讶。查找和修复安全漏洞的过程中存在直接成本和间接成本。如果有漏洞被找到并利用在产品应用中，那么对品牌的损害将无法估量且难以弥补。
直接成本我们尚可以计算。而编写修复代码的平均成本是最易于计算的：
编写修复代码的平均成本=（程序员的人数×每人的日需成本）+ 修复的漏洞数量。除了这一成本，还有些额外成本需要考虑：
系统测试成本
执行成本
系统成本
后期成本
当涉及关键任务和受瞩目的应用时，这些成本也会水涨船高，可是却不能让使用互联网应用的客户看到这种变化，如网上银行的页面。
因此，对于企业而言，在发布进入生产环境之前就寻找和修复应用软件漏洞是更为明智的选择。虽然对威胁建模，设计还有架构有助于确保不会有设计以内的高级别漏洞出现，但是安全测试可以保障执行安全设计的时候不会有漏洞。有若干技巧可在测试某应用安全性时使用。这些技巧从简单的程序员驱动型单元测试，到专业安全团队的渗透测试不等。
测试阶段
典型的软件开发测试一般出现在多迭代阶段。这些阶段都可能存在安全和弹性测试，而且可以用下列词语来表述：
单元测试
整合性测试
质量保障测试
用户接受度测试
单元测试
程序员对自己编写的代码执行单元测试。单元测试是对代码的质量进行整体测试且具有一定的安全优势。单元测试有助于阻止漏洞进入更高级的测试阶段。由于程序员比其他人更了解自己的代码，所以简单的单元测试就足以保证测试的有效性。
程序员需要记录下自己的测试情况，因为手动测试的步骤很容易被忘记。程序员可以在单元测试中找到的以下内容：
边界条件
整数溢出/整数下溢
路径长度 （URL，文件）
缓冲溢出
用C语言编写代码和编写其内存管理事务时，所有相关计算都应该被测试
程序员也可以用模糊测试（Fuzzing）技巧执行直接的安全测试。模糊测试，简而言之，是将随机数据发送到程序所依赖的应用程序界面，再确定它是否会，何时会损坏软件。模糊测试通常通过多重迭代完成，而且如果在数据结构的关键部位有针对性的变化则可以获得更好的效果。模糊测试是许多程序员都乐于使用的方法。而它也是识别安全漏洞最便宜，最快捷和最有效的方法，即便是拿下具备成熟SDLC安全性和弹性的企业也是如此。
