在Fortify里做规则定制，真正要先分清的是你要改哪一层。第一层是规则内容本身，也就是用Fortify Custom Rules Editor去写或改自定义规则；第二层是规则装载方式，也就是让本地SAST扫描器、Audit Workbench或SSC真正吃到这份自定义Rulepack。官方文档明确说明，Fortify支持编写自定义规则来补充内置安全内容，适合落地企业自有安全规范、第三方库识别和预编译组件分析；同时，Custom Rules Editor就是官方提供的自定义规则编辑工具，而Custom Rules Guide随产品下载包提供。

　　一、fortify规则怎么定制

　　做规则定制时，先不要急着直接改生产扫描链路，更稳的做法是先把规则开发、规则打包和规则装载三件事拆开。Fortify官方把这条路写得很清楚，先有Custom Rules Editor和Custom Rules Guide，再通过规则目录、命令行参数或Rulepack导入让扫描器真正使用这些规则。

　　1、先确认你走的是自定义规则还是仅改扫描策略

　　如果你只是想少扫一些问题、换一套检查范围，优先改Scan Policy就够了；只有当你要新增企业内部规范、识别自定义框架方法或补充第三方库语义时，才需要进入Custom Rules Editor写规则。官方说明里把“自定义规则用于扩展Fortify Secure Coding Rulepacks能力”说得非常直接。

　　2、先用Fortify Custom Rules Editor做规则开发

　　官方SAST文档把Fortify Custom Rules Editor定义为“创建和编辑自定义规则的应用”。实操上，先在这一步完成规则模板选择、匹配条件、元数据和打包，不要一开始就在扫描命令里硬试。

　　3、需要规则语法和示例时直接看Custom Rules Guide

　　官方文档明确列出OpenText Static Application Security Testing Custom Rules Guide这个包，并说明它专门用于创建自定义规则，还包含把规则编写概念应用到真实安全问题的示例。也就是说，规则语法、条件表达、示例写法，应该以这个指南为准，而不是只凭旧项目经验拼。

　　4、规则落地前先确定装载方式

　　Fortify官方给了至少三条常用装载路径。第一条是通过fortifyupdate-import导入本地下载的Rulepack；第二条是在SSC里以管理员或安全负责人身份导入安全内容，让SAST和AWB可用；第三条是用-rules参数指定自定义Rulepack或规则目录。先把装载方式定好，后面验证才不会乱。

　　二、fortify规则自定义后如何验证生效

　　规则写完以后，真正关键的不是“包生成了没有”，而是扫描链路里有没有真的加载这份规则，以及它有没有在预期样本上触发、在非预期样本上不触发。官方文档虽然把规则编写和规则导入分散在不同手册里，但验证逻辑很清楚，先确认Rulepack已安装，再对照样本重扫，再看日志和结果文件。

　　1、先准备一组触发样本和一组对照样本

　　验证不要直接拿整库上来扫，先准备最小触发样本和最小不触发样本。这样你能先确认规则会不会命中，再确认误报边界够不够干净。这个做法虽然属于测试建议，但最符合Fortify官方把自定义规则用于真实规则扩展的使用方式。

　　2、先确认自定义Rulepack已经被扫描器看到

　　本地SAST链路里，可以先用fortifyupdate导入本地Rulepack；官方还给出了fortifyupdate-import的标准用法。导入完成后，再用-showInstalledRules查看当前已安装的Rulepacks，官方说明这里会显示当前安装的Rulepacks，包括自定义规则和自定义元数据。

　　3、如果走SSC统一管理，就在SSC里导入安全内容

　　官方SSC文档明确说明，管理员或安全负责人可以在Administration下导入安全内容，其中就包括用Fortify Custom Rules Editor创建的自定义Rulepacks。也就是说，如果你的规则要给团队共用，不能只在个人SAST机器上装，本质上还要在SSC侧完成一次导入。

　　4、验证扫描时把日志打开

　　官方SAST文档说明，-logfile可以指定日志文件，-verbose会把详细状态消息写到控制台和支持日志里，-debug-verbose会进一步增加细节，尤其对解析类问题更有帮助。规则验证阶段，建议至少带上日志文件输出，这样后面判断“规则没加载”还是“规则加载了但没命中”会更快。

　　5、用同一套构建ID做前后对照扫描

　　最稳的方式是先跑一版基线扫描，再装载自定义Rulepack后重跑同一份样本。官方示例里一直围绕固定build ID去做translate和scan，这也适合拿来做规则前后对照。这样你能直接比较新增问题、消失问题和预期命中情况。

　　三、Fortify规则上线前还要检查什么

　　规则能触发不等于已经可以上线。真正上线前，还要把装载路径、版本迁移、日志留痕和升级兼容性一起收口。官方文档已经提醒，升级SAST时如果不迁移设置，建议备份rules、customrules和外部元数据目录；这说明自定义规则从一开始就应该按“可迁移资产”来管理，而不是只留在某台扫描机里。

　　1、先固定Rulepack版本和命名

　　不要让同名Rulepack在多人环境里反复覆盖。更稳的做法是按版本号管理包名和导入记录，这样后面扫出来的问题变化才能和具体规则版本一一对应。这个做法和官方把Rulepack当成独立安全内容资产来导入、更新、迁移的方式一致。

　　2、再确认本地SAST和SSC装的是同一版规则

　　如果开发机本地扫描和SSC集中扫描装的不是同一版Rulepack，就很容易出现“本地能复现，平台上看不到”或者反过来的情况。官方既支持本地fortifyupdate-import，也支持SSC导入安全内容，所以两端版本一致必须单独核对。

　　3、升级SAST前先备份自定义规则目录

　　官方SAST文档明确建议，在不迁移旧版本设置时，备份Core/config/rules、Core/config/customrules、ExternalMetadata和CustomExternalMetadata等目录。也就是说，自定义规则上线后，这些目录本身就应纳入版本资产和备份范围。

　　4、把验证样本和验证日志一起留档

　　规则上线前，最好把触发样本、不触发样本、导入记录、扫描命令和日志文件一起留档。官方对-logfile、-verbose和-debug-verbose的说明，本质上就是给你留下可复查证据链的工具。

　　5、最后再决定放到扫描默认链路还是只在特定项目启用

　　如果规则还在观察期，更适合先在特定项目或特定扫描链路里启用；如果规则已经稳定，再进入团队默认扫描链路。官方把rules参数、规则目录和SSC导入都做成独立装载入口，也正适合做这种分阶段放量。

　　总结

　　Fortify规则定制，先用Fortify Custom Rules Editor和Custom Rules Guide把规则内容做出来，再按本地SAST、-rules参数、fortifyupdate-import或SSC导入这几条路径把自定义Rulepack真正装到扫描链路里。规则自定义后验证生效，核心不是只看包有没有生成，而是先确认Rulepack已安装，再用触发样本和对照样本重扫，并结合-logfile、-verbose、-debug-verbose和FPR结果核对问题类型、位置和描述。把规则版本、装载路径、验证样本和升级备份一起固定下来，后面规则维护会稳很多。