最大的挑战是，在当今的 Web 应用程序中这些缺陷都太常见。这样的例子之一就是 Web 页面的代码中的一个安全漏洞，它可以允许一个在线银行客户看到其它客户的数据。这些缺陷可以让黑客在这个应用程序 的后台数据库上运行查询程序，很可能替代这个 Web 服务器本身。Web 应用程序的安全问题非常紧急并且正构成威胁，它们主要由这个应用程序代码中的安全故障导致产生的。
另一个挑战是最新发现这些问题的成本。大多数机构将这个 Web 应用程序安全性问题的发现留给专注安全的小组来做，他们在这些应用程序生效之前进行测试。找到并修复这些问题，然后要求开发和质量保证测试的人员对最新代码变更进行完整的迭代。这样修复很常见的最简单安全故障也会产生很高的成本。
此外，安全专家远远多于开发人员的数量。这些安全小组就会努力跟上新的以及变更的应用程序的节奏。这样通常会导致只有十分紧急的应用程序才会被测试。其它自检的应用程序就很可能出问题，因为在它们被执行之前并没有进行安全性测试。
这种状况已经变得越来越恶劣，因为 Web 应用程序在绝大多数商业中扮演者越来越重要甚至是前所未有的重要角色。这种破坏和黑客的影响继续在增长，然而安全性问题还没有被当作这些 Web 应用程序开发过程的一部分。
要解决这个问题，要求这个 Web 应用程序开发中所有不同小组的参与，但主要是开发和质量保证小组。最后，潜在造成这些问题的原因是不安全编码介入了 Web 应用程序的安全缺陷中。这篇文章集中强调开发人员的角色应该主要致力于这个问题的解决，以及 IBM® Rational® AppScan® Developer Edition 该如何使他们这样做的具体细节。
开发过程首先要测试和修正这些安全性问题，您的小组必须首先了解您的开发和安全性小组之间的差异。当今可利用的技术主要为安全专家所使用，通常并没有满足开发的需求和用例。
表格 1提供了这些小组之间差别的一些例子。
| 安全小组 | 开发小组 |
| 安全是他们的主要工作。 | 交付软件是他们的主要工作：安全是众多职责之一。 |
| 他们带着证明这些应用程序是安全的目标进行测试，因此会尝试找出一个应用程序中所有的问题。 | 他们测试这些应用程序，都带着尽早找出简单问题的目的，而不是证实不安全性。他们不需要找出所有的问题。 |
| 如果有一个很难理解的问题，或者这个问题很可能会失败地报告为（一个假阳性的），他们通常将花一些时间来理解它，因为它可能会导致一个安全风险。 | 如果一个问题很难理解，或者这个问题很可能会失败地报告为（(一个假阳性的），他们将会忽略从而避免浪费时间。 |
| 他们利用所包含的充分的功能来处理完整应用程序。 | 他们不完全处理开发的应用程序。 |
| 他们测试大量不同应用程序的安全性问题：他们并不需要很好地理解每个应用程序。 | 他们测试一个（或者几个）应用程序的许多不同问题：他们并不需要很好地理解安全性问题。 |
| 每次审核通常都仅仅由一个（或者几个）审核人员完成的。 | 每个应用程序通常都是由多个（通常是许多）不同的开发人员进行开发的。 |
因为这两个小组是不同的，因此每个小组的产品设计也应该不同。正如 Rational AppScan Standard Edition 是为安全审核人员设计的，而 Rational AppScan Developer Edition 是为开发人员设计的，并且要记住他们自己特殊的用例：
- 它是为另一个开发工具而设计的，而不是一个安全工具的另一种风格。
- 这个产品设计偏好使用简便以及轻松地整合到开发工具和过程中，胜过高级安全性专研功能的开发。
- 它将假阳性因素最小化，使结果更加容易理解，从而比增加监测幅面有更高的优先权：这样有助于帮助开发人员尽早发现问题，并且节省了时间。
- 所包含的手动的基于浏览的监测和静态分析功能使得熟悉的应用程序的特殊板块能够进行简单的测试。
- 这个设计使得么个应用程序能够轻松地重复使用重复监测和配置。
- 协作以及构造和结果的共享是这个产品的核心部分。
Web 应用程序监测可以通过许多不同的方式来完成，但是有两种主要的被广泛采用的方法：
- 动态分析 (Dynamic analysis)是从外围测试运行软件的实践。这种方法与这个应用程序的运行实例相互影响，从而有效地执行轻度攻击（绝大多数是无害的）来检查安全漏洞。
动态分析与使用一个 Web 浏览器来单步调试一个 Web 应用程序十分相似，在每个表单域放置一个单引号，从而从相应的回应中找出 SQL 错误（通常暗示 SQL 介入的存在）。 - 静态分析 (Static analysis)是观察这个静态应用程序代码以及二进位的过程。构建它们如何工作的数学模型，以及通过分析那些模型来检查安全缺陷。
代码的静态分析域自动化代码检查十分相似，在这个分析过程中您从思想上考虑这些情形的不同类型，并且从应用程序如果对这些代码做出反应中进行理解。
有一种第三方分析技术，叫做运行时分析，当不同的事件发生时监测这个应用程序，收集关于执行代码和执行的系统调用的相关信息，以及许多其它因素。运行时分析不是真正的独立技术，相当于一个提高动态和静态分析的方法。
Rational AppScan Developer Edition 包含所有这三种分析技术，并肩运行它们，并用它们来相互支持。平行地运行它们从而衡量每个技术的优势，共同使用它们来帮助克服它们的缺陷。这篇文章仔细审核了这些方法，并且讨论了您如何才能将它们合并到一个有效的解决方案中。
动态分析包括将 Web 应用程序作为一个封闭的实体进行测试，通过它的官方干涉（主要是 HTTP）进行相互作用。这种行为通常涉及到Black-Box 监测，因为它并没有或者要求对这个应用程序中所发生的事件有可视性。动态分析就是当今 Web 应用程序安全性测试占主导地位的方法。Rational AppScan Standard 和 Enterprise Editions 都是动态分析的案例。
动态分析工作的方法与黑客在攻击一个应用程序时所使用的方法十分相似。它通过两个阶段来完成： Explore 和 Test。
这个 Explore （或者 Discovery） 阶段包括作为一个普通用户穿越这个 Web 应用程序，检查这些页面，表单域，以及其它到这个应用程序的输入。这个考察要么通过使用一个自动下载网站内容引擎的方法，要么通过通过监测一个用户手工浏览这个网站的方式进行。
这个步骤的目的是学习其中尽可能多的关于这个应用程序，不同控件，它接受的输入，以及它如何以合法方式执行的相关知识。
在 Test 阶段，这个检测器将重复在有着多种修改的 Explore 阶段中的所见到的行为，是用来揭示通过提交未预料的输入所产生的缺陷。然后对这个应用程序的反应进行分析，从而决定这个问题是否确实没被发现。
动态分析的一些优势包括：
- 大多数紧急问题的发现：由于动态分析是作为一个黑客来测试这个应用程序的，因此它会找出与攻击者所发现十分相似的问题。这些问题就是您首先要处理的问题。
- 低级假阳性率：由于这些测试是在一个运行的应用程序中执行的，因此问题也被证明。毫无疑问这个应用程序是按照它过去的方式进行重复行为的，因此可以得出这样的结论：这表明这个缺陷的存在是十分准确的。
- 源代码的非必要条件：需要非源代码，从而支持了商业常用应用程序，外包应用程序，机器产生的代码，以及其它第三方代码不可用的控件的监测。
- 服务器端技术的透明性：从外围进行测试允许动态分析使得动态分析成为一个服务器端技术的不可知论者，因此用于任何 Web 应用程序的平台和语言。
- 少数先决条件：您可以用尽可能少的对运行的 Web 应用程序的远程访问和登陆证明来进行测试。
- 代码，整合以及基础构架的测试：动态分析揭示了这些问题，不论它们是在不同控件的整合中的应用程序本身的自定义代码中，还是在下面的基础构架中。它会首先找出这个问题，您可以找出为什么它会第二次发生的原因。
虽然动态分析提供了许多优势，它同样也有缺点。正如它的优势来自于在运行的应用程序外围进行测试一样，同时也带来一些挑战。部分挑战如下：
- 部署应用程序的必要条件：只有当一个带有 HTTP 界面的部署应用程序可以被测试调用时，您才可以进行测试。
- 潜在不完全应用程序代码的覆盖范围： 在 Explore 阶段发现的应用程序只有部分被监测者们所知和进行测试：用户需要证实必要的部分已经被检测。例如，当某些输入作为参数传递到这个应用程序时，有些应用程序路径可能被执行，但是动态分析者不可能全面测试带有所有可能输入的应用程序。
- 通过 HTTP 可利用的有限信息：从外围进行测试意味着这个分析者并不知道内部所发生的情况。缺陷可能仍然隐藏在检测器中，但是通过攻击者对这个应用程序的逻辑分析仍然是可检测到的。
- 指出问题的根源是不可能的：动态分析根据 URLs 和参数确定了问题的位置，但是并不能从定位的问题中看到这个代码行或者服务器元件。
静态分析工具审核一个应用程序的源代码和二进位，弄清楚这个应用程序是如何运行的，以及构建这个行为的数学模型。这个工具然后就会查询这些模型来检查这个应用程序的行为是否暴露出了安全缺陷。与动态分析方法相比，在静态分析中实际并没有任何执行行为：整个分析是建立在纯粹的数学模型基础上的。
静态分析通常被看做是一个白盒监测，意味着与黑盒是相对立的。在黑盒中，这个应用程序是一个封闭的单独实体。在白盒中，应用程序（代码）的所有内部是完全开放的，对分析者是公开的。
静态分析中的模型和分析有不同的类型。有些审核到方法和类的登陆许可，有些分析一个过程的配置和运行许可。每个都审核不同的模型，并进行不同的查询。对于 Web 应用程序，安全静态分析最重要的类型叫做污染流分析。 这个分析主要是以检查这个流和应用程序中不信任代码使用为目的的。
当执行污染流分析时，检测器会在这个系统中为数据流建立模型。如果来自非信任源的数据（比如，一个表单域）在这个应用没有确认此输入是非恶意情况下，进入一个敏感输出库（比如，一个数据库调用），就好报告一个安全性问题。这个非信任数据被看作是污染的数据，当这个代码确保这个数据是非恶意就称作杀毒功能，通常也称作杀毒污染的东西。
静态测试的优势是，对内部代码的高度可视性，它构建的数学模式可以通过特定的代码说明所有可能执行的流。通过审核这个应用程序的真实代码，静态分析者可以检查这个数据能够进入或者存在于这个应用程序的方式，并且可以一直跟踪在它上面所执行的流和行为。
因此，静态分析的优势包括：
- 更多问题类型的检测：由于它不仅仅局限于对通过外部 HTTP 界面可以进行测试的问题，静态分析还可以测试信任度，糟糕的安全实践，以及在动态分析中不可见的许多其它问题。
- 目标程序的广泛范围：有了对其他数据入口点的可视化（比如文档被阅读以及环境变量被检测），静态分析可以验证任何实际程序中不存在的问题，不仅仅是 Web 应用程序。其中某些属性可以被动态地测试，但是并不属于当前可利用动态分析工具中的一部分。
- 清除代码覆盖范围：由于这个代码本身是被静态监测的，获得代码范围就像指定这个分析范围中应该包含哪些代码一样简单。
- 减少对客户端技术的敏感度： 查看代码中这个应用程序的入口点，可以消除动态分析必须通过它的客户来“驱动”的需求，使监测服务器端问题的富 Internet 应用程序 （RIAs） 跟监测传统 Web 应软件一样简单。
- 不需要应户界面 (UI)：您可以在 UI 或者一个完整工作流程可利用之前开始监测缺陷。
静态分析中的挑战来自它对没明白或者理解的单元和代码没有可视性的事实。例如，如果一个程序是由不同的控件构成（其中有些没有源代码，或者已经被这个静态分析者所不支持的语言覆盖），这个分析者可能就不能为这些所有控件构建执行模式。
因为它为这个应用程序所执行的行为构建模式，因此静态分析需要对这个应用程序是如何工作有完全的可视性，否则它就不能够决定是否有缺陷存在。
这也非常具有局限性，意味着静态分析可能不能决定一个应用程序是否受到外部系统（比如一个防火墙）的保护，不受特定缺陷的攻击，或者黑客是否确实访问了特定信息流。这意味着静态分析不能决定，是否：
- 一个受攻击的页面曾经被部署
- 一个 Web 应用程序的文件系统不能被任何人访问，除管理人员外
- 代码中一个特定公共功能实际上从来不被调用
- 等等
当防御程序原则说明这些问题应该被解决时，静态分析在帮助用户检查将用户的工作项目进行优先分级所必须的更高曝光度和更高风险问题上，能力显得十分有限。
总的来说，静态分析的不足包括：
- 对可视的代码的局限性：静态分析者所没看见的代码可能包括封闭源代第三方控件（比如 COTS 软件），操作系统，数据库，以及 Web 应用程序控件。它通常很难平等地获取由其它相同组织中的外部小组开发的控件代码。
- 对它可理解的代码的局限性：例如，静态分析工具需要构建所使用的每种语言以及每个开发平台的完全支持。在运行时他们也会不断遇到由决定数据流的程序所带来的挑战。
- 不能确定可利用性以及缓和因素：通常，一个静态分析者不能自动评估某些问题的可利用性，或者缓和因素的存在。这样就导致大量的问题很难被适当地分选，并且假阳性也逐渐增长。
- 不能测试整合问题：一个系统的安全性需要在与其它控件整合时保证这个系统的所有控件都是安全的。问题可能是由于对不同应用程序控件或者下面的基础构建的输入的不同处理方式而引起的。如果这些控件被当作孤立的单元来分析，就会导致这些缺陷很难被发现。这些问题只有您在它的完全部署状态下进行测试才会显现出来。
静态分析技术当今另一个下降趋势就是对谨慎配置杀毒功能的需求。
来自表格参数的数据仅仅通过一个 SQL 查询就可以进入数据库的事实已经成为一个问题，如果这个数据没有被合适地进行清除的话。
虽然现存的工具在检查应用程序的输入（源）和输出是表现良好，但是它们不会自动检查杀毒工作是否已经完成。配置需要指定哪些功能是这个杀毒功能对数据进行杀毒功能。
由于绝大多数 Web 应用程序过分依赖于在用户和数据库之间传递的数据，而并没有对杀毒功能进行适当的配置，从而导致大量的问题，这些问题中的绝大多数都是假阳性的。那么用户就需要贯穿浏览，手工标记杀毒软件的所有功能，从而找出真正有问题显示的点。
这种行为十分单调，耗费时间，容易出错，而且需要对所有可能环境中的杀毒功能进行严格的检查。这样需要很好地了解特定应用程序的代码和安全行为。这通常暗示着它需要一个开发人员和安全专家同时工作，从而也需要花费双倍的投资。
这个问题的另一种变异是对校验的的使用。在有些情况下，数据没有被清除掉，而只是简单地核查它是有效的还是无效的。如果这个数据没有被清除掉，那么就会返回一个错误，进程就会停止。
这种技术保持使系统安全的一种有效的方法，但是因为并没有真正地清除数据（仅仅以它作为条件），那么当前的静态分析工具就不能适当地分析这样的代码。唯一的解决方案是重构（换句话说，就是修改）代码来进行清除，使工具能够理解它。
Rational AppScan Developer Edition 在它的静态分析引擎中介绍了一种令人振奋的新方法，叫做字符串分析 (String analysis)。字符串分析，就像它的名字所表达的那样，在构建代码模型时运用所看到的字符串的进一步处理来完成。这样在决定缺陷的存在时，可以使随后的查询可以询问更多准确的问题（从而获得更多准确的答案）。
字符串分析的原理包括跟踪在穿越这些代码时这个字符串所包含的所有可能值。当一个字符串进入此应用程序时，它可能被看做是一个开字符串T，并可能包含任何符号。如果所有的引号现在都被这个应用程序代码中的一些功能从此字符串中清除掉，那么这个字符串分析模型就会检测到这个字符串从此以后就不可能包含引号。
接下来，当它检查出包含在一个 SQL 问题中的污染代码区，这个静态分析引擎就能判定是否仍然存在一些危险的符号（表明一个安全问题的存在）。字符串分析模型字符串就是一些语法，能够对字符串和序列有很详尽的理解，字符串可能在执行过程的任何点发挥作用。
在列表 1所显示的例子中，输入字符串变量被跟踪。字符串分析能够自动计算出，到它连接到此 SQL 命令时候位置，它不可能包含单个的引号或者分号。
列表 1.跟踪出入字符串变量
public void submitQuery(String userName) { userName = clean(userName); String query = "SELECT id FROM users WHERE name = '" + userName + "'"; execute(query); } public String clean(String input) { return input.replaceAll(";","").replaceAll("'",""); }注意：在 public String 中，输入是 ".*" ，而在 return, ，输入为 "[~;']*"
字符串的使用十分方便，而且使其对下一个层次的静态分有很高的精确性。它不需要对杀毒功能进行配置，支持校验，并且消除了代码重构的需求。它对用户的错误不是很敏感，因此有些功能可能被错误地标记为杀毒功能，或者杀毒软件可能会丢失一个字符串或者一个字符串序列。
字符串分析通过减少重大投资和杀毒功能配置所需的安全专家高水平的需求，使静态分析成为开发人员的一种有效工具。不可想象的准确性，以及它没有代码重构的需求，使得它成为监测现存应用程序（通常存在于当前风险中）的一种切实可行的工具。
Rational AppScan Developer Edition 对强大字符串分析的主要应用是消除杀毒软件的功能配置。然而，那只是字符串分析潜能的初步表现。字符串分析的另一个应用是，在 IBM 当前的开发中，允许静态分析跟踪代码界限以外的数据（通过对遗留在应用程序代码主要区域中字符串进行语境分析）。
留意论坛应用程序中一个用户定义她的公共名称的页面，如列表 2所示。
列表 2. 定义一个公共名称
statement.executeUpdate("UPDATE Users SET PubName='" + SqlEncode(Name) + "' WHERE UserName = '" + SqlEncode(UserName) + "';");当用户发布一个消息时，另一个页面就会拉出这个名称将它显示在这个用户发布的每个消息中，如列表 3所示。
列表 3. 显示这个公共名称
ResultsSet rs = statement.executeQuery("SELECT PubName FROM Users " + " WHERE UserName='" + SqlEncode(UserName) + "';");假设这个用户名直接被记录到HttpResponse，这意味着有一个 Persistent Cross-Site Scripting (XSS) 缺陷存在：污染数据在 XSS 存在的情况下没有被清除掉而进入了 HttpResponse。
传统的静态分析不能处理这样的情形，因为当它被记录到数据库时，这个数据为代码保留了一定的空间。静态分析工具主要留下了一个严格的选择。它们很可能丢失许多问题，或者它们能够标记任何数据的编写到这个数据库中（或者从数据库中阅读和显示数据）， 作为一个安全性问题。更为通常的情况是，它们放弃了后者，导致大量的假阳性，从而使这个工具实际上不可使用。
使用字符串分析，分析者可以从语法上分析和理解被传递到数据库的 SQL 说明。这样允许它检验特定表格和专栏中的信息是否被污染，但是不能降低这个数据库中其它数据只读形式的信任度。同样的逻辑可以应用到：
- 从特定文件中读取和写入
- 对检查服务器进行调用
- 许多其它协议
然而这并不是字符串分析的唯一用途。它潜在的能力可以保证它将成为静态分析技术新一代的基础。
早期，这篇文章阐述了动态分析是如何在一个运行的应用程序上被执行的，然而对内部的活动不具有可视性。它还涉及了静态分析是如何对此应用程序有完全的可视性，但如果在静态信息上运行，就不能看到分析代码是如何进行实时分析的，或者它是如何与环境进行相互影响作用的。
运行时分析 (Runtime analysis) 在这两者之间进行操作。当它被调用时，它就会对这个应用程序内部的活动进行监测，为动态分析提供跟高的可视性，并将运行确认添加到静态分析中。
Runtime Analysis 使用的常见流程包括以下这些步骤：
- 利用静态分析学习关于被监测的应用程序的知识
- 将钩子注入汇编的应用程序（或者运行的环境中），从而监测那些活动
- 当执行动态分析时从那些钩子中搜集信息
- 精炼动态分析结果并进入下一步
运行时分析所搜集的信息的类型差别很大。例子包括：
- 监测什么代码执行测量代码覆盖范围的工作
- 监测 I/O 活动，从而检查贯穿应用程序代码的测试有效载荷
- 监测内存的分配，从而找出漏洞以及导致耗尽内存的其它潜在路径
运行时分析是对其它分析技术的一个强有力的附加工具，非常重要一点要澄清的是它不是单独工作的：它可以仅仅用来加强其它的活动。
在开发中使用动态分析的挑战之一是，问题都是在一个 URL 地址和一个参数中报告的。虽然开发人员有时可以充分利用它们来指出代码所包含的范围，但通常情况下是不充分的，开发人员需要花费宝贵的时间来寻找故障的位置。
要解决这个问题，Rational AppScan Developer Edition 在调用每个动态分析问题时，利用运行时分析来检查被执行的准确的代码。这个执行流程，以文本或者图表的形式显示，开发人员可以直接指出所包含的代码行。这样找出问题源和解决问题就容易多了。
动态分析工具用户的另一个常见担忧是，了解它们是否调用了应用程序中的大多数行为。当您设置这样的工具来自动利用一个应用程序时，很容易就会在此应用程序的绝大多数活动中被遗漏。当今的动态分析工具很容易就可以将遗漏的部分添加到扫描中，但是通常很难确定这些部分是否确实被遗漏了（如果确实遗漏，是哪些）。
运行时分析还揭示了自动化开发利用。通过监测自动开发利用过程中被执行的代码，很容易就可以快速了解扫描过程中的百分比和特定区域。
如果有了这样的了解，调整配置和确保更成功的扫描将是十分简单的事情。Rational AppScan Build Edition 权衡了 Eclipse Test 和 Performance Tools Platform. （TPTP） 和 IBM®Rational®Application Developer 框架的强有力性能，从而使之形象化并能快速了解扫描所覆盖的准确范围。
当用户手工浏览这个应用程序，找出动态分析引擎区域来进行分析时，覆盖范围就不是什么问题了。当您的目标是一个较小的范围时，更简单的方法是通常会更好，比如在核查他们的特定任务的代码之前开发人员通常会执行它们。
这篇文章已经讨论了三种主要的分析技巧，包括它们的值和涉及到独立使用它们的潜在问题。Rational AppScan Developer Edition 将这些不同的技巧混合在一起来权衡它们的优势从而来补偿它们的弱点。这是如何做到的呢？
正如先前所显示的，动态的，静态的已经运行时分析每种都有它们自己的优点和缺点。
通过并肩使用这些技术，您可以充分利用它们的优势。这样能够使您在第三方控件中找出问题，并伴随着来自恶意文件源中更多的问题。一个有安全意识的组织可以通过使用这两种技术来清楚地降低它的风险。
然而，Rational AppScan Developer Edition 并不在这里停止。通过使用两种技术 一起 ，您还可以 权衡每种技术来克服另一种技术的弱点。您可以利用动态分析来决定开发利用性并帮助优化静态分析的结果，而静态分析可以自动配置动态分析，很大程度上降低为达到合适的覆盖范围而需求的配置。
综合分析最直接的体现是将静态和动态分析所找出的问题集相互关联起来。将结果联系起来可以产生利用这两种方法所发现的优先问题集。
这个组中的每个问题都被证明是由动态分析所开发利用的。遍及代码中的污染数据的精确流程是有静态分析所提供的。用这种方法，它的精确性被实践所证明，因为它是用这两种截然不同的方法查找的。这些问题应该在这个优先列表的顶部就不澄清。
将这两个问题集合联合起来并不是意见简单的事情：动态分析以 URLs 和参数的形式说明，而静态分析则讨论代码的类和行。幸运的是，由运行时分析提供的执行流程可以帮助 Rational AppScan Developer Edition 将这个动态分析问题映射到所涉及的代码中，然而它们可以在静态分析问题所包含的代码中相互匹配。
这对准确关联来说十分重要，因为颠倒关联关系（将静态分析问题映射到 URL 和参数层）需要准确的信息和对应用程序部署的理解，但并不经常被静态分析工具所利用。
结果关联仅仅是综合分析的例子之一。真正的优势是帮助一种分析技巧指导另一种。例如，静态分析可以用来决定到应用程序的所有 Web 入口点，并为动态分析工具提供信息。这样可以帮助它自动到达高度的覆盖范围。
从另一个并不十分重要的方面来看，动态分析可以通知静态分析对于外部用户来说那些输出是可见的，从而帮助后者优化它的问题并检查隐藏在代码中的后门（或者维护钩子）。
Rational AppScan Developer Edition 是首个利用联合不同分析技术巨大潜力的产品。因为这是一个现存的新路径，您可以确保见到更令人振奋的新方法和添加到每个释放中的性能。
T先前的部分描述了每种分析技巧所提供的各种不同的优势。然而当分析技巧一起使用时，它们的联合力量可以帮助克服，或者至少能很大程度上减轻单个方法中的缺点。表格 2显示了静态和运行时分析一起帮助克服动态分析中的挑战。
问题 解决方案 需要一个部署的应用程序 在它们的界面可利用之前静态分析支持分析的应用程序。 应用程序/代码的覆盖范围是非保证的 运行时分析可以简单地测量被扫描应用程序的精确代码覆盖范围。 通过 HTTP 的限制可利用信息 静态和运行时分析在扫描之前和扫描过程中为这个应用程序的行为提供了详细的可见性。 不能指出问题源 为每个动态分析问题而收集详细的代码执行流程，多亏了运行时分析引擎的作用。 反过来，表格 3显示了静态分析引擎是如何被新的字符串分析性能和动态分析技巧所加强的。
问题 解决方案 对可见代码的限制 字符串分析扩大了静态分析对数据库，文件系统，以及其它控件的可视度。动态分析对这个应用程序进行实时测试，含蓄地被纳入所有的成因中。 可以理解但不能测试整合问题的的局限代码 动态分析在不许去对它们的情况深度了解的情况下揭示了问题所在，向用户提供了丰富的信息，从而帮助判定控件的错误。 不能决定开发利用性和缓和因素 与动态分析的结果联合关系可以帮助标出基于关注的可开发利用的问题，将它们从这些问题中分离开来，这些问题的纠正是非常重要但是次要步骤。 需要大量的事先投资来达到精确的结果 字符串分析提供了非常高的准确性，消除了杀毒功能配置和代码重构的需求。
- 更多问题类型的检测：由于它不仅仅局限于对通过外部 HTTP 界面可以进行测试的问题，静态分析还可以测试信任度，糟糕的安全实践，以及在动态分析中不可见的许多其它问题。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780873/viewspace-586743/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780873/viewspace-586743/
301
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
