很多团队第一次碰到这个问题时，都会下意识去找一个“只扫改动代码”的开关，觉得把参数一加，Fortify就能像普通增量构建那样轻下来。可真跑到流水线里，常见情况反而是时间没怎么降，结果还不敢完全信。这里最容易绕进去的一点是，当前SCA版本里，官方意义上的Incremental Analysis已经不是一个还能正常开启的主线能力了，所以这件事不能只盯着命令参数看，还得先把产品边界和工程做法分开。
一、fortify增量扫描怎么开
这一段先把结论说透。你要是问“Fortify现在哪个参数能把官方增量扫描打开”，答案其实很直接，当前版本里没有这样一个还能正常使用的官方开关。你要是问“怎么把每次扫描时间压下来”，那就得换成复用翻译成果、缩小扫描范围和调整扫描精度这套思路。
1、先别把时间花在找隐藏参数上
20.1.0的用户指南变更记录已经写到，Incremental Analysis会在下一版本移除；到了20.2之后，OpenText社区员工也直接确认，SCA no longer supports incremental scan。换句话说，当前版本里你再去找所谓的增量分析开关，大概率是在和一个已经退出的能力较劲。
2、很多人误把“只编译了改动文件”当成“已经开了增量”
Fortify在build integration里只处理这次构建真正执行到的编译命令。官方文档写得很清楚，如果构建前不做clean，Fortify只会处理被重新编译的文件。这个现象看起来很像增量，但它本质上只是翻译阶段拦截到的编译范围变小，不等于分析引擎仍然保留了官方Incremental Analysis模式。这个区分一定要先想明白，不然后面排查时很容易跑偏。
3、现在更实用的做法，是把“开功能”换成“改流程”
一条更稳的落地顺序是这样的。第一次做基线扫描时，先执行【sourceanalyzer-b MyBuild-clean】，再让Fortify包裹你的真实构建命令，比如【mvn package】或者【gradle build】，最后执行【sourceanalyzer-b MyBuild-scan-f result.fpr】。后续开发阶段不要再把这套理解成“开了增量”，而是把它当成缩短反馈时间的工程手段，再结合【-scan-precision】或【-quick】去压时间。官方也说明，translation phase可以由多次sourceanalyzer调用组成，并由同一个build ID串起来。
4、跨机器跑时，优先把会话传递先搭好
如果你的构建机和扫描机不是同一台，或者runner经常销毁重建，那就别单纯赌本地缓存。Fortify支持导出和导入MBS，也就是移动构建会话。实际操作可以在翻译机执行【sourceanalyzer-b MyBuild-export-build-session app.mbs】，把文件传到扫描机后再执行【sourceanalyzer-import-build-session app.mbs】，然后继续用同一个build ID执行scan。很多团队表面上是在问“怎么开增量”，实操里真正该先做好的，其实是这条会话传递链路。
二、fortify增量扫描前置条件有哪些
这部分往往比命令本身更重要。因为多数“增量没生效”的现场，最后都不是参数拼错了，而是构建没被Fortify正常拦截、build ID没接上，或者翻译机和扫描机的环境根本不一致。
1、构建链路必须先跑通
官方对build integration的要求很明确，构建工具要调用Fortify支持的编译器，编译器要能从系统PATH找到，而且最好是构建工具直接调用编译器，而不是再包一层Fortify看不见的子进程。只要这一条不成立，Fortify连“本次到底编译了哪些文件”都抓不稳，后面谈范围收缩就没有基础。
2、语言类型要先分清
同一个build ID支持多次translation调用，但官方同时给了一个很容易被忽略的例外，JavaScript、TypeScript、PHP、Python和Ruby这几类动态语言，不支持像静态编译型语言那样在后续调用里继续往build ID里追加新文件。这意味着你要做会话复用时，先得看项目语言是不是落在这个限制里。要是语言不满足条件，流程怎么调都不会顺。
3、build ID、工作目录和clean策略要一起定
官方标准流程仍然是【clean】、【translate】、【scan】三步，而且文档明确写了，clean会删除这个build ID的临时文件。也就是说，如果你每次都换一个新的build ID，或者一上来就把旧会话clean掉，那前一轮留下来的翻译上下文自然接不上。所以前置条件不只是“有build ID”，而是你得先决定哪些流水线保留同一个build ID，哪些流水线必须完整clean，不能一会儿复用、一会儿全删，最后让结果状态失控。
4、跨机器时版本和内容都要对齐
走MBS这条路时，官方要求翻译机和扫描机安装相同版本的Fortify Security Content，也就是规则包；如果涉及正则分析，还建议两边使用相同版本的源码，并保持相同路径，否则结果质量会变得不可预期。这个条件看起来细，但很多“本地能复用、上CI就不对”的问题，最后都是卡在这里。
三、Fortify没法真增量时怎么做
说到底，团队真正想解决的不是“非得把增量两个字打开”，而是“别让每次提交都等太久”。既然当前版本不再保留官方Incremental Analysis，那就直接用替代手段把反馈周期压下来，反而更稳，也更容易长期维护。
1、开发阶段先用【-scan-precision】
Fortify支持【-scan-precision】也就是speed dial，精度级别有1到4，数值越低速度越快，4等同full scan，而且它不能和【-quick】一起用。官方说明里还提到，级别3在Java、C和C++这类类型明确的语言上能明显改善中间开发阶段的扫描时间。对日常提交和合并前校验来说，这个比执着去找“增量开关”更实在。
2、需要更短反馈时再用【-quick】
【-quick】的定位是尽快发现高优先级问题，它会降低分析深度，并使用quick scan配置。操作上就是在scan命令里加上【-quick】。但这一步不能拿来替代基线扫描，因为官方同时强调，quick scan不能代替full scan，至少每个迭代要定期做一次完整扫描。它更像开发期的快筛，不是最终归档结果的唯一来源。
3、大项目要学会拆，不要每次抱着整仓库硬扫
官方用户指南和性能指南都提到，大项目拆成相对独立的模块分别翻译、分别扫描会更高效；对C和C++项目，还可以考虑用【-bin】按二进制关联范围收缩扫描集。这个办法不叫增量，但在多模块仓库里常常比一味追求“只扫diff”更容易真正落地。要注意的只是，模块拆开后，少量跨模块的数据流问题可能会看不到。
4、把扫描节奏分层，别让一套规则压到所有阶段
更稳的做法通常是，开发分支走precision 1或2，合并前走precision 3，主干夜间或周末跑full scan，版本发布前再做一次完整基线。这不是某个固定模板，而是基于Fortify已有的quick scan、full scan和precision分层能力做的工程化安排。这样既能让开发尽快看到结果，也不会把遗漏问题一直带到后面。
总结
fortify增量扫描怎么开，fortify增量扫描前置条件有哪些，这个问题真正的答案，并不是去找一个已经不存在的开关。当前版本下，更靠谱的理解应该是，官方的Incremental Analysis已经退出主线能力，想把扫描时间降下来，重点要放在构建拦截是否成功、build ID和会话是否稳定、跨机器版本是否一致，以及【-scan-precision】、【-quick】、MBS和模块拆分这些替代方案上。把这几个点理顺后，你的Fortify流水线就算没有“真增量”，反馈速度也能明显好很多。
