修复组
修订组当前仅适用于在静态分析扫描中发现的问题。
修订组是一种管理、分类和解决在静态分析扫描中发现的问题的新方法。运行静态扫描后，AppScan 360° 会根据漏洞类型和所需补救任务将发现的问题组织到修订组中。在每个新的静态扫描中，系统会将新问题添加到这些组中，并根据需要创建新的修订组。
- 通用修复点
- 包含具有相同漏洞的问题。整个组可以通过一个修订方法（一个代码点）来修复。
- 常见 API
- 包含与同一 API 调用相关的问题。如果具有相同根本原因的发现结果无法放入共同修订点组中，那么共同 API 组会将这些发现结果放在一起。这将减少审核结果和应用修订时的上下文切换。通常，每个受影响的发现结果的修订都类似；可以将同一个修订应用于组内的所有问题。
- 公共开源
- 包含第三方代码中根据找到这些问题的库标识的问题。针对应用程序中标识的每个易受攻击的库，创建一个修订组。根据特定库中找到的漏洞数，每个修订组可以有一个或多个漏洞。同一修订方法可以应用于组中的所有问题。
任何组中的问题始终具有相同的漏洞类型。
修订组严重性
修订组严重性由其包含的所有问题中的最高严重性确定。
修订组状态
仅当组中的所有问题的状态相同时，才会指定修订组状态。
更改组中所有问题的状态时，可以选择是否将状态应用于从未来扫描中添加到组中的问题。如果状态不应用于未来问题，则在添加新的问题时，组的状态将更改为混合。
教程
示例
共同修订点修订组
在以下图像中，有五个参数（id、name、email、subject、message）最终使其 DBUtil.java 中第 194 行的修订点 new Feedback。虽然 id 是一个 int，而不是跨站点脚本编制的可攻击向量，但其他四个参数都是可攻击的，必须予以补救。
跟踪告知我们存在五种不同的症状，并且由于不同行上出现的 out.print 调用，该症状会进入浏览器页面。如果 new Feedback 调用将允许的字符列入允许列表，或者对构造函数内的这五个实体的数据进行某种清理/验证，那么将解析该修订组的所有发现结果。如果忽略该修订组修订点，那么需要为其中每个发现结果添加四个不同的编码调用。
共同 API 修订组
在此示例中，有两个发现结果具有相同的根本原因（输入字符串没有转义）。每个问题都需要单独解决，但是此修订类似，或者在这种情况下，这两个实例完全相同。
共同开源修订组
在此示例中，发现该库有八个不同的漏洞。因此，创建了一个修订组以显示此库的所有漏洞，从而加快了审核与该库相关联的每个漏洞的过程。
