Fortify

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 Software Security Center的官方文档写得很清楚，角色负责定义一个用户能做哪些动作，应用版本访问则决定这个用户能看和能操作哪些项目；同时，系统还支持自定义角色、LDAP角色映射，以及把用户单独分配到具体应用版本。也就是说，权限设计不是只建几个角色就结束，而是要把“能做什么”和“能进哪几个项目”分开管。

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 SCA时，最容易把“翻译源码”“执行分析”“生成FPR”“上传SSC”当成一个动作去理解，结果前面命令是跑了，后面要么FPR没生成出来，要么上传到SSC时报权限或版本定位错误。OpenText官方文档对这条链路分得很清楚，SCA至少包含翻译和扫描两个阶段：先通过`sourceanalyzer`用同一个build ID把源码或构建过程收进分析上下文，再通过`-scan-f`把结果输出成FPR文件；上传到SSC，也就是当前文档里的Application Security，则要改用`fortifyclient uploadFPR`，并且必须先拿到能上传分析结果的认证token。也就是说，FPR生成和SSC上传本来就是两段流程，不能混着看。

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】这个参数来标记一次构建过程，并且通过这个ID来跟踪这次构建里被编译和组合了哪些文件，到了后面的扫描阶段，也得用同一个Build ID去读取前面翻译时产生的那些中间文件。所以Build ID不能随随便便就取成test、scan、project这种太笼统的名字，不然的话，来自不同分支、不同模块、不同流水线的数据，就很容易出现互相覆盖或者叠在一起的情况。

在企业把SAST扫描接入自动化流水线之后，经常会碰到一个让人头疼的问题，那就是用Fortify ScanCentral提交的扫描任务，不是一直卡在排队的状态里，就是半天都跑不起来。要说清楚Fortify ScanCentral的扫描任务到底该怎么提交，以及任务一直排队又该怎样处理，需要先了解这套系统的基本运转方式：通常是由Client端把任务发出去，Controller这边负责接收请求，然后再把任务分给那些处在空闲状态下的Sensor去实际执行扫描。想要顺利地提交一个任务，事前得准备好Controller的地址、client_auth_token、SSC CI Token、应用的名称、版本的名称，还有要扫描的源码包，这些前置条件在官方的说明里也是被明确写出来的，它要求我们必须有SSC的URL、ScanCentral Controller的URL、客户端认证用的Token、SSC CI Token，以及已经在SSC里面建好的Application和Version。

很多团队做Fortify审计时，最容易乱掉的不是漏洞本身，而是状态口径和处理节奏。表面上看，大家都在给问题打标签，实际到了复盘时却发现同一类问题有人标成可利用，有人标成误报，还有人一直停在未处理状态，后面自然很难统计整改进度。OpenText官方文档对这件事说得很清楚，Application Security默认提供一个名为Analysis的标签来支撑审计，问题是否算完成审计，取决于主标签有没有被赋值；同时，平台还支持用custom tags、issue templates和application version profile把审计流程固定下来。也就是说，Fortify的审计状态不是随手写备注，而是要先把标签、主标签和状态映射定清。

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文件也能上传到应用安全的对应版本下面去阅读。

扫描文件明明已经传上去了，可是在页面上就是看不到对应的结果，这种情况在Fortify SSC的使用过程中并不少见；面对Fortify SSC项目里看不到扫描结果的问题，又或者是结果的同步出现了延迟，首先要做的一点并不是直接下结论说扫描失败了，而是要沿着“应用版本、账号权限、上传状态、处理队列、过滤条件、后台日志”这样一条线索去排查。Fortify SSC是以应用和应用版本为单位来管理结果的，在建立一个应用版本的时候，还要求把开发阶段、开发策略、访问级别等必要的属性填好，一旦版本给选错了，看上去就会很像结果被弄丢了。

很多团队在Fortify里说“基线没生效”，实际遇到的常常不是同一类问题。有的是新版本根本没有把上一版本的审计状态带过来，有的是FPR其实上传到了另一条应用版本上，还有的是制品已经上传，但因为处理审批或结果刷新没走完，页面上暂时看不到预期状态。Fortify官方文档把这几层分得很清楚，所以这类问题不能只盯着“规则有没有变”，而要把应用版本、应用状态复制、制品处理和指标刷新放在一条线上看。