在软件开发过程中，代码安全分析可以帮助开发人员提前发现潜在风险。Fortify通过静态分析方式检查源代码中的安全问题，并根据规则库生成漏洞结果。实际使用时，扫描结果并不一定完全符合开发人员预期，例如报告中出现误报、部分漏洞没有发现、漏洞等级判断存在差异等情况。这些问题通常和代码上下文、扫描配置、规则版本以及项目环境有关，需要结合分析结果进一步确认。

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这种太笼统的名字，不然的话，来自不同分支、不同模块、不同流水线的数据，就很容易出现互相覆盖或者叠在一起的情况。

在企业把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扫描慢，关键不是盲目加机器，而是先拆阶段，再调参数，再看日志。