ibm appscan_IBM Security AppScan Source快速过程指南

ibm appscan

应用程序安全测试的市场领导者

Gartner将IBM Security AppScan列为应用程序安全测试的市场领导者。

阅读Gartner报告 。

本教程面向熟悉静态分析的IBM Security AppScan Source和IBM Security AppScan Source for Analysis客户端的当前用户。 为了简洁起见，在本指南的其余部分中，我将产品称为“ AppScan Source”或“ AppScan”。

尽管AppScan Source多年来一直是静态分析安全测试（SAST）的市场领导者，但仍无法立即获得理想的结果。 实际上，没有SAST工具具有该功能。 原因很简单：每个组织都是唯一的。 每个组织都编写自己的代码，并拥有自己的技术堆栈，该技术堆栈通常由数十个，数百个，甚至数千个可能公开或不公开提供，并且可能有或没有源代码的库和框架组成。 每个组织都有自己的应用程序安全策略和安全编码最佳实践，它们会影响他们调查的安全性问题的类型，并且根据风险评估，编程语言和其他因素，每个应用程序通常会有所不同。 这样一来，SAST工具就无法立即了解应用程序中使用的每个API的功能，或者无法从外部来源进入应用程序并对其进行适当清理的数据是否属于低优先级问题或五级警报。 例如，如果文件系统只能由管理员访问，那么使用未经处理就从文件系统上的文件读取的数据可能不会引起关注。 但是，如果其他用户可以在该特定应用程序之内或之外将文件上传到该服务器，则情况将发生巨大变化。

现在，人们可以说AppScan Source仍然应该能够开箱即用地提供有意义的结果集，即使它无法识别出对用户重要的每个API或每个小细节。 这正是AppScan Source通常要做的。 AppScan Source具有成千上万条规则，告诉它各种API的功能。 它还支持最新的框架，例如ASP.NET MVC，Spring，Struts和JSF等。 AppScan Source还提供了一组过滤器，允许用户单击或单击两次即可将通常被认为是高优先级的问题归零。 使用开箱即用的过滤器进行扫描的结果通常是非常好的，并且许多用户不需要再检查那一点之后的结果。 但是，也有许多人希望将他们的发现推向新的高度。 他们希望真正了解涵盖了多少应用程序，以提高覆盖率，并将扫描结果微调到其应用程序安全策略或安全编码最佳实践。 AppScan Source通过使用内置工具（例如“源和接收器”视图，“自定义规则”向导和“过滤器编辑器”）使此分析相对容易进行。

本教程中描述的过程将指导您使用这些工具来帮助实现所需的自定义适应。 与往常一样，此解决方案不能解决所有问题。 此外，这不是获得所需结果的唯一方法，AppScan Source的一部分还提供了其他工具来帮助您（例如Framework for Frameworks API），这些工具不在本教程的讨论范围之内。 就是说，本教程应帮助您产生一套全面的可行结果，以备审核之用。 成功运行扫描并获得初始结果后，此过程开始。 但是，因为进行干净的扫描且编译错误很少是至关重要的，所以我认为将其包含在下面的“扫描应用程序”部分中已经足够重要。 请记住，您需要具有使用AppScan Source for Analysis客户端和在您的环境中创建自定义规则的权限，才能遵循本指南。

本指南中描述的做法分为以下几个活动阶段：

• 阶段1：扫描应用程序
• 阶段2：评估并扩大覆盖范围
• 阶段3：筛选结果
• 阶段4：分析/排序/捆绑结果

阶段1：扫描应用程序

在继续执行本教程中描述的过程之前，请确保：

• 扫描中包括了大多数（如果不是全部）应用程序的代码库
• 该应用程序已编译/扫描，没有任何重大错误
• 初始扫描成功完成

注意：如果扫描中有太多编译错误，则代码覆盖范围可能会受到严重影响，并导致不良结果。 由于AppScan无法自动分析无法编译的类，因此这也可能导致您需要更多的人工来分析如此糟糕的结果。 在继续下一步之前，应解决大多数编译或扫描错误。

阶段2：评估并扩大覆盖范围

此阶段的目标是了解扫描期间覆盖了多少应用程序，并在必要时通过创建自定义规则将覆盖率提高到可接受的水平。

在此阶段花费的时间可能从执行覆盖范围的基本评估所需的几秒钟到需要显着提高高度自定义应用程序的覆盖范围的几小时不等。 此步骤需要花费多长时间取决于扫描工作的目标，正在分析的应用程序以及其他因素。

注意：在此阶段，不要考虑整个跟踪（数据流）。 关注于您正在检查的方法，因为该方法的功能不会从一个数据流更改为另一个数据流。 例如，无论查询中的数据来自属性文件还是来自网页上用户的输入， SqlQuery.execute(query)方法都以相同的方式执行查询。 因此，如果您在此步骤中检查SqlQuery.execute()方法，则应仅考虑该方法的功能以及它是否表示关注点，而不是考虑数据可能来自何处（当我处理该关注点时，讨论过滤器）。

在此阶段中，需要执行几个步骤：

• 步骤1：查看发现的来源
• 步骤2：定义“已知”但缺少来源
• 步骤3：找出丢失的汇
• 步骤4：定义接收器且不易受污染方法影响
• 步骤5：定义异味传播者
• 步骤6：找出其他遗失来源
• 步骤7：重新运行扫描

步骤1：查看发现的来源

打开“源和接收器”视图并查看所有源，以对数据的来源有一个较高的了解。 根据应用程序的预期来源检查显示的来源类型。 例如，如果应用程序是使用数据库的Web应用程序，则应该看到Web和数据库源（请参见图1）。 该应用程序可能仅在写入数据库而不是从数据库读取，但是您应该仔细检查以确保。

图1. Sources和Sinks视图，其中扩展了Web和数据库源

您还可以在“发现”视图中查看类似的信息，方法是单击其工具栏上的“ 选择树层次结构” ，然后选择“ 源” 。 现在，视图左侧的树结构应该由Sources进行组织。

步骤2：定义“已知”但缺少来源

现在您已经知道存在哪些源，请询问应用程序的开发人员是否有任何Web服务方法或其他自定义技术将数据带入您无法在Sources下看到的应用程序中，并询问它们如何工作。 AppScan Source支持许多最受欢迎的Web服务定义框架，例如JAX-RS和JAX-WS，但是即使应用程序正在使用这些框架，也可能存在其他技术。 因此，仔细检查始终是一件好事。 在“自定义规则”向导中定义此类方法作为源或污染的回调（在“自定义规则”视图的工具栏中单击带有加号的图标）。

源是一种返回污染数据的方法，而污染回调是一种通过其参数（通常是从外部实体）接受污染数据的方法。 请考虑以下方法：

• 示例1：字符串user = request.getParameter(username);
• 示例2：公共布尔isValidUser(username, password){ ... }

在第一个示例中， request.getParameter检索用户从Web输入的HTTP参数username的HTTP值。 它返回用户输入的值，该值可能是危险的（因此是受污染的），这意味着它是受污染数据的来源。 此方法接受的参数并不危险。

在第二个示例中， isValidUser(...)是公开给应用程序各种客户端的Web服务方法。 如果提供给此方法的数据来自应用程序外部， 则除非得到证明，否则不能信任它！ 如果用户或客户端调用此方法，则他们将提供要验证的用户名和密码。 而且由于isValidUser通过其参数接受污染的数据，因此它是污染的回调。 这里的返回值是true或false，通常不表示威胁。

重要提示：如果您无法从同事那里获得有关丢失来源的信息，或者如果他们的建议对您没有帮助，则可以使用“扫描范围–无痕迹”中所述，如“识别其他丢失的来源”中所述。 但是，问一个知道该应用程序的人通常是一种更快的方法。

步骤3：找出丢失的汇

接收器丢失是AppScan Source无法理解的API。 跟踪停止，因为AppScan不知道所遇到的代码能做什么，因此无法继续进行跟踪。 没有规则，也没有源代码可帮助AppScan Source分析API，这对扫描范围有负面影响。 对于当今市场上大多数执行数据流分析的SAST产品而言，这是一个挑战。 AppScan Source将丢失的接收器归类为“扫描覆盖率发现”，使您有机会查看它们并提高扫描覆盖率。 接收器丢失的发现显示为带有以接收器丢失方法结尾的迹线的发现。 解决丢失的接收器通常可以为您的工作带来丰厚的回报，因为仅创建一些自定义规则或查找关键的丢失接收器API的“缺失”源代码都可以大大提高扫描范围。 丢失关键接收器的API是具有大量跟踪（发现）的API。 您可以在Sources and Sinks视图的Lost Sinks下看到Lossink信息（请参见图2）。

图2. Sources and Sinks视图-丢失的接收器

解决丢失的接收器时，首先要问的问题是所涉及的API是否真的是第三方API。 如果它是第三方API（无论是否开放源代码），那么您可能将没有代码。 如果它是由您自己的组织创建的API，请检查以确保您的文件系统上没有源代码。 如果这样做，则扫描配置可能存在问题。 如果您没有源代码，则可能需要访问它。 即使您决定不包含它，也需要一个有意识的决定，因为不包含它可能会影响相关代​​码的覆盖范围，如“ 扫描应用程序 ”中所述 。 这个思考过程通常只需要几秒钟，但是对最终结果却有很大的影响。 最后，如果您确信扫描中包含了源代码，但是仍然显示为丢失的接收器（这是不太可能的，但仍然可能），那么请按照以下说明继续进行接收器分辨率的丢失。

您可以通过为其创建自定义规则来“解决”丢失的接收器。 为此，请在“源和接收器”视图或“跟踪”图中右键单击丢失的接收器。 您还可以使用“自定义规则”向导解决丢失的接收器。 下面，我讨论了不同类型的丢失接收器及其解决过程。

步骤4：定义接收器且不易受污染方法影响

使用“源和接收器”视图按其名称空间查看所有丢失的接收器。 查看列表，并寻找“水槽且不易受污染的方法”。 仅为这些方法创建规则。

识别接收器：对于特定的丢失接收器，问自己一个问题：“在进入此方法之前，我是否应该检查/验证/清除数据？” 如果答案是肯定的，那就是一个接收器。 例如，如果丢失的接收器将数据传递给外部系统，第三方库，数据库或用户，则它是接收器，您可能应该在离开“控制范围”之前检查数据。 接收器方法如下所示： dbQuery.execute(...) ， netManager.send(...) ， httpResponse.write(...) ， thirdPartyLibrary.doSomething(...) ， backEndService.run(...) ， 等等。

图3显示了一个丢失的接收器的示例，该接收器实际上是一个接收器– logTransaction()方法，用于记录交易信息（包括敏感的信用卡数据到纯文本日志文件）。

图3.丢失的接收器示例实际上是一个接收器

识别不受污染的方法：对于特定的丢失接收器，问自己一个问题：“在任何应用程序中，是否有可能使未经检查的数据丢失丢失接收器的情况？” 如果回答为“否”，则丢失的沉没方法对污秽不敏感。 标记为此类后，将删除所有使用此方法的迹线，因此，应谨慎使用“不易污染的”规则。

切记：仅考虑丢失的接收器方法，而不考虑丢失的接收器可能导致的整个数据流或其他方法。 原始的污点将继续通过丢失的水槽。

步骤5：定义异味传播者

定义污染传播者的方法有两种，选择正确的传播者非常重要 。 正确使用两种方法，并充分了解其优点和缺点并加以考虑时，这两种方法都非常有效。

污染传播者方法不会“生成”污染数据，并且通过内部的代码不会发生漏洞。 但是，如果将污染的数据（通常通过参数）提供给此类方法，则它将沿数据传递（通常通过返回值）。 污点传播器的示例为string.subString(...) ， string.append(...)和base64.encode() 。

图4显示了一个丢失的水槽的示例，该水槽实际上是一个污染传播者。 在此示例中， decodeBase64()方法将存储在cookie中的base64编码帐户列表转换为可由应用程序使用的纯文本列表。

图4.丢失的水槽示例实际上是污染传播者

当您将某个方法标记为污点传播者时，AppScan Source会认为其所有输入参数都是污点或危险的，以及其返回值和指针。 换句话说， AppScan现在将跟踪通过任何参数输入并通过此方法的返回值输出的数据 ； AppScan还将在以后引用该对象时对其进行任何污染。 下文所述的每种方法都以不同的方式使用异味传播者规则的概念和功能。

快速嘈杂的方法

当时间至关重要（并且应用程序覆盖范围不足）或执行工具辅助代码审查时，这种方法在一次性审查情况（例如，概念验证）中最有效。 仅当污染传播者（如果不是所有规则）在比赛结束时被扔掉时，才应使用此方法。

在“快速且嘈杂”的方法中，所有剩余的丢失的接收器都标记为污点传播者，无论它们是否实际上传播了污点。 这样可以使AppScan快速捕获以前从未观察到的全新数据流和行为。 但是，与此同时，这种做法也会导致痕量爆炸。 请记住，现在正在跟踪每个丢失的接收器方法的每个参数和返回值，从而为每个方法至少产生一个新的跟踪。 而且，由于并非所有标记为异味传播者的方法实际上都会传播异味，因此使用这种方法会引入很多错误的数据流（在现实生活中不存在），因此，结果是产生了很多噪音。

也就是说，如果处理得当，噪音不一定是坏事。 尽管这些发现不是有效的安全问题，但它们仍然可以提供对正在分析的应用程序的深刻见解。 使用过滤器（使用“过滤器编辑器”中的“跟踪”部分）通常很容易删除它们。 毕竟，比起将它埋在田野里来，更容易判断是胸前装满了黄金还是装满了煤。 这种方法在基于污点传播查找潜在漏洞方面非常有效。 仅当污点传播达到危险方法（下沉）时，此方法才会产生发现。 在报告作为污点传播规则结果的发现之前，请验证标记为污点传播者的节点实际上是在传播污点数据，而不是污点爆炸的结果。 您仅需要针对有限的一组发现执行此操作。

从长远来看，噪声确实开始成为问题。 尽管通常在单个应用程序的上下文中删除它相对容易，但是在查看企业中的许多不同应用程序时却很难控制。 它还会使用大量伪造的污染传播程序污染自定义规则数据库。 在这种情况下，需要格外小心，并应使用以下所述的长期清洁方法。

要将所有剩余的丢失的接收器标记为污点传播者，请打开“源和接收器”视图，右键单击“ 丢失的接收器”节点，然后选择“将所有丢失的接收器标记为污点传播器” 。

清洁，长期的方法

当AppScan Source是企业正在进行的安全工作的一部分时，此方法最有效。 自定义规则是在多次扫描中创建和维护的，用于分析多个应用程序。

由于创建的任何规则都将持续用于分析各种应用程序，因此使用此方法时，在创建规则时需要格外小心。 鉴于污染传播者容易产生噪音，这尤其如此。

在干净，长期的方法中，您需要实际检查剩余的丢失的接收器，并要求每个接收器：“它会传播污点吗？” 仅在绝对确定进入方法的污点已转移到调用的返回值或转移到对象的指针时，才将丢失的接收器标记为污点传播器。 污点传播者的好例子包括集合，哈希图和诸如doc.parse(taint) 。

这种方法花费更多时间，但是如果规则是在多次扫描中累积的，则可以避免很多麻烦。

步骤6：找出其他遗失来源

尽管AppScan Source无法自动识别丢失的源，因为AppScan无法识别的每种方法看起来或多或少都是相同的，但它可以提供“面包屑”或指针来帮助您识别它们。 这些指针以没有可用跟踪信息的扫描覆盖范围发现形式显示（扫描覆盖范围–无跟踪）。 仔细研究这些发现可能很耗时，并且不一定会在每次参与中都发生，但这是识别丢失或丢失的资源的重要方法，尤其是在没有人问的情况下。 但是，总的来说，就像我之前说过的，问一个知道该应用程序的人要快得多。

扫描范围–找不到跟踪可能意味着几件事：

• 它是无效代码或类似于Web服务的调用，没有任何东西调用发现所标识的方法。 最好为这种方法创建污染的回调规则。
• 从内部集合或存储对象中检索数据。
• 这是一个失去的来源。 您必须遵循代码回到入口点（或询问开发人员）。

图5显示了一个“扫描范围–无痕迹”示例，该数据发现数据来自内部存储对象“帐户”。 请注意，此发现没有痕迹。

图5.扫描范围示例－找不到踪迹

提示：如果为源和受污染的回调创建了自定义规则，但在重新扫描后它们没有效果，则可以通过启用“ 自动污染回叫”标记选项来排除扫描故障。 要启用它，请在“扫描配置”视图的“高级设置”部分中将其设置为True ，以获取用于扫描的扫描配置。 这会使AppScan Source污染正在分析的应用程序中每个公用方法的每个参数。 反过来，这导致AppScan在应用程序中显示各种各样的数据流，从而提供了对潜在数据源的大量洞察力，并产生了很多噪声。 大量噪音是通常仅在自定义源和受污染的回调规则无法产生所需效果时才使用此选项的主要原因。

在应用程序中看到数据流之后，您可以将其与源代码一起分析，以找到AppScan可以看到的源和受污染的回调方法。 然后，可以为下一次扫描禁用“ 自动污染的回调”选项。 您也可以简单地使用过滤器来找出扫描结果中的漏洞，但是这种方法不如使用自定义规则强大。

步骤7：重新运行扫描

要应用规则更改，必须重新运行扫描。 检查项目属性的“概述”选项卡上的“ 启用漏洞分析缓存”选项可能很有用。 这样可以避免AppScan始终都必须重新编译代码，而是可以让其记住在代码更改时清除缓存！

冲洗并重复并...

重复七个步骤，直到获得满意的覆盖率。 您可以通过将“扫描范围”发现的数量与“确定+可疑”发现的数量进行比较来判断。 较少的“扫描范围”结果会更好。 丢失接收器的发现也应该仅由几种丢失接收器的方法来贡献。

阶段3：筛选结果

此步骤的目标是显着减少发现的数量，并专注于那些被认为是最重要的，因此也是您最感兴趣的发现。 换句话说，您要删除“噪声”和“误报”，即客户不关心的问题。 顺便说一句，您要过滤掉的大多数发现可能实际上并不是“误报”。 通常，它们通常被认为“足够难以利用”。

筛选器的最重要目的之一是强制执行组织的“安全编码最佳实践”策略 。 许多组织从针对所有应用程序的单个过滤器开始，或针对少数不同编程语言或风险级别的少数几个过滤器。 但是，要进行详细的审查，很少有“一刀切”的过滤器。 开箱即用的过滤器提供了一个很好的起点，甚至可能足以根据您的目标获得所需的结果。 “！-AppScan非常重要”和“！-高风险来源”都是很好的过滤器。

严重程度和分类

在“过滤器编辑器”视图中，仅关注“高严重性确定”和“可疑”结果。 对于大多数过滤器来说，这是一个很好的起点。 尽管“可疑”发现的信度比“确定”的发现低，但是您通常会在此发现一些非常有趣且重要的漏洞（例如，SQL注入）。 图6显示了具有这些设置的过滤器。

图6.过滤器编辑器–严重性和分类

专注于高风险来源

快速获得最关注您的结果的第一种方法是使用“筛选器编辑器”的“跟踪”部分来限制发现，以仅包括来自易于利用的来源或属于高风险接收者的发现。 例如，您可以通过在新跟踪条目的“源”部分中添加Technology.Communications.HTTP属性来关注来自Web的数据。 您可以通过定义该数据来自于特定的方法进一步集中你的资源。例如，你可以定义javax.servlet.ServletRequest.getParameter()中的一个跟踪条目和javax.servlet.http.HttpServletRequest.getQueryString()在另一个仅检查来自这两种非常容易利用的方法的数据。 图7显示了在过滤器编辑器的“跟踪”部分中定义的这些源。

图7.筛选器编辑器-专注于高风险源

这种方法使您可以快速评估应用程序中最重要的发现，但消除了您可能有兴趣进一步调查的其他发现。 一种更彻底的方法是消除安全源和汇。 有关详细信息，请参见“ 消除安全的源和接收器 ”。

添加第一个条目后，“跟踪”部分的“限制”部分中的每个新条目都会通过显示不符合先前“限制”条目标准的发现来扩展结果集。

消除安全源和汇

第二种更彻底的方法是使用“筛选器编辑器”的“跟踪”部分来删除来自源或进入接收器的发现，这些发现构成的风险很低，被认为是“安全的”。 与专注于高风险来源相比，此方法通常需要更长的时间，但通常会导致更全面的结果。 那是因为您查看结果并决定什么是“安全的”，而不是仅仅假设什么是危险的。 安全操作可能包括来自属性文件和环境变量的数据，以及进入诸如日志记录API或“类似复制”操作之类的方法，在这些方法中，您从一个存储属性中获取一个值，然后将其存储在另一个存储属性中。

提示：认为安全的方法可能因应用程序而异，所以请当心！ 例如，在文件系统上读取数据文件的方法可能被认为是安全的，但是如果允许用户将文件上传到服务器，则您将无法再信任文件系统上的文件，并且您不能认为它们是安全的。 属性文件通常是可以的，除非它们正在读取“秘密”并且这些秘密未经过解密。 这表示明文密码存储。 如果这是一个问题，则“源和接收器”视图提供了一种快速的方法来了解数据通过源进入之后的最终位置，并区分您和您可能关注的源到接收器流。被认为是安全的。 图8显示了使用“过滤器编辑器”的“跟踪”部分删除的一些“安全”源和接收器。

图8.过滤器编辑器–删除“安全”源和接收器

安全接收器提示：查找安全接收器时，可以在“查找”视图中获取特定源到接收器组合或特定接收器的上下文信息。 然后，您可以按上下文信息进行排序，以便将具有相似上下文的所有发现组合在一起。 通过扫描上下文中的有趣单词，您可以快速滚动浏览数千个结果。 这样做，请单击“结果”视图工具栏上的“ 选择和排序列 ”，然后添加“上下文”列。 例如：记录API的debug / warn / info / error方法通常是“嘈杂的”接收器。 但是您仍然可能希望查看所有上下文信息，以查看是否包含“信用卡”，“ SSN”或“密码”。 这通常表示信息泄漏，并且可能是一个非常重要的发现。 通过查看“结果”视图中的“上下文”列可以很快排除不相关的结果。

“跟踪”部分的“删除”部分中的每个新条目都通过隐藏不符合先前条目条件的发现来缩小结果集。

基于过滤器的验证

使用过滤器是删除经过验证的结果的首选方法，而不是使用自定义规则执行相同任务。 区别在于，您不仅可以了解哪些发现已被删除，而且不仅可以在今天，而且可以在未来一个月和一年内删除。 这是因为过滤器可以轻松地“逆向”，而规则则不能。 基于过滤器的验证还可以对组织中的各种数据流和应用程序进行更精细的验证控制，因为您甚至可以针对单个应用程序使用不同的过滤器（或过滤器组合）。

要指定基于过滤器的验证器，请转到“过滤器编辑器”视图。 在“跟踪”部分的“删除”区域中，添加一个新条目； 然后在“必需的调用”部分中指定一种验证方法（包括其名称空间），并指定该验证器/清除程序所适用的接收器（或接收器属性中的漏洞类型）。 图9显示了定义基于过滤器的验证条目。

图9.定义跟踪规则条目以执行基于规则的验证

重要提示：始终通过“反转”检查过滤器，以确保没有重要的发现意外丢失。

要反转过滤器，请在“过滤器编辑器”中将其选中，然后在“结果”视图工具栏上单击“ 显示与过滤器不匹配的结果”。 您也可以在扫描后自动应用过滤器的逆函数（请参阅“ 共享过滤器并保存过滤的结果 ”）。

漏洞类型

使用“筛选器编辑器”的“漏洞类型”部分，删除低优先级的发现类型或将类型限制为仅少数几个最高优先级的问题类型。 最后最好执行此操作，以免意外删除带有有趣发现的问题类型，因为在发现所有杂音的情况下，可能不会注意到这些发现。

共享过滤器并保存过滤结果

创建过滤器后，可以通过在“过滤器编辑器”工具栏上选择“ 共享过滤器 ”来与其他人共享 。

您也可以在扫描完成时自动应用过滤器（仅显示和保存过滤的结果）。 要进行设置：

1. 转到项目或应用程序属性，然后选择“过滤器”选项卡。
2. 将您创建的一个或多个过滤器添加到“过滤器”列表中。
3. 如果您想确保过滤器不会删除任何重要的发现，可以使用窗口底部的“ 反转”选项来反转过滤器，以便仅显示通常被删除的发现。

提示：如果评估结果将发布到IBM Security AppScan Enterprise，请在发布之前创建一个预先过滤的评估。 这样可以避免IBM Security AppScan Enterprise报告中出现干扰。

要保存预先过滤的（部分）评估而不重新运行扫描，请执行以下操作：

1. 在“过滤器编辑器”中应用过滤器，以查看要保留的问题。
2. 在“发现”视图中选择所有发现（单击发现，然后按Ctrl + A或在Mac⌘+ A上按 ）。 如果您不想保存通过过滤器的所有内容，也可以只选择要保存的发现。
3. Click on the Save Selected Findings icon on the Findings view toolbar and save the assessment. That icon resembles a floppy disk with an arrow over it.
4. Open the assessment file you just saved to see only filtered results.

Phase 4: Analyze/Sort/Bundle Findings

The goal of this step is to review filtered findings, further improve filters, bundle the findings in a way that makes sense (for example, by issue type, developer, and so on), and distribute them to developers for fixes. Again, the time required for this step depends on your application, your goals, and the quality of your filters. For example, if the scan is run by a build system and a proper filter is set up, scan results can even be provided directly to developers and this step can be skipped altogether.

That said, it is usually best to review findings before distributing them. When reviewing findings, verify that:

• Each source is relevant for this application
• Each sink is relevant according to the business risk of the application
• There are no obvious "validation" methods between the source and sink

If these three conditions are not easily checked off, then a little more digging may be required on your part. Use this information to further improve filters you created earlier.

Tip: You can hide bundled findings (findings that were already reviewed) from the Findings view by pressing Hide bundled findings on the Findings view toolbar.

摘要

The process described in this tutorial is very iterative in nature. As you proceed from one step to the next, you may discover things that were important for one of the previous steps. Typically, you would then go back to provide AppScan with this additional information. The goal is to start at a high level and let AppScan do the work for you, improving coverage through custom rules and focusing on issues of concern through filters. In this way, you do not just dive into the sea of findings trying to make sense of it all. As you focus your findings through the filters, you will be able to get more and more fine-grained in what you want and what you do not want to see. At the end, you should have relatively few findings left that are of concern to you and yet cover more of the application than on the initial scan. And, best of all, you will be able to reuse the fruits of your labor on future scans of this application and even on scans of other applications because both rules and filters can be easily shared, saving you time and effort on your future assessments.

---

翻译自: https://www.ibm.com/developerworks/security/library/se-sourcescanbest/index.html

ibm appscan