流水线里跑Fortify增量扫描，最常见的坑是时间没降，或结果看起来少了。排查时先确认链路是否支持增量，再核对基线与缓存是否被保留，通常就能把问题锁定到具体一步。

　　一、Fortify增量扫描不生效怎么办

　　增量不生效多数不是规则问题，而是参数没落到sourceanalyzer，或历史状态被清掉了。按下面顺序检查，能很快判断是版本不支持、基线缺失，还是缓存断链。

　　1、先判定当前版本与集成方式是否还支持增量

　　在构建机打开【命令提示符】或【PowerShell】，执行sourceanalyzer-v记录版本；社区反馈SCA在22版本后增量能力可能被移除或不可用。

　　如果你通过Azure DevOps扩展任务跑SCA，文档写明不支持增量扫描，需要改成命令行步骤或更换方案。

　　2、确认首次全量扫描是否建立过增量基线

　　老版本SCA要求第一次scan带-incremental-base，后续scan才用-incremental；缺了基线，常见表现就是参数被忽略或退回全量。

　　翻第一次成功那次日志，确认Args里出现-incremental-base，并对应同一个build ID。

　　3、核对build ID与中间文件是否连续

　　翻译与扫描要靠同一个build ID合并多次翻译结果；如果build ID每次变化，或中间执行clean清理，中间文件断掉后增量就会回落。

　　在CI里尽量固定build ID到仓库与分支维度，并保留Fortify的工作目录与构建缓存目录。

　　4、用日志确认参数确实传进了扫描进程

　　在扫描阶段加-logfile输出，打开support log搜索incremental，确认-incremental-base或-incremental真实出现在Args里；常见排错日志名包括sca_FortifySupport.log与scaX_FortifySupport.log。

　　二、Fortify增量扫描需要满足哪些条件

　　增量能跑通依赖基线、同一build ID、连续缓存三件事，缺任何一项都会回落成全量或出现漏扫。你只要按下面四条逐条对照，就能判断当前流水线到底适不适合继续用增量。

　　1、必须先做一次-incremental-base的基线扫描

　　把基线当成一次必须完成的全量分析，基线建立后再考虑后续增量，不要跳步。

　　2、后续扫描必须持续复用同一个build ID

　　每一步都用同一build ID，确保翻译与扫描始终指向同一套构建会话与同一套缓存。

　　3、每次变更后仍要把工程完整翻译进该build ID

　　增量复用的是分析阶段状态，不代表只翻译改动文件；翻译没纳入变更时，会出现扫描很快但新代码没进结果的假象。

　　4、翻译与扫描分离时两端版本口径要一致

　　两端SCA版本的major和minor尽量保持一致，避免构建会话不兼容导致复用失败。

　　三、Fortify扫描提速与结果一致性怎么做

　　当增量不稳定或不可用，与其硬上，不如把提速做成固定节奏：日常跑快，周期跑全，差异可解释。把节奏定住后，你会发现团队更容易对结果变化达成共识，也更好做治理闭环。

　　1、用-scan-precision把扫描深度分档运行

　　精度从1到4分档，日常分支用2或3压时长，里程碑或夜间跑4保证覆盖。

　　2、用-quick做快速拦截但要注意SSC处理规则

　　快速扫描会应用Quick View过滤集，若你上传到SSC，记得检查SSC侧是否会忽略快扫结果，避免误判为未扫描。

　　3、用-filter把扫描范围收敛到关键代码

　　把第三方目录、生成目录与不关心的文件类型写进filter文件，在scan阶段用-filter加载，先把噪声压下去再谈增量。

　　4、按模块拆分build ID降低单次扫描峰值

　　按模块分别翻译与扫描能降低单次资源峰值，但跨模块数据流分析可能变弱，拆分边界要与关注点一致。

　　总结

　　Fortify增量扫描不生效，先看版本与集成方式是否支持，再对照-incremental-base基线、同一build ID、连续缓存与日志参数四条硬条件。若增量难以持久化，就用-scan-precision与-quick配合filter和模块拆分，把速度与一致性稳住。