很多团队在Fortify里跑通扫描后，真正卡住的反而是例外：谁能提、提什么、要写到什么程度、谁来批、批完怎么追踪、到期怎么收回，一套流程走下来比修一个中等风险问题还耗时。例外流程之所以显得复杂，根源往往不是“管得太严”，而是缺少统一口径与可复用的字段，导致每次都从零开始解释，审批也只能靠人盯人。

　　一、fortify例外申请流程为什么过于复杂

　　例外流程一旦没有标准化字段与入口，就会出现同一类问题在不同团队写法完全不同，安全、研发、管理层各自理解不一致，最后只能用更多审批环节去“兜底”。建议先把复杂度来源拆开看清楚，才能对症做减法。

　　1、例外与误报与延期修复被混在一起

　　很多团队把Not an Issue、可利用性低、暂不修复、延期修复都叫例外，但SSC默认的Analysis标签本身就包含Not an Issue等审计分类，如果不先定义边界，申请表会越写越长，审批也越来越像“补材料”。

　　2、没有统一字段，导致每次都要写长篇理由

　　缺少固定字段时，研发只能用自由文本描述，安全审核只能靠阅读理解，复核也无法批量比对，最后不得不加会签与反复补充说明来降低误判风险。

　　3、缺少可复用的审批状态，流程只能靠人工推动

　　如果系统里没有“待审、已批、已拒、到期复核”这类可筛选状态，例外只能靠邮件或群消息推动；而社区里常见做法是用SSC自定义标签来做审批状态值，实现可检索的流程状态。

　　4、例外没有到期机制，审批人担心放出去就收不回

　　没有有效期与复核节点的例外，风险会在系统里长期沉积，审批人自然倾向于“多审几轮”；而一旦把有效期与复核责任写成字段，审批会更敢做快速决策。

　　5、例外结果没有和缺陷系统打通，追踪链路断裂

　　例外本质是风险接受或阶段性处理，如果没有把例外与工单、版本、责任人绑定，后续回溯会很痛苦；SSC支持通过缺陷跟踪插件把问题推送到外部系统，在审计阶段就能把追踪链路建起来。

　　二、fortify例外审批应怎样简化

　　简化不是减少控制点，而是把控制点前移到模板与字段里，让申请人一次填对，让审批人一眼看清。落地时建议用SSC的Custom Tags与Issue Template把例外字段标准化，再用最少的两级审批完成闭环。

　　1、先把例外类型做成固定枚举，申请表立刻变短

　　在SSC点击【Administration】，左侧进入【Templates】再进入【Custom Tags】，点击【NEW】新建自定义标签，标签名建议用例外类型，值建议固定为误报、风险接受、延期修复、第三方依赖、已替代控制等，描述里写清适用边界，避免自由发挥。

　　2、用审批状态标签代替邮件流转

　　继续在【Custom Tags】里新增审批状态标签，值可设为Not Set、Not Approved、Approved，并把默认值设为Not Set；社区里也明确给过用自定义标签实现Approved与Not Approved的做法，用来模拟审批流非常直接。

　　3、把必填项固定为五个字段，避免长篇论证

　　建议把例外申请固定为五项：例外类型、风险说明、替代控制、到期日期、审批状态；其中风险说明要求一句话写清影响面，替代控制要求写清已有的防护或监控，避免把材料写成“作文”。这些字段都用自定义标签承载，后续才能筛选与报表化。

　　4、用Issue Template把标签与应用版本绑定，避免每个团队各配一遍

　　在SSC里自定义标签可以通过Issue Template管理并复用，适合由安全团队统一维护；做法是先在模板层面定义标签，再让各应用版本使用同一套模板与标签集合，避免出现A项目能选到期日期、B项目没有的情况。

　　5、只保留两级审批，其他校验交给规则与准入条件

　　建议把审批拆成两级：研发负责人确认业务必要性，安全负责人确认技术风险与替代控制；其余内容用准入条件替代，例如未填写到期日期不允许提交、未填写替代控制不允许标记Approved，这样流程节点更少但质量更稳。

　　6、对已确认不处理的项，用抑制作为收口动作减少反复出现

　　对于确认为已修复或明确不计划修复的项，可以在审计工具里执行Suppress来标记并在后续发现中保持抑制状态，减少每次复扫都重新走例外流程；需要注意抑制属于半永久标记，必须配合到期复核与权限控制使用。

　　三、fortify例外口径应怎样固化

　　流程简化之后，最怕的是口径再次漂移，半年后又回到“每次重新解释”。把例外当作可治理资产来管理，关键是固化字段、固化追踪链路、固化复核节奏。

　　1、把例外与缺陷系统打通，例外就不再是孤立记录

　　在SSC点击【Administration】，左侧进入【Plugins】再进入【Bug Tracking Plugins】，点击【NEW】上传并启用缺陷跟踪插件；SSC文档明确支持与Jira等系统集成，用来在审计时把问题推到工单系统，例外也能跟着工单状态走。

　　2、用固定报表视图呈现三类清单，管理层才看得懂

　　建议长期只输出三张清单：已批准且未到期的例外、已到期待复核的例外、被拒绝但仍在代码里的问题；清单字段只用前述五项加上应用版本与发现时间，这样任何人拿到报告都能快速定位重点。

　　3、把到期复核做成例行节奏，而不是临时催办

　　每次迭代或每月固定一次复核，把到期日期在当周的例外拉出来集中处理；到期后只允许两种动作，续期并更新替代控制，或撤销例外并推动修复，避免“默认续期”。

　　4、用权限控制限制谁能把状态改成Approved

　　审批状态标签建议只允许少数角色修改，避免研发自行把Not Approved改成Approved导致审计失真；自定义标签本身支持在系统层面统一管理，便于安全团队维护口径。

　　5、把例外决定与审计学习结合，减少重复争议

　　当团队频繁把同类问题判为Not an Issue或例外，可以把审计结论沉淀为统一的标签规则与说明，必要时配合审计辅助能力，让后续同类问题更快归类，减少反复讨论。

　　总结

　　fortify例外流程显得复杂，多数是因为边界不清、字段不统一、状态不可复用、到期不可管理、追踪链路断裂。简化的核心做法是用SSC的自定义标签与Issue Template把例外信息标准化，把审批状态做成可筛选的枚举值，只保留两级审批，并把到期复核与缺陷系统集成固化为例行机制；这样既能降低沟通成本，也能让例外成为可追踪、可审计、可回收的风险治理闭环。