Fortify进行静态代码安全分析时，并不是简单搜索危险函数，而是结合规则、控制流和数据流判断外部输入能否沿代码路径到达敏感操作。因此，同一条安全问题是否成立，往往还要结合项目框架、输入约束和实际调用关系确认。处理“Fortify怎么进行代码安全扫描，Fortify扫描结果误报过多如何优化”时，一方面要保证扫描范围和规则版本正确，另一方面也要把真正的误报与低价值告警区分开，否则很容易通过大量过滤把实际风险一并隐藏。
一、Fortify怎么进行代码安全扫描
Fortify SAST的本地分析可以理解为两个主要阶段：先把项目代码转换为Fortify能够分析的中间表示，再对这些内容执行安全分析并生成FPR结果文件。扫描结果既可以上传到Application Security统一管理，也可以直接使用Fortify Audit Workbench打开审计。
1、扫描前把项目环境准备完整
Fortify能否正确理解代码，与实际构建环境关系很大。尤其是Java、C/C++以及包含大量框架代码的项目，缺失依赖或编译参数后，扫描虽然可能完成，但数据流完整度会受到影响。
①确认待扫描的是当前发布版本对应的【源代码】，不要把旧分支和当前分支混在同一个扫描工程中。
②检查项目所需的JDK、编译器、依赖库和构建参数，尽量让Fortify看到与正常构建一致的工程环境。
③使用固定的【Build ID】管理同一项目的翻译和扫描过程。重复使用旧Build ID重新分析前，应清理此前生成的中间数据。
④生成代码、测试代码以及确实不属于交付范围的目录，可以结合项目实际决定是否纳入，但不要为了减少告警直接排除核心业务模块。
2、完成代码转换和安全分析
命令行扫描时，典型过程是先执行项目翻译，再针对相同Build ID执行分析。例如分析阶段可以生成一个FPR：
sourceanalyzer-b MyProject-scan-f MyProject.fpr
【-b】对应前面使用的Build ID，【-scan】启动安全分析，【-f】指定结果文件。Fortify当前支持把结果保存为FPR，FPR中会包含漏洞信息以及用于后续审计的相关数据。
对于规模较小、结构简单的项目，也可以直接从【Audit Workbench】启动扫描。例如Java项目可以通过扫描向导选择源代码目录和Java版本，然后完成分析。
3、在Audit Workbench中分析扫描结果
FPR生成后，可以使用【Audit Workbench】打开。
不要一上来就按总告警数量整改，更实用的方式是先按照【Category】查看漏洞类别，再结合【Analyzer】判断它来自Data Flow、Control Flow、Structural还是其他分析器。Fortify还支持按照Engine Priority、审计状态等属性重新组织问题。
对于SQL Injection、Path Manipulation、Command Injection这类数据流问题，应重点打开对应Trace，查看【Source】到【Sink】之间经过了哪些函数，尤其要看中间有没有真正有效的校验或净化逻辑。
二、Fortify扫描结果误报过多如何优化
Fortify结果多并不等于误报多。有些问题是真实风险但优先级较低，有些是工具没有识别项目自己的安全封装，还有一些才属于可以明确关闭的误报。把这几种情况混在一起，是扫描结果越来越难维护的主要原因。
1、先更新Security Content再判断规则是否准确
Fortify的漏洞识别依赖Secure Coding Rulepacks和相关安全内容。如果长期使用旧规则，新的框架API可能无法被正确识别，已经改进的规则也无法生效。
①在Audit Workbench进入【Options】中的【Security Content Management】。
②检查当前安装的安全内容版本，并更新到与当前Fortify版本匹配的内容。
③更新后重新扫描一份基准版本，不要直接把新旧规则生成的告警数量横向比较。
OpenText明确建议定期更新Fortify Security Content；这些内容除了安全规则，还包含漏洞类别与CWE、OWASP等体系之间的映射。
2、检查“误报”是不是来自自定义安全封装
项目中经常会自己封装参数校验、编码、过滤和数据库访问接口。Fortify如果不知道某个内部函数具有净化作用，就可能继续沿着数据流传播污染状态。
比如业务已经通过统一方法限制文件路径，但规则库并不了解这个内部方法，最终仍然可能报告Path Manipulation。
这类情况不要逐条设置成【Not an Issue】，更值得处理的是规则层。
①从出现频率最高的同类问题中选取几个样本，检查Trace是否都经过同一个内部函数。
②确认这个函数在所有调用条件下确实能够消除对应风险，而不是只在部分情况下有效。
③对于企业自有框架或Fortify尚未覆盖的第三方组件，可以建立【Custom Rules】，让分析器理解这些Source、Sink、Validator或其他安全语义。
OpenText提供自定义规则能力，其中一个典型用途就是补充专有框架、第三方库和预编译组件中默认Rulepack尚未覆盖的行为。
3、合理选择扫描策略，不要靠大量隐藏告警降数量
当前OpenText SAST提供【security】【devops】【classic】三类扫描策略。25.4文档中，【security】为默认策略，会排除代码质量类、通常可信Source产生的数据流以及一些容易形成噪声的问题；【devops】会进一步减少低优先级结果；【classic】则保留更完整的问题范围。
开发流水线如果更关注快速反馈，可以评估【devops】；正式安全审计如果需要完整覆盖，则应根据组织要求选择更全面的策略。
这里需要注意：调整扫描策略是在改变“扫描结果范围”，并不代表被排除的问题已经经过人工确认。不能为了让报告好看，简单换成更激进的过滤策略。
4、已经确认的误报要形成审计结论
人工检查后能够证明某条问题确实不可利用，可以在审计结果中设置相应分析状态。
Fortify默认提供的Analysis状态包括【Not an Issue】【Reliability Issue】【Bad Practice】【Suspicious】【Exploitable】等。
标记【Not an Issue】时，建议同时记录判断依据，例如输入已经受到固定枚举限制、数据不会经过外部可控路径，或者框架已经完成不可绕过的净化。这样下一次合并扫描结果时，安全人员能够知道为什么关闭，而不是重新审计同一问题。
三、Fortify误报优化后怎么验证效果
误报治理完成后，不能只看告警总数有没有下降。真正值得关注的是：相同代码在后续扫描中是否还能得到一致结论，以及高风险问题有没有因为规则调整被一起过滤掉。
1、用固定样本重新扫描
①从之前已经确认的误报中挑选几类典型问题，例如统一输入校验、内部编码函数或自定义数据库封装。
②重新执行扫描，确认这些问题是否按照预期减少，同时检查同类真实漏洞还能不能正常出现。
③如果使用了【自定义规则】或调整了【扫描策略】，不要一次修改太多内容，最好逐项验证效果，方便判断是哪一项配置改变了结果。
④发现某类告警突然大面积消失时，应重新检查过滤条件，防止规则范围设置过宽。
误报优化的目标是提高结果可信度，而不是单纯把数字压低。
2、关注新增问题，而不是反复处理历史结果
当项目已经形成比较稳定的扫描结果后，后续版本更适合把注意力放在新增和重新出现的问题上。
①保留上一版本的FPR及审计结果，作为下一次分析的对照基线。
②新版本扫描完成后，优先查看【New】问题，判断最近代码修改是否引入新的安全风险。
③对于【Reintroduced】问题，确认是不是旧漏洞重新进入代码，或者此前整改内容被新的修改覆盖。
④已经经过充分审计的历史问题，不需要每个版本从头判断，但代码路径或安全控制发生变化后应重新评估。
这种方式比每次都从几千条扫描结果重新开始，更容易把安全人员的精力留给真正发生变化的部分。
3、定期检查规则和审计结论是否仍然有效
项目框架、公共组件和安全封装都会变化，因此以前成立的误报判断并不一定永久有效。
①内部校验函数被修改后，重新确认原来的【自定义规则】是否仍符合实际逻辑。
②升级Fortify或Security Content后，抽查以前高频出现的几类问题，看看规则行为有没有变化。
③对于长期标记为【Not an Issue】的问题，发现调用路径、输入来源或权限边界变化时，应重新打开审计。
④正式发布前，可以保留一次较完整的扫描作为阶段基线，避免日常快速扫描的过滤策略掩盖重要问题。
这样维护下来，Fortify的扫描结果才会越来越稳定，而不是随着项目迭代不断累积新的例外和过滤条件。
总结
Fortify误报过多，本质上会降低扫描结果的可用性：真正需要处理的安全问题容易被大量噪声淹没，开发人员也会逐渐对告警失去敏感度。优化时更重要的是让工具准确理解项目中的数据流、框架和安全控制，再把已经确认的误报转化为可追踪的审计结论。只有在降低无效告警的同时保持真实漏洞的发现能力，扫描结果才具有长期参考价值。如需进一步了解Fortify扫描误报判断、自定义规则优化及结果复核方法，欢迎联系咨询。
