Fortify扫描失败，先不要急着反复重跑。更常见的原因不是平台本身坏了，而是扫描范围没有命中源码、翻译阶段没成功、输入文件类型不受支持，或者任务其实已经被调起但在执行中失败。Fortify官方文档把排查入口分成三层，也就是分析参数、日志文件和退出码，所以更稳的做法是先查范围，再看日志，最后再对照错误码。

　　一、fortify扫描失败怎么办

　　这一步先解决“为什么任务没正常产出结果”。排查时不要一上来就盯报错堆栈，先把扫描前提和输入条件核对清楚，通常能更快把问题压到具体环节。

　　1、先确认sourceanalyzer能被系统找到

　　如果流水线或本机提示找不到sourceanalyzer，官方建议先检查Fortify SCA安装路径是否已经加入系统执行路径，必要时重启代理或终端会话让环境变量生效。

　　2、再查输入文件和构建命令是否有效

　　Fortify退出码说明里明确写到，退出码2通常表示输入文件无效，例如翻译了不受支持的文件扩展名。若是构建型项目，还应先确认原生构建本身可以独立成功，再把Fortify接进来。

　　3、把分析范围先缩到最小可复现集

　　如果是多模块大工程，先用一小部分源码做最小扫描，确认翻译和扫描链路能通，再逐步放大范围。这样比整仓重试更容易判断问题是出在文件类型、构建参数，还是某个模块本身。

　　4、必要时先开调试日志再重跑

　　Fortify官方属性说明给了标准做法，也就是在命令行加-debug、-debug-verbose、-verbose，并配合-logfile指定日志输出文件。这样重跑后，后面的定位会比只看控制台输出清楚很多。

　　二、fortify扫描日志与错误码怎么定位

　　这一步先把日志和错误码分工看清。日志负责告诉你任务具体卡在哪一段，错误码负责快速判断失败大类，两者一起看才高效。

　　1、先找标准日志和支持日志

　　Fortify官方说明，默认会生成sca.log这一类标准日志，以及sca_FortifySupport.log这一类支持日志。标准日志适合先看信息、告警和错误，支持日志在开了调试后会更详细。

　　2、日志位置优先看当前项目根目录

　　官方日志属性写明，默认日志位置在当前ProjectRoot下的log目录里，所以先到当前扫描工程目录下找log，再找sca.log和sca_FortifySupport.log，通常比在系统盘全局乱搜更快。

　　3、先用退出码做第一层分类

　　官方退出码表里，0表示成功，1表示通用失败，2表示输入文件无效。也就是说，若控制台已经给出退出码，就先按退出码做第一层判断，再回到日志里找具体文件、具体命令或具体解析错误。

　　4、解析类问题优先看-debug-verbose输出

　　官方说明里，-debug-verbose比-debug更细，尤其适合看解析错误。若你怀疑是某些源文件、模板文件或Dockerfile这类内容触发失败，优先用这一档日志重跑。

　　5、日志看不出结论时再整理支持包

　　官方帮助页明确建议，若告警或错误无法自行解决，可把Fortify Support日志提交给支持团队。因此内部排查时也应先把标准日志、支持日志、命令行和退出码一起留档，后续沟通会更快。

　　三、Fortify排查顺序先看什么

　　真正想把排障速度提上来，关键不是把所有日志全翻一遍，而是把顺序固定下来。顺序一旦对了，大多数问题在前两步就能拦住，不会拖到最后才发现是最基础的输入或路径错误。

　　1、先看命令能不能正常启动

　　先确认sourceanalyzer命令可执行、安装路径正确、环境变量有效。这一步不过，后面的日志再多也没有意义。

　　2、再看输入和构建是不是有效

　　文件类型不支持、构建命令本身失败、翻译阶段没有真正产出，都会直接导致后面扫描失败或结果为空。

　　3、最后再看日志细节和错误码

　　当前两层都确认无误后，再用sca.log、sca_FortifySupport.log和退出码去压缩问题范围，这样最省时间，也最容易把问题落到具体原因上。

　　总结

　　Fortify扫描失败，先查命令和输入条件，再查翻译与扫描链路，最后才看详细日志。日志定位时，标准日志先看大类，支持日志负责深挖细节，退出码则负责快速分类。把“可执行路径、输入有效性、调试日志、退出码”这四层固定成排查顺序，后面不管是本地扫描还是流水线失败，通常都能更快压到具体原因。