整合性合成测试的好处
软件测试的整合性的合成分析方法可以更大地提升效率。集成开发环境的特定插件在发现用户的编码错误时会向编码人员发出警告。静态分析，也称为“白盒”测试，在将不同的模块组装成最终的产品之前，开发人员和审计人员就对其使用此技术。静态分析在代码水平上提供了一种内部人员对应用程序的检查分析。静态分析对于发现语法错误和代码水平的缺陷是很有效的，但并不适于决定一个缺陷是否会导致可利用的漏洞。
动态分析和人工渗透测试对于验证应用程序是否容易受到攻击是有效的。它也被称为“黑盒测试”，主要展示的是外部人员对应用程序的检查分析，可以对投入生产的应用程序进行深入检查，查看攻击者是否容易利用其漏洞。然而，动态测试技术仅能用于软件开发的后期，只能在生成后阶段。动态测试的另一个局限性是它很难找出代码中导致漏洞的代码源。
这就是将静态测试和动态测试结合起来以“灰盒”或组合的方法进行混合测试的原因。通过将代码水平的内部检查和动态的外部检查结果结合起来，就可以充分利用两种技术的长处。使用静态和动态评估工具可以使管理人员和开发人员区分应用程序、模块、漏洞的优先次序，并首先处理影响最大的问题。组合分析方法的另外一个好处是动态测试确认的漏洞可以用静态工具追溯到特定的代码行或代码块。这便有利于测试和开发团队进行合作性交流，并使得安全和测试专家更容易向开发人员提供具体的可操作的纠错指导。
将安全性构建到软件的生命周期中：实用方法
构建安全性需要人员、过程以及技术、方法。虽然有大量的工具可有助于自动化地强化Web应用程序的安全，但是，如果没有恰当的过程和训练有素的人员来创建、测试Web应用程序，那么，任何工具都不会真正有效。
这个过程应当包括一个正式的软件开发周期及所公布的策略。此外，为所有的开发人员建立角色，并且指派检查和监管责任也是很重要的。安全和业务在软件开发周期的每一个阶段都应当得到表现，从而可以在每一个步骤处理风险管理。
在软件的整个开发周期，一个有益的永恒主题就是教育。教育对于开发人员是很重要的，它对于Web应用程序开发所涉及到的全体人员都很有益。因为安全意识既需要从上而下，也需要从下而上。不要低估教育管理人员认识到Web应用程序的漏洞如何影响企业的重要性。告诉一位管理人员Web应用程序易于遭受跨站请求伪造(CSRF)可能会令他感到茫然，但是如果向他展示软件错误如何会导致客户数据的泄露，就能够有助于使其意识到不安全的Web应用程序所造成的切实后果。应该准备特定的案例和度量标准用以阐明潜在的各种成本节约。例如，在开发人员检查其代码之前，就演示对开发人员的培训和IDE的静态分析插件投资可以阻止软件应用中的数据泄露根源。
审计人员和评估人员可以从学习常见的编码错误、后果评估以及与Web应用程序“生态系统”(包括后端的支撑系统、现有的安全控制以及属于Web应用程序环境的任何服务或应用程序)有关的依赖关系中获益。测试者及质量评价专家应当熟知误用情形，并且知道误用情形是如何区别于标准的应用的，还要知道如何解释安全测试结果，并能够按照需要对结果区分优先次序。
关注软件开发周期中的具体步骤，在这些步骤中存在着增加效率同时又可以贯彻安全性和风险管理的机会。
需求
Web应用程序的设计者对于定义功能和业务需求非常熟悉，但是未必理解如何定义安全需求。此时，整个团队需要协同工作，决定哪些安全控制对最终的Web应用程序至关重要。
将安全性集成到需求阶段的步骤
1、根据公司策略、合规和规章要求，讨论并定义安全需求。
2、安全和审计团队应当评估业务需求和Web应用程序的功能，并且在测试和接受期间开始制定误用案例(误用情形)。
其好处有两方面，一是提前清除或减少安全或违规问题，二是减少部署时间。
架构和设计
由于已经定义了Web应用程序的架构和设计方案，下一步就需要评估安全问题。正是在这个阶段，成本高昂的、难以纠正的安全问题可以在其最易于解决的时间修复。为了防止损失惨重的错误，应当从性能和安全两个方面评估程序的架构。由于编制了详细的设计规范，因而可以向开发人员展示出应当包括哪些安全控制，以及应用程序的组件如何与完整的Web应用程序进行交互。
将安全性集成到架构和设计阶段的步骤
1、对于所建议的架构和部署环境执行风险评估，以决定设计是否会带来风险。
2、评估应用程序与原有系统进行交互时的安全意义和风险，以及不同的组件、层或系统之间的数据流的安全问题。
3、评述在实施或部署阶段需要解决的任何具体的暴露问题(即依赖于应用程序的部署方式和部署位置的漏洞)。
4、考虑依赖关系以及与混搭关系、SOA及合伙服务的交互所引起的漏洞。将最终的设计交付安全和审计，以确定安全测试计划和误用情形。
其好处体现在五个方面：
1、可以精心协调风险评估分析过程和可重用的风险评估模型。
2、可以在早期阶段确定由架构环境或部署环境所带来的风险。
3、可重用的误用案例可以节省测试阶段的时间。
4、减少特定的设计漏洞。
5、如果有必要，可以调整或变更带来风险的架构限制，如果无法完全清除风险,也可以用补偿性控制来定义减轻风险的策略。
