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

　　一、Fortify SCA生成FPR怎么做

　　Fortify SCA生成FPR怎么做，关键不是直接敲一条`-scan`命令，而是先把翻译阶段做完整。OpenText SAST 26.1用户指南明确说明，`sourceanalyzer`通过`-b`指定build ID，把后续多次调用关联到同一个分析上下文里；只有翻译阶段已经把源码和配置正确收进这个build ID，后面的扫描阶段才能真正生成可用的FPR。

　　1、先定一个固定的build ID

　　官方文档写得很直接，`-b`是用来把多次`sourceanalyzer`调用绑到一起的。后续不管你是直接喂源码目录，还是包一层Maven、Gradle、MSBuild、Bazel之类的构建命令，核心前提都是这个build ID要保持一致。若build ID前后不一致，最后扫描时就找不到正确的翻译结果。

　　2、先跑翻译阶段

　　翻译阶段的目标，是让SCA理解你的项目文件、语言和构建关系。官方说明里，翻译完成后可以用`sourceanalyzer-b-show-build-warnings`查看翻译阶段的warning和error，也可以用`sourceanalyzer-b-show-files`确认当前build ID下到底收进去了哪些文件。也就是说，FPR生成前，最好先确认翻译阶段没有明显断层。

　　3、再跑扫描阶段生成FPR

　　官方给出的标准语法非常明确：`sourceanalyzer-b MyProject-scan-f MyResults.fpr`。这一步就是把前面build ID里已经翻译好的内容真正做分析，并把结果写入FPR文件。若你有多个build ID要合并，官方也允许在扫描阶段把多个`-b`一起带上，然后输出到同一个FPR。

　　4、生成FPR时注意源码是否要一起打包

　　OpenText官方文档说明，默认情况下，SAST会把source code一起包含进FPR文件中；同时在26.1里也给出了`FPRDisableSourceBundling`相关属性，并特别提醒，如果你要把quick scan生成的FPR上传到Application Security，就必须把该属性设为`false`，也就是不能禁用源码打包。放到实际操作里，这意味着“FPR能生成”和“FPR能顺利上传并正常展示”还不是同一个层面。

　　5、复杂语言场景先按语言要求补翻译参数

　　官方文档还特别提醒，某些语言需要额外参数或不同翻译方式。例如PL/SQL要先指定`-sql-language PL/SQL`再扫描，动态语言也要求在翻译阶段把所有源文件按要求一次性纳入。也就是说，如果某类项目一直生成不出可用FPR，不要只怀疑`-scan`，也要先回到对应语言的翻译口径去查。

　　二、Fortify SCA结果上传SSC怎么操作

　　Fortify SCA结果上传SSC怎么操作，重点不是拿到FPR就直接传，而是先准备认证token，再确认上传目标到底是application version ID还是application name加version。SSC当前官方文档里已经统一称为Application Security，官方上传文档明确说明，命令行上传FPR必须先有authentication token，而且你可以按两种方式定位上传目标。

　　1、先生成上传用token

　　OpenText官方给出的标准做法是用`fortifyclient token-gettoken AnalysisUploadToken-url-user-password`去生成上传分析结果所需的token，必要时还可以加`-daysToLive`指定有效期。这里最关键的一点是token类型要选对，上传FPR用的是`AnalysisUploadToken`，不是随便拿一个登录token就能替代。

　　2、能拿application version ID时优先用ID上传

　　官方上传文档给出的第一种方式，是通过application version ID直接上传：`fortifyclient uploadFPR-url-authtoken-file MyScan.fpr-applicationVersionID`。这种方式的好处是目标最明确，不容易因为应用名或版本名写法不一致而传错位置。

　　3、没有ID时再用应用名和版本名

　　如果当前流程里拿不到application version ID，官方也支持另一种方式：`fortifyclient uploadFPR-url-authtoken-file MyScan.fpr-application MyApp-applicationVersion 1.0`。这种方式对人工操作更直观，但前提是SSC里应用名和版本名必须和你命令里写的一致。

　　4、上传前先列出应用版本更稳

　　25.4文档还给出了`fortifyclient listApplicationVersions-url-authtoken`这条命令，用来列出当前token可访问的application version ID、application name和version。实际上传前先跑一次这条命令，会比凭记忆填写目标版本更稳，尤其是在一个SSC里应用和版本很多时。

　　5、上传失败时先排token权限和版本兼容

　　官方文档明确说明，上传token继承的是创建该token的用户权限；同时SSC用户指南也单独列出了FPR file compatibility章节。这意味着上传失败时，不要只盯命令格式，还要优先检查三件事：token是否是`AnalysisUploadToken`、创建token的用户是否对目标应用版本有上传权限、当前FPR是否在SSC可接收的兼容范围内。

　　三、Fortify SCA到SSC这条链路怎么收口

　　Fortify SCA到SSC这条链路怎么收口，真正要解决的不是“今天手工能跑通一次”，而是让后面命令行和流水线都按同一套口径稳定执行。OpenText官方文档其实已经把这条链路拆得很完整：翻译阶段由`sourceanalyzer-b`管build上下文，扫描阶段由`-scan-f`生成FPR，上传阶段由`fortifyclient`和`AnalysisUploadToken`接入SSC。更稳的团队做法，是把这三段固定成标准流程，而不是每次临时拼命令。

　　1、先固定build ID命名规则

　　build ID不是临时字符串，而是整条分析链的主线。更稳的方式通常是按项目名、分支名或流水线编号来生成固定规则的build ID，这样翻译、扫描和后续查问题时都能快速对上，不容易因为build ID写乱导致分析结果串项目。这个建议建立在官方对`-b`作用的明确说明之上。

　　2、把翻译检查放在扫描前

　　很多团队的问题不是FPR不会上传，而是FPR里本身就缺文件或翻译不完整。更好的做法，是在正式`-scan`之前先跑`-show-build-warnings`和`-show-files`做一次检查，让“翻译阶段有没有收全源码”这件事先被确认，而不是等FPR生成后再被动返工。

　　3、上传目标尽量统一到application version ID

　　虽然官方支持名称加版本名两种上传方式，但在自动化里更稳的做法通常是优先用application version ID。这样可以减少因为命名不一致、大小写差异或版本字符串变化造成的上传失败。这个结论是基于官方同时支持两种方式，而ID定位天然更精确这一点做出的。

　　4、把token生命周期和权限一起管住

　　官方说明里，token可以通过`-daysToLive`限定有效期，而且token权限继承创建者账号。因此更稳的流程不是长期共用一个高权限token，而是让专门的流水线账户生成受控时长、受控权限的`AnalysisUploadToken`，这样既能保证上传可用，也更容易做权限治理。

　　总结

　　Fortify SCA生成FPR怎么做，关键是先按build ID跑完整翻译，再用`sourceanalyzer-scan-f`输出FPR，而不是只跑一条扫描命令。Fortify SCA结果上传SSC怎么操作，关键则是先生成`AnalysisUploadToken`，再用`fortifyclient uploadFPR`按application version ID或应用名加版本名把FPR传到SSC。等这两步都走顺以后，再把Fortify SCA到SSC这条链路怎么收口固定成标准流程，后面的本地执行和流水线上传通常都会顺很多。