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

　　一、Fortify怎样维护自定义安全规则

　　先选定具体函数和预期行为，再创建规则，比较容易验证。已有规则可使用Custom Rules Editor维护；针对函数建立规则，也可以从Audit Workbench的向导开始。

　　1、从已分析的函数生成规则

　　①在Audit Workbench打开包含目标代码的FPR结果文件，进入【Options】→【Show View】→【Functions】。

　　②找到目标函数，右键选择【Generate Rule for Function】，打开【Custom Rule Wizard】。

　　③选择符合实际行为的规则模板，按向导填写语言、匹配条件和相关参数，将规则保存到自定义Rulepack。

　　规则应说明这个函数承担什么作用。例如，返回外部输入、接收敏感数据和执行有效校验，分别属于不同的建模需求。把校验函数误设为清洗函数，可能导致原本需要报告的问题消失。

　　2、重新加载并扫描验证

　　①打开【Options】→【Options】，在左侧选择【Security Content Management】。

　　②点击【Import Custom Security Content】，选中自定义Rulepack，通过【Open】导入，再点击【OK】。

　　③点击【Scan】，使用更新后的规则重新分析。

　　④扫描结束后，在【Functions】中右键目标函数，选择【Show Matched Rules】，核对结果中的规则ID和Rulepack文件名。

　　打开旧FPR查看结果，不会自动用新规则重新分析。若源代码或翻译配置也改过，应先更新翻译结果，再进行扫描。

　　3、给规则保留可追溯的修改记录

　　日常维护建议保存可编辑的规则源文件，并记录规则ID、用途、适用语言、内部接口版本及修改原因。一次调整尽量对应一个明确问题，方便回退和比较。

　　①使用Custom Rules Editor打开自有Rulepack，检查并修改相关规则，保留修改前版本。

　　②回到【Security Content Management】，导入修订后的文件，再执行【Scan】。

　　③通过【Show Matched Rules】核对本次扫描实际匹配的规则，避免只凭文件名判断版本。

　　不要直接改写厂商提供的加密规则包。自有规则单独保存，也方便在升级安全内容后重新验证。

　　二、Fortify自定义规则未命中目标代码如何排查

　　先确认“未命中”指什么：是函数没有匹配规则，还是规则已经匹配，却没有形成漏洞结果。两种情况的检查方向不同。

　　1、确认规则交给了实际扫描进程

　　①在【Options】→【Options】→【Security Content Management】检查本机导入的自定义安全内容。

　　②若扫描由流水线或远程节点执行，核对该任务使用的规则路径、文件内容和扫描参数。

　　③检查扫描日志，查找规则文件读取失败、格式解析错误及版本兼容提示。

　　命令行扫描可以通过-rules指定规则文件或目录，也可配置自定义规则目录。本机Audit Workbench导入成功，只能说明本地配置已更新，远程任务仍需核对自己的规则加载方式。

　　2、查看规则是否匹配到正确函数

　　①在【Functions】中找到目标函数，右键选择【Show Matched Rules】。

　　②查看【Search】中的规则ID及Rulepack名称，确认是否包含本次自定义规则。

　　③右键函数选择【Open Declaration】，核对声明中的包名、类名、函数名称及参数类型。

　　④对照规则匹配条件，检查重载方法、命名空间、大小写和正则表达式是否与实际函数一致。

　　同名函数不一定是同一个目标。接口升级后参数类型发生变化，旧规则也可能无法继续覆盖新调用。

　　3、规则已匹配，却没有漏洞结果

　　函数旁的绿色标记表示有规则覆盖，不能据此认定漏洞一定会产生。数据流源规则即使匹配成功，相关数据没有到达危险操作，也可能没有对应问题。

　　①通过【Show Matched Rules】确认匹配的是预期规则。

　　②核对规则描述的数据位置：需要跟踪的是返回值、某个参数，还是对象状态。

　　③检查调用关系中的数据传递、包装函数和已有清洗逻辑，确认测试样例具备规则要求的触发条件。

　　④若结果中已有相关问题，在【Analysis Trace】查看路径，判断中间的数据处理是否符合预期。

　　例如，自定义输入函数已经被识别，但后续使用的是另一份固定值，就不能仅凭“调用过该函数”要求产生告警。

　　4、目标代码没有进入本次分析

　　①在【Functions】中查找目标函数，并使用【Open Declaration】确认对应代码版本。

　　②检查翻译日志和构建配置，核对目标文件是否被排除、相关模块是否参与构建、依赖是否解析成功。

　　③更新翻译结果后重新执行【Scan】，再检查函数匹配情况。

　　同时检查扫描参数是否禁用了所需规则类型。排查时使用过的-no-default-rules等选项，也应确认没有误留在正式任务中。

　　三、Fortify自定义规则更新后怎样做回归检查

　　只验证一个能触发的问题样例，还不足以判断规则是否适合发布。最好同时准备应该命中和不应该命中的代码，观察规则边界。

　　1、对照风险样例和安全样例

　　①准备直接触发目标行为的风险样例，再准备经过有效处理的安全样例。

　　②完成翻译，在【Security Content Management】导入待验证规则，点击【Scan】。

　　③分别在【Functions】中执行【Show Matched Rules】，确认两个样例涉及的函数是否按预期覆盖。

　　④比较漏洞结果，记录命中位置和数量。若安全样例也产生问题，再检查匹配范围及数据流条件。

　　2、保留发布版本和验证结果

　　①验证通过后，将规则文件、样例、扫描配置和结果文件按版本一起留存。

　　②在正式任务中使用同一份规则，扫描后通过【Show Matched Rules】抽查目标函数。

　　③接口或扫描引擎升级后，重新运行保留的样例，确认覆盖范围没有意外改变。

　　总结

　　内部框架会逐步演变，昨天准确的规则，换一版接口后可能就需要重新调整。Fortify自定义规则的价值，在于把团队对内部代码的认识补充给扫描器，让安全检查更贴近项目实际。维护记录里如果留有适用接口、验证样例和调整原因，接手的人就能理解规则为什么这样写，也更容易判断何时该修改。希望这些操作能帮助大家查清规则未命中的原因，让后续维护有据可查。遇到其他Fortify规则配置或结果分析问题，也欢迎继续交流。