Fortify规则怎么定制，Fortify规则自定义与测试生效怎么做，真正难点不在“写出一条规则”，而在把规则做成可安装、可回滚、可复验的工程资产，并且让SCA与SSC两端口径一致。下面按定制思路、测试生效、版本管理三块拆开讲清。

　　一、Fortify规则怎么定制

　　Fortify规则定制建议先把需求拆成可落地的三类，再决定走新增规则、增强识别，还是做分类与严重度口径调整。这样做的好处是投入更可控，后续也更容易维护和复盘。

　　1、先明确你要定制的Fortify规则属于哪一类

　　（1）新增检测点，把公司内部禁止用法、必需封装、敏感API调用约束做成可命中的规则，避免只靠评审口口相传；

　　（2）增强识别能力，把你们的清洗函数、编码函数、鉴权函数、统一SQL执行封装标记成可信边界或消毒点，减少数据流误报；

　　（3）调整分类与口径，把问题映射到你们内部漏洞分类、严重度分级与整改口径，保证报告对外输出更统一。

　　2、选对定制入口与存放方式，避免改完被覆盖

　　（1）优先用Audit Workbench相关能力生成规则骨架，再补齐触发条件与描述，减少手写格式错误导致导入失败；

　　（2）自定义规则包与官方Rulepack分开管理，单独打包、单独版本号，避免更新官方规则库时把你们的改动冲掉；

　　（3）规则包命名建议包含适用范围与版本信息，例如适用语言或框架、主要目的与发布日期，便于多条流水线核对使用版本。

　　3、用样例驱动写规则，先可复现再扩大覆盖

　　（1）准备最小样例仓库或样例目录，至少包含Bad Case与Good Case两组代码，规则迭代只围绕这两组做对照；

　　（2）把规则写成可执行口径，必须明确触发条件、例外条件、风险解释与推荐修复方式，避免只写一句泛化描述导致复核困难；

　　（3）数据流类规则要先把Source、Sink、Sanitizer说清楚，尤其是自研框架里参数解析、模板渲染、ORM执行这类关键路径，不补识别信息会导致命中不稳定。

　　4、把定制过程做成团队资产，而不是个人经验

　　（1）规则包文件、变更说明、样例代码三样一起入库，任何规则改动都对应一次变更记录与一次样例复验记录；

　　（2）约定变更评审流程，规则逻辑变化、严重度口径变化、映射变化都要可追溯，避免多人并行改造成口径漂移；

　　（3）把规则包版本与扫描配置绑定，明确哪条流水线、哪类项目、哪种语言组合使用哪一版Fortify规则，防止“导入了但没用上”。

　　二、Fortify规则自定义与测试生效怎么做

　　Fortify规则自定义后最常见的问题是看起来导入成功，但扫描结果没有变化。建议按SCA侧导入核对、样例触发验证、SSC侧展示验证三步走，先保证本地可命中，再保证平台端口径一致。

　　1、先在SCA侧导入自定义规则并核对版本是否生效

　　（1）准备好自定义规则包文件，路径尽量使用英文目录并避免过长，减少解压与读取异常；

　　（2）在SCA执行环境中导入规则包后，立即用fortifyupdate查看已安装规则包列表，确认自定义规则包名称与版本号出现在列表里；

　　（3）如果定制涉及外部元数据，同步检查外部元数据是否已安装，避免出现规则命中了但分类、描述、映射不生效的情况。

　　2、用最小样例做触发验证，确认规则确实被执行

　　（1）先清理旧结果并使用固定构建ID执行短范围扫描，保证本次结果只来自当前规则库与当前样例；

　　（2）扫描后按自定义规则名称、类别关键词或你写入的描述字段检索，确认Bad Case稳定命中、Good Case稳定不命中；

　　（3）对数据流规则重点看链路是否按预期穿过你标注的清洗或封装点，如果链路不穿过，优先补识别信息而不是盲目加严检测条件。

　　3、在SSC侧验证展示口径与审计材料是否一致

　　（1）如果你们使用SSC集中审计，确保SSC侧也导入或同步了对应规则包与元数据，避免本地与平台解释不一致；

　　（2）在SSC里抽查一条由新规则触发的问题，核对问题详情页的分类、描述、建议修复是否符合你们的内部口径；

　　（3）导出一次报告做外部视角检查，确认标题、分类、严重度与描述没有出现缺字段或乱码，避免到了交付时才发现口径不完整。

　　4、规则导入后仍不生效的高频排查方向

　　（1）导入到了错误的安装目录或错误的执行节点，例如ScanCentral worker未同步导致CI仍用旧规则；

　　（2）规则包版本冲突或同名覆盖，导致实际加载的是旧版本或被其他包顶替，先以已安装列表为准做核对；

　　（3）扫描口径未绑定新规则包，流水线仍在用旧的Rulepack或旧的配置快照，先固定配置名与规则版本再复扫对比。

　　三、Fortify规则版本怎么管理Fortify规则回归验证怎么跑

　　Fortify规则定制越深入，越要像管理代码一样管理规则库，否则一次小改动就可能引入误报暴涨或漏报。把版本化、回归验证、灰度推广做成固定动作，规则才会越用越稳。

　　1、把Fortify规则库当成制品做版本化与可回滚

　　（1）每次发布规则包都升版本号，并维护变更清单，明确新增了哪些规则、修改了哪些触发条件、调整了哪些映射口径；

　　（2）保留可回滚版本并固定存放位置，出现误报暴涨或关键漏报时可以快速回退到上一版，再定位差异点；

　　（3）推广采用灰度节奏，先在样例仓库与少量真实项目验证，再推广到主流水线，避免一次更新影响全线交付。

　　2、建立规则回归用例集，专门验证命中是否符合预期

　　（1）回归用例集按漏洞类型与框架封装整理Bad Case与Good Case，覆盖你们最常见的入口、封装与清洗路径；

　　（2）每次规则变更输出命中清单对比，确认关键规则ID与关键命中点没有意外变化；

　　（3）持续补充新案例，把线上真实问题抽象成最小复现加入用例集，长期提升规则质量与稳定性。

　　3、把回归验证接入CI，自动化验证再推广

　　（1）规则库更新触发独立回归任务，回归扫描只跑小仓库但必须可复现、可对比；

　　（2）回归不通过则禁止把新规则包推广到主流水线，先修规则或补识别信息再重测；

　　（3）每次构建归档记录规则包版本、SCA版本、Rulepack版本与扫描参数摘要，告警突变先比版本再比代码。

　　4、误报治理优先收敛到规则与识别信息，不靠大面积抑制

　　（1）高频误报优先补框架识别、清洗点标注与边界定义，让数据流按真实语义走，再考虑是否需要调整规则条件；

　　（2）抑制只用于少量确认例外的点位，并且必须记录原因与约束条件，避免把真实风险一并压下去；

　　（3）定期清理历史抑制项与过期例外，规则口径收敛后把原本的临时抑制逐步撤销，保证治理方向可持续。

　　总结

　　Fortify规则怎么定制，Fortify规则自定义与测试生效怎么做，可以按一条可复用链路推进：先把需求归类并选择合适的定制入口，再在SCA侧导入并核对已安装版本，用最小样例完成触发验证，随后在SSC侧验证展示口径一致，最后用版本化与CI回归验证把Fortify规则管理成可持续资产，规则才能长期稳定服务真实工程。