Fortify

变量进入封装函数后，路径里只剩一条调用记录，未必表示分析已经停止。Fortify展示的是与问题有关的证据，不是完整的运行日志。关于“Fortify如何核查污点分析路径Fortify数据流路径中断时如何定位关键调用”，下面以Audit Workbench英文界面为例说明。

在代码安全扫描过程中，扫描规则决定了Fortify对代码风险的识别范围。不同项目的开发语言、业务场景以及安全要求存在差异，因此实际使用时通常需要对规则进行调整。使用Fortify时，有些用户会遇到修改规则后结果没有变化的情况，例如关闭某类规则后报告中仍然存在对应问题，新增规则后没有出现新的检测结果等。出现这类情况时，需要确认规则是否已经应用到扫描任务，而不是只查看规则配置页面。

Fortify进行静态代码安全分析时，并不是简单搜索危险函数，而是结合规则、控制流和数据流判断外部输入能否沿代码路径到达敏感操作。因此，同一条安全问题是否成立，往往还要结合项目框架、输入约束和实际调用关系确认。处理“Fortify怎么进行代码安全扫描，Fortify扫描结果误报过多如何优化”时，一方面要保证扫描范围和规则版本正确，另一方面也要把真正的误报与低价值告警区分开，否则很容易通过大量过滤把实际风险一并隐藏。

Fortify本地扫描完成后，通常会生成FPR文件，再上传到SSC集中审计。上传成功只说明文件已经送到服务器，结果是否进入正确版本，还要看目标版本、处理状态和审批规则。弄清Fortify结果怎么上传SSC Fortify上传SSC后项目版本没有更新怎么办，先要分清“更新扫描结果”和“新建项目版本”是两件事。

Fortify扫描时内存不足应当怎样处理，以及大型项目的扫描参数又该怎样调整，这是大型项目在接入SAST时很容易碰到的问题。Fortify SCA在扫描的时候，需要经过代码转换和安全分析这两个阶段，项目的代码量越大、依赖越多、语言越复杂，内存方面的压力就会越明显。OpenText的文档也说明了，扫描所需要的物理内存，会受到代码复杂度的影响，在默认情况下，它会根据系统可用的物理内存自动去分配，但遇到OutOfMemory的时候，可以通过-Xmx去调整Java的堆内存，也可以使用SCA_VM_OPTS来统一设置内存的选项。

项目把数据库访问、输入校验封装成内部接口后，扫描器未必能直接理解这些函数的安全含义。Fortify自定义规则可以补充这部分信息。不过，规则文件保存成功、扫描正常结束，并不能证明目标代码已经按预期接受检查。维护时既要管理规则本身，也要确认扫描实际加载了哪个文件。以下以Fortify Static Code Analyzer配合Audit Workbench的操作为主，界面使用英文名称。

在软件安全测试过程中，扫描结果通常需要整理成报告，方便项目成员查看代码风险情况。Fortify完成安全分析后，可以将检测到的问题、风险等级以及相关信息输出为报告文件，用于项目记录和后续查看。实际使用时，报告生成并不一定每次都顺利，例如扫描完成后没有数据、导出文件失败、报告内容显示不完整等情况。这些问题通常和扫描结果状态、报告设置以及当前项目环境有关，需要结合具体情况进行检查。

Fortify完成静态扫描后，扫描结果仍需要经过人工审计，才能区分真实漏洞、可疑问题、代码质量问题和误报。处理“Fortify怎么设置审计漏洞结果，Fortify漏洞审计状态无法保存如何解决”时，需要区分两种场景：在Audit Workbench中审计时，结果主要保存在FPR文件；在SSC/Application Security中审计时，结果还受到账号权限、Custom Tag配置和审计冲突策略影响。官方默认【Analysis】标签就是漏洞审计状态的主要依据。

Fortify扫描结果里，有些问题经过人工确认后可以暂时不处理。直接删除扫描记录不合适，把问题留在主列表里又会影响统计，这时可以使用漏洞抑制。处理“Fortify漏洞抑制怎么设置Fortify抑制标记复扫后为什么消失”，要留意扫描结果有没有正确合并。抑制记录跟着问题身份走，复扫时被识别成了新问题，原来的标记自然带不过去。

Fortify过滤器怎么设置，以及Fortify过滤器把有效漏洞隐藏了又该怎么处理，这里的关键是先要分清楚“为了方便查看而做的过滤”和“在扫描阶段就直接把结果排除掉”这两件事情。在Fortify里面，是可以通过filter set、filter file、问题视图条件这些方式，去减少结果当中的噪音的，但如果规则设得太宽，就有可能把真实的漏洞也一起藏起来。官方的文档里面也提到过，使用filter set所隐藏的问题，当它在扫描阶段被应用的时候，是有可能不会被写入到FPR结果文件里面去的，对这一类的配置，需要特别谨慎。

新增了一个接口文件，流水线扫描正常结束，报告里却没有它的相关信息。遇到这种情况，应先确认文件是否进入翻译阶段，再检查扫描和结果展示。Fortify静态分析扫描的是翻译后形成的中间数据，源码目录里有文件，并不代表本次任务已经分析了它。另外，旧版增量分析与新版结果对比不同，配置前需要先确认产品和版本。

在软件开发过程中，代码安全分析可以帮助开发人员提前发现潜在风险。Fortify通过静态分析方式检查源代码中的安全问题，并根据规则库生成漏洞结果。实际使用时，扫描结果并不一定完全符合开发人员预期，例如报告中出现误报、部分漏洞没有发现、漏洞等级判断存在差异等情况。这些问题通常和代码上下文、扫描配置、规则版本以及项目环境有关，需要结合分析结果进一步确认。

Fortify完成静态分析后，通常会生成FPR文件，用于在Audit Workbench中审计结果，或上传到Fortify Software Security Center统一管理。处理“Fortify怎么导入分析结果，Fortify导入FPR文件失败如何处理”时，需要先区分是本地打开FPR失败，还是上传到Software Security Center后处理失败。两种场景虽然都表现为文件无法正常使用，但排查方向并不一样。

Fortify内置规则覆盖面很广，但企业自研框架、封装接口和内部安全规范，未必都能被准确识别。这时可以补充自定义规则。处理“Fortify自定义规则怎么创建Fortify自定义规则不生效怎么排查”，建议先准备一段最小测试代码，确认规则能命中，再放进正式项目。

Fortify漏洞路径怎么分析，以及污点传播路径太长的时候又该怎样筛选重点，是很多团队在复核SAST结果时都会碰到的情况。Fortify扫出一条SQL注入、命令注入、路径遍历或者跨站脚本问题，如果只在列表里看漏洞名称，那是不够的。真正要判断它是不是有效风险，还是要看数据是从哪里来的，中间经过哪些变量和函数，最后流向了哪个危险的调用。Fortify的数据流类问题会在Analysis Trace里面展示污染数据从source到sink的路径，审计的时候这条路径就是主要的判断依据之一。

FPR导入Fortify后，漏洞数量、审计标签或代码位置与原记录不同，需要先确认打开的是哪份结果。Audit Workbench可以直接查看本地FPR，Software Security Center则会将上传文件与应用版本已有结果合并。原始扫描文件、补充过审计意见的文件和服务器最新结果，可能包含不同信息，比较前应先对齐扫描批次。

在软件安全检测过程中，Fortify扫描项目的配置是正式分析前的重要准备环节。很多项目第一次接入安全扫描时，问题并不出现在扫描功能本身，而是代码目录、编译环境或者项目参数没有对应设置好。比如扫描任务启动后没有发现代码、分析过程提前结束、生成结果和实际代码情况不一致等，都可能和前期配置有关。因此，在使用Fortify建立扫描项目时，需要根据项目实际情况逐项确认配置内容。

Fortify SAST的漏洞识别能力主要来自Rulepack，项目还可以额外加载自定义规则，用于补充企业内部安全规范、第三方框架或特殊函数的数据流模型。处理“Fortify怎么配置扫描规则，Fortify扫描规则不生效如何排查”时，需要区分默认Rulepack、自定义规则和结果过滤三个层面。规则文件虽然存在，但没有真正被当前扫描任务加载，或者分析器、扫描参数发生变化，都可能出现预期漏洞不再报告的情况。

FPR文件里不只有漏洞结果，还可能包含源码片段、审计状态、注释和扫描信息。处理Fortify FPR文件怎么合并Fortify FPR合并后结果重复怎么办，先要明确目的：是把旧审计结果带到新扫描，还是把多个独立项目拼到一起。两种需求看着相近，处理方法却不一样。

Fortify的规则包应当怎样更新，以及规则包更新以后扫描出现的差异又该怎样去判断，这里的关键并不只是把规则更新到最新版本，而是需要弄清楚这次更新会不会改变扫描的结果。Fortify的规则包里面包含了安全规则和与之相关的元数据，SCA可以通过fortifyupdate这个命令去获取或者导入安全内容；在SSC里面，也可以从规则包的页面去执行服务器的更新。规则包发生变化以后，新增的漏洞、消失的漏洞，还有严重等级的变化，都有可能出现，因此在更新前后需要把基准结果保留下来，不能只盯着最终的漏洞数量去看。