Fortify

Fortify本地扫描完成后，通常会生成FPR文件，再上传到SSC集中审计。上传成功只说明文件已经送到服务器，结果是否进入正确版本，还要看目标版本、处理状态和审批规则。弄清Fortify结果怎么上传SSC Fortify上传SSC后项目版本没有更新怎么办，先要分清“更新扫描结果”和“新建项目版本”是两件事。

Fortify扫描时内存不足应当怎样处理，以及大型项目的扫描参数又该怎样调整，这是大型项目在接入SAST时很容易碰到的问题。Fortify SCA在扫描的时候，需要经过代码转换和安全分析这两个阶段，项目的代码量越大、依赖越多、语言越复杂，内存方面的压力就会越明显。OpenText的文档也说明了，扫描所需要的物理内存，会受到代码复杂度的影响，在默认情况下，它会根据系统可用的物理内存自动去分配，但遇到OutOfMemory的时候，可以通过-Xmx去调整Java的堆内存，也可以使用SCA_VM_OPTS来统一设置内存的选项。

在Fortify SSC里面，扫描结果并不是直接放在单独的“应用名称”下的，它是需要放在具体的某个【应用版本】里面。大家在做SAST扫描结果上传的时候，不能光看FPR文件是不是生成成功了，还要看SSC里面的应用版本是不是建对了，属性是不是都填完了，上传的目标有没有选错。至于Fortify SSC应用版本怎么创建，还有Fortify SSC版本上传后为什么看不到结果，一般能顺着“建版本、传文件、看Artifacts、查Audit页面”这条线去排查。

Fortify SSC的权限怎么分才合适，角色改完了怎么还是看不到应用，在安全平台多人一起用的时候，这两个问题是挺常碰到的，SSC不是光靠一个“管理员”或者“普通用户”的名头就能把访问权限管住的，它还得把角色的权限、应用版本的授权、项目团队的范围，还有认证的来源，这好几样东西揉到一块儿，才能去判断一个用户到底能干什么，按照官方文档讲的，角色的权限是能在用户管理的角色页面里查到的，一个角色到底能执行哪些操作，得一项一项去把它确认清楚。

在Fortify SSC这类安全平台上面，多人一起协作的时候，经常会碰到两个比较头疼的问题，一个是权限到底该怎么分配才算合理，另一个就是明明已经改完了角色，可用户登录之后还是说看不到应用。SSC控制访问权限并不是简单地给用户贴上一个“管理员”或者“普通用户”的标签就完事了，它会把角色本身所带的权限、应用版本这一级的授权、项目团队的划分范围，还有用户是从哪里做的身份认证，这好几样东西综合到一起来决定某个人到底能干什么。按照官方的说明文档，角色所对应的权限可以去【Administration】→【Users】→【Roles】这个路径里面查看，而且每一个角色底下到底能够执行哪些具体的操作，都需要一条一条地去核对清楚。

Fortify扫描结果里，有些问题经过人工确认后可以暂时不处理。直接删除扫描记录不合适，把问题留在主列表里又会影响统计，这时可以使用漏洞抑制。处理“Fortify漏洞抑制怎么设置Fortify抑制标记复扫后为什么消失”，要留意扫描结果有没有正确合并。抑制记录跟着问题身份走，复扫时被识别成了新问题，原来的标记自然带不过去。

Fortify过滤器怎么设置，以及Fortify过滤器把有效漏洞隐藏了又该怎么处理，这里的关键是先要分清楚“为了方便查看而做的过滤”和“在扫描阶段就直接把结果排除掉”这两件事情。在Fortify里面，是可以通过filter set、filter file、问题视图条件这些方式，去减少结果当中的噪音的，但如果规则设得太宽，就有可能把真实的漏洞也一起藏起来。官方的文档里面也提到过，使用filter set所隐藏的问题，当它在扫描阶段被应用的时候，是有可能不会被写入到FPR结果文件里面去的，对这一类的配置，需要特别谨慎。

关于Fortify Audit Workbench这个工具，用户可以用它来把FPR格式的结果文件打开，从而对Fortify SCA自动扫描出来的那些程序漏洞进行人工的检查、分类、写备注以及标记状态，这个工具不单单是用来查看报告的，它的主要作用是把一堆乱七八糟的扫描告警信息，整理成开发人员能看懂去修复、管理人员能看懂去追踪的最终结论，如果想知道Fortify Audit Workbench怎么审计漏洞，以及Fortify Audit Workbench审计状态怎么同步，操作人员需要重点关注漏洞的分析判断、状态的勾选标记、备注证据的填写以及最后的上传同步这几个步骤。

在进行SCA本地扫描或者ScanCentral打包翻译的时候，经常会碰到翻译阶段卡住不动的情况，这时候就要知道该从翻译日志的哪些报错信息开始查起。首先要明白，Fortify的翻译阶段本身并不等同于漏洞扫描，它实际上是通过sourceanalyzer工具，把源代码、配置文件或者构建命令，转换成和build ID绑定在一起的中间数据，等到后续的扫描阶段，才会再以这些中间文件作为基础，去生成最终的FPR结果。按照官方文档的解释，Translation这个步骤就是把源代码转成跟build ID关联的中间格式，然后Analysis阶段再去扫描那些已经识别出来的文件，并产生对应的结果文件。

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

Fortify完成静态分析后，通常会生成FPR文件，用于在Audit Workbench中审计结果，或上传到Fortify Software Security Center统一管理。处理“Fortify怎么导入分析结果，Fortify导入FPR文件失败如何处理”时，需要先区分是本地打开FPR失败，还是上传到Software Security Center后处理失败。两种场景虽然都表现为文件无法正常使用，但排查方向并不一样。

Fortify内置规则覆盖面很广，但企业自研框架、封装接口和内部安全规范，未必都能被准确识别。这时可以补充自定义规则。处理“Fortify自定义规则怎么创建Fortify自定义规则不生效怎么排查”，建议先准备一段最小测试代码，确认规则能命中，再放进正式项目。

Fortify漏洞路径怎么分析，以及污点传播路径太长的时候又该怎样筛选重点，是很多团队在复核SAST结果时都会碰到的情况。Fortify扫出一条SQL注入、命令注入、路径遍历或者跨站脚本问题，如果只在列表里看漏洞名称，那是不够的。真正要判断它是不是有效风险，还是要看数据是从哪里来的，中间经过哪些变量和函数，最后流向了哪个危险的调用。Fortify的数据流类问题会在Analysis Trace里面展示污染数据从source到sink的路径，审计的时候这条路径就是主要的判断依据之一。

Fortify ScanCentral通常指Fortify ScanCentral SAST，用来把本地构建机上的扫描任务提交到Controller，再由Sensor去执行分析。它和单机版SCA不太一样，问题不只出在命令本身，还可能出在Controller、Sensor、任务池、SSC上传权限这些地方。Fortify ScanCentral怎么提交扫描，Fortify ScanCentral任务排队太久怎么办，可以按“先提交成功，再看任务状态，再处理排队原因”这个顺序排查。

在开始使用Fortify做扫描的时候，Build ID这个参数要是没有提前规划好，后面会带来很多麻烦，比如不同分支之间的结果互相覆盖，或者扫描出来的数据莫名其妙串到一块儿去了。想要弄清楚Build ID怎么规划才不会乱，以及一旦重复了要怎么避免结果串线，就得先把Build ID到底是干什么用的给搞明白。在Fortify SCA这套工具里头，翻译阶段会用到【-b<build_id>】这个参数来标记一次构建过程，并且通过这个ID来跟踪这次构建里被编译和组合了哪些文件，到了后面的扫描阶段，也得用同一个Build ID去读取前面翻译时产生的那些中间文件。所以Build ID不能随随便便就取成test、scan、project这种太笼统的名字，不然的话，来自不同分支、不同模块、不同流水线的数据，就很容易出现互相覆盖或者叠在一起的情况。

Fortify SAST的漏洞识别能力主要来自Rulepack，项目还可以额外加载自定义规则，用于补充企业内部安全规范、第三方框架或特殊函数的数据流模型。处理“Fortify怎么配置扫描规则，Fortify扫描规则不生效如何排查”时，需要区分默认Rulepack、自定义规则和结果过滤三个层面。规则文件虽然存在，但没有真正被当前扫描任务加载，或者分析器、扫描参数发生变化，都可能出现预期漏洞不再报告的情况。

FPR文件里不只有漏洞结果，还可能包含源码片段、审计状态、注释和扫描信息。处理Fortify FPR文件怎么合并Fortify FPR合并后结果重复怎么办，先要明确目的：是把旧审计结果带到新扫描，还是把多个独立项目拼到一起。两种需求看着相近，处理方法却不一样。

Fortify的规则包应当怎样更新，以及规则包更新以后扫描出现的差异又该怎样去判断，这里的关键并不只是把规则更新到最新版本，而是需要弄清楚这次更新会不会改变扫描的结果。Fortify的规则包里面包含了安全规则和与之相关的元数据，SCA可以通过fortifyupdate这个命令去获取或者导入安全内容；在SSC里面，也可以从规则包的页面去执行服务器的更新。规则包发生变化以后，新增的漏洞、消失的漏洞，还有严重等级的变化，都有可能出现，因此在更新前后需要把基准结果保留下来，不能只盯着最终的漏洞数量去看。

在进行Fortify SCA扫描的时候，漏洞并不是立刻被寻找的，在这之前，代码需要经历一个很关键的翻译阶段，很多时候项目出现报错，原因既不在于规则包，也不在于扫描策略，而是代码没被Fortify SCA成功读取进去，关于Fortify SCA翻译阶段怎么配置，以及Fortify SCA翻译日志报错怎么定位，主要需要紧盯着三件事情，也就是构建ID要对得上，依赖路径不能缺失，还有日志里写出的到底是解析错误还是环境错误。

在安全扫描结束并交付结果的时候，大家通常先拿到的是一个FPR格式的文件，而不是直接打开平台的页面去看。要说清楚这个FPR文件到底该怎么打开，以及打开之后要是碰到字段显示不全又要怎么处理，主要取决于你是打算在本地用Audit Workbench来做审计，还是准备把它上传到Fortify Software Security Center里去统一查看。按照Fortify官方的文档说明，Audit Workbench这个工具能够帮助人们对扫描结果进行组织、调查，还有确定优先处理顺序，同时FPR文件也能上传到应用安全的对应版本下面去阅读。