在代码扫描的结果出来之后，真正让人费时间的，往往并不是去打开那份报告，而是要把每一条缺陷到底是不是真的问题给分辨清楚；关于Fortify Audit Workbench里头的审计状态该怎么去改，以及审计的记录又该怎样导出来，这里面的关键步骤，就是先在Issues这个视图当中把要处理的缺陷给选中，然后再到Audit页签的下面去填好分析结论、标签和备注。官方的文档上也有说明，Audit Workbench这个工具是能够用来打开FPR项目并对里面的问题进行审计的，不过假如许可证对审计功能有限制的话，那就只能去看看结果和生成报告，没有办法对审计项目做修改了。

　　一、怎么改动审计状态

　　在Audit Workbench里改动审计状态的时候，可不要仅仅为了让缺陷的数量看起来变少就去随手标记，这个状态本身应该要能够反映出我们对这条问题的真实判断，比方说它是可被利用的、看起来可疑的、属于误报、是一种不好的实践，又或者是可靠性方面的问题。

　　1、打开FPR项目

　　先把工具启动起来，通过菜单里的【File】到【Open】去选择那个扫描生成的FPR文件，等项目打开了以后，就可以在Issues视图中按照严重程度、分类或者文件路径这些条件来做筛选了，处理的时候，最好是从那些风险高而且会影响到版本发布的缺陷开始下手。

　　2、选中要审计的问题

　　在问题列表里面点中某一条缺陷，然后去查看界面下方或者右侧的Audit页签、它的调用路径、源代码位置还有Details里面的具体信息，千万不要只看个标题就去改状态，至少也得把入口参数、触发点、数据流和实际代码的上下文这些内容都确认一下。

　　3、修改Analysis这个字段

　　在Audit页签当中找到Analysis这项，选出一个合适的分析值来，按照OpenText的文档说明，这个主标签的默认名称就是Analysis，它下面有效的值包含了Not an Issue这种表示不是问题的，还有Reliability Issue、Bad Practice、Suspicious，以及Exploitable可被利用的，这个主标签一改，会直接决定这条问题的审计状态，还有它在Issues视图里显示的那个审计图标。

　　4、把审计备注补上

　　在Comments里面要把判断的依据给写明白，比如输入是不是可控的、有没有经过校验、是不是受到了权限的限制，或者这个问题到底修没修好；到了有多人一起参与审计的时候，备注千万别只简单地写个“已确认”或者“误报”，那样后面的人做复核就很难弄清当初的根据了。

　　二、审计记录怎么导出

　　从Audit Workbench往外导出审计记录，常用的办法一般也就是两种：一种是直接保存那个已经带上审计状态的FPR文件，它的好处是方便后面接着审计；另一种就是生成一份报告，拿给开发、测试或者安全方面的负责人去看，这个做法对评审和归档会更合用。

　　1、先把审计项目保存好

　　在状态改完之后，要点击【File】下的Save或者Save As，把当前的FPR给保存下来，也只有这么做，那些审计状态、备注、抑制信息和标签才会跟着项目文件一起留下来；要是光关了窗口却没有存盘，等下回再打开的时候，说不定就看不到刚才的那些判断了。

　　2、去生成报告

　　接下来，顺着菜单点【Tools】到【Reports】再选【Generate Legacy Report】，再从模板里面挑一个合适的，比如面向开发整改的或者面向管理汇总的；官方文档上说明了，Legacy Report是能够直接从Audit Workbench生成出来的，并且生成好了以后还能再另存成PDF、RTF以及XML这几种格式。

　　3、按照筛选的范围来导出

　　在导出之前，最好先在Issues视图中按Analysis、Severity、Folder或File这些条件筛一下，仅仅把那些真正需要复核的问题给挑出来；要是准备把结果交给开发去整改，那就要建议在导出的内容里头，把文件路径、行号、漏洞类型、审计状态、备注，还有修复的建议这些字段都给保留住。

　　4、需要协作的时候上传到SSC

　　要是团队里还在用Fortify的SSC管理平台，也可以把这审计完了的FPR传到对应的应用版本上去，好让审计记录在平台里头继续走下去；不过在上传之前，一定得先确认好应用版本跟扫描批次能对得上，免得把老的审计结果给错传到别的版本里头去了。

　　三、导出以后要怎么核对

　　审计记录导出来了以后，还得再去检查一遍，看看那上面的状态全不全，备注读不读得懂，以及报告覆盖的范围到底对不对；其实很多在交付上出的问题，倒不是因为内容导不出来，而是导出来的东西没法支撑后面的复核。

　　1、检查有没有未审计的项

　　在Issues视图里面，专门按Analysis是空的或者还保持着默认的值这种条件再过一遍，确认还有没有落下的问题没有处理；高风险的缺陷自然是不能漏掉的，即便是那些低风险的，也得把后续打算怎么处理的统一口径给说清楚。

　　2、检查那些被抑制处理的问题

　　要是在审计的时候用到过Suppress功能，那就得通过菜单里的【Options】下面Show Suppressed Issues把它们给显示出来，并再核对一次；按官方文档上的说法，Suppress这个操作会把当前这条问题以及往后重新扫出来的同一条，全都给打上被抑制的标记，这种标记相对来说是偏长期的一种处理。

　　3、检查报告里的那些字段

　　把已经导出的PDF、RTF或者XML文件打开，看看里面的审计状态、备注、文件路径和行号这些信息是不是完整的；要是报告只列了个漏洞清单，却没有显示出审计的意见，那就得回到报告模板的设置里头重新勾选需要的字段，或者干脆换一个更合适的模板来用。

　　4、把版本的对应关系给留下来

　　导出来的这份报告，应该要跟那次审计用的FPR文件、扫描发生的时间、代码当时所在的分支，还有规则包的版本这些信息放在一起保管；因为代码一旦更新过了，旧的那些审计记录就不一定还能对应得上变动后的新代码行，后面再做复核的时候，是一定要先把版本的信息给看清楚的。

　　总结

　　总的来讲，Fortify Audit Workbench里面审计状况怎么去改，以及审计的记录又该怎么往外导，这里边的核心做法就是先待在Audit那个页签里头，结合实际代码的上下文去把Analysis这一项给改掉，并且将Comments的备注内容给补充上去，在这以后再保存好FPR，或者是通过Generate Legacy Report这个功能把报告给导出来；等到导出完成了之后，还要再去核对一下那些还没审计的、被抑制掉的、报告里面的各个字段，以及跟代码版本有关的信息，这么一来，才能免得审计记录看上去像是已经齐全了，可真到了要拿去搞整改或者给安全评审用的时候，却完全支撑不起来。