Fortify

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

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

在Fortify里做权限，最容易出问题的不是按钮不会点，而是一开始就把“系统角色”和“项目访问”混成了一层。Fortify Software Security Center的官方文档写得很清楚，角色负责定义一个用户能做哪些动作，应用版本访问则决定这个用户能看和能操作哪些项目；同时，系统还支持自定义角色、LDAP角色映射，以及把用户单独分配到具体应用版本。也就是说，权限设计不是只建几个角色就结束，而是要把“能做什么”和“能进哪几个项目”分开管。

很多团队说做Fortify基线，实际做出来的却只是一次首扫结果。真正能长期拿来比新增、比移除、比审计效率的基线，关键不在“先扫一次”，而在“先把应用版本、模板、过滤口径和后续上传方式固定住”。Fortify Application Security会把新上传结果并入同一个应用版本的既有结果里，并判断问题是不是上一次就存在，问题在最新扫描里消失后还会被标记为removed，所以基线本质上是同一应用版本上的第一份稳定全量结果，而不是单独一份文件。

很多团队第一次碰到这个问题时，都会下意识去找一个“只扫改动代码”的开关，觉得把参数一加，Fortify就能像普通增量构建那样轻下来。可真跑到流水线里，常见情况反而是时间没怎么降，结果还不敢完全信。这里最容易绕进去的一点是，当前SCA版本里，官方意义上的Incremental Analysis已经不是一个还能正常开启的主线能力了，所以这件事不能只盯着命令参数看，还得先把产品边界和工程做法分开。

在进行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里说“规则包更新”，本质上更新的是OpenText Application Security Content，也就是Secure Coding Rulepacks和相关元数据。官方文档已经把更新路径分成了两条，一条是直接连规则包更新服务器在线更新，另一条是先把内容下载到本地，再用命令行工具导入。真正遇到更新失败时，问题通常也集中在这两条线上，比如更新源地址改错了、代理没配好、网络读超时、环境本身不能直连外网，或者本来就应该改走离线导入。

Fortify做增量扫描时，最容易误判的地方，不是结果里“少了几个问题”，而是没先分清到底是增量基线没立住，还是翻译阶段本身就没有把文件真正收进本次扫描。Fortify官方手册对这条链写得很清楚，增量分析要先做一次带`-incremental-base`的完整扫描，后续再用同一个build ID做`-incremental`；同时，翻译阶段到底收进了哪些文件，可以直接用`-show-files`和`-show-build-warnings`去核对。也就是说，漏扫问题先查翻译范围，再查增量口径，通常会比直接怀疑规则包更快。

在开始使用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里常说的规则包，本质上就是Application Security Content，也就是SCA真正用来识别漏洞类别、语言规则和API风险映射的内容。官方文档明确写到，Fortify Secure Coding Rulepacks对所有受支持的OpenText SAST版本保持向后兼容，这意味着多数场景下，规则包更新并不会直接把一套原本可用的SCA环境“更新坏”。真正容易出问题的，往往是SCA本地内容、SSC平台规则包和团队当前审计口径没有落在同一时间窗口里。

项目一旦变大，Fortify从十几分钟拖到一两个小时并不少见。真正常见的问题，往往不是单纯“机器太差”，而是翻译阶段、分析阶段、结果打包阶段混在一起排，最后把时间都耗在错误的地方。OpenText官方文档也明确把耗时分成Translation、Analysis、Audit Upload几段来看，因此处理Fortify扫描慢，关键不是盲目加机器，而是先拆阶段，再调参数，再看日志。

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

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

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

做Fortify代码审计时，最容易混掉的是两件事，一件是“这条结果是不是误报，该怎么标”，另一件是“审计注释到底要写到什么程度，后面的人才看得懂”。OpenText官方文档把这条线分得很清楚，审计时可以给问题设置Analysis等审计标签，也可以写COMMENTS；如果确定某条问题以后都不再关心，还可以继续做Suppress，但Suppress属于更强的、偏长期的处理动作。换句话说，误报标注和结果抑制不是同一个动作，注释也不该只写一句“误报”。

Fortify里最容易让团队卡住的，不是问题太多，而是把真正要修的缺陷、暂时接受的风险和明显误报全堆在一起处理。更稳的顺序是先用问题详情和事件路径确认是不是误报，再用审计状态和抑制动作把结果收口，最后把原因记录写成后续还能复核的证据链。Fortify官方文档把问题分析入口放在Source pane和Triage pane里，同时支持查看已抑制问题和维护审计属性，这正好对应这三步。