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

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

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

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

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

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

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

规则包一更新，结果数量突然往上跳，这事在Fortify里并不稀奇。问题在于，很多团队一看到数量变多，就默认是误报失控，马上想整包回退。其实更稳的做法是先把版本、扫描条件和结果范围对齐，再判断到底是新规则真的带来了噪声，还是检测口径本身变了。官方资料也提到，安全内容更新后，本来就可能出现新增发现、旧类别调整和检测逻辑变化；另外，规则包既可以从服务器更新，也可以从本地ZIP导入，所以回滚本身是有明确操作路径的。