很多团队觉得fortify的漏洞优先级排序不准，通常不是算法突然失灵，而是把Severity当成Priority在用，或在SSC里看的是某个筛选视图而不是Fortify Priority Order视图。另一方面，fortify的Severity本身由规则内容定义，不能随意改成企业自定义口径，所以要实现符合业务的风险等级，需要把内置优先级用于技术风险，把自定义风险标签用于业务优先级，两条线同时落地，排序才会稳定、可解释、可复用。

　　一、fortify漏洞优先级为什么排序不准确

　　优先级看起来不准确，往往是视图口径与指标口径不一致造成的。先把你们当前页面到底按什么在排清楚，再去调整风险等级，才能避免改完后依旧感觉乱。

　　1、把Severity当成Priority在比较

　　fortify的Severity是规则内容的一部分，由Fortify安全研究人员维护并分配，属于规则语义，不等同于企业修复顺序；而Fortify Priority Order更偏向风险象限，会综合Impact与Likelihood来分层，你如果拿Severity去对照Priority，自然会觉得排序不对。

　　2、SSC页面没有切到Fortify Priority Order口径

　　SSC的OVERVIEW与AUDIT页面提供按Fortify priority order查看问题的入口，通常以Critical、High、Medium、Low的文件夹链接形式呈现；如果你在自定义列表里按别的列排序，结果就不会按Friority分层。

　　3、同一条问题在不同版本被合并后优先级观感变化

　　当你们上传多次扫描结果并做合并，问题会带上历史、状态、标签与审计信息；如果某些问题在不同分支里被不同人打了标签或改了可见性，列表里看起来就像优先级忽高忽低，实际上是筛选条件在起作用。

　　4、Likelihood相关信息不足导致推断偏保守

　　fortify的Likelihood在方法论上会结合Confidence、规则准确度与可利用概率等因素，如果项目缺少必要的语义信息或规则内容版本不匹配当前框架，Likelihood更容易被推到偏高或偏低，从而影响最终优先级观感。

　　5、误报与低置信问题未分层处理，噪声淹没真实高风险

　　当低Confidence或已确认误报没有被过滤或标识，列表里会堆积大量看似高优先级但实际不成立的问题，团队就会产生排序不准的直觉；这种问题属于审计与过滤口径缺失，不是计算口径的问题。

　　二、fortify风险等级应怎样重新设定

　　重新设定风险等级的关键点是分清哪些能改、哪些不建议改。一般不建议试图改规则的Severity本体，而是用Fortify Priority Order做技术风险底座，再用Issue Template里的自定义标签建立业务风险等级，并把它做成统一的筛选与报表口径。

　　1、先把团队默认视图固定为Fortify Priority Order

　　在SSC进入应用版本的【Audit】页，优先用页面上Critical、High、Medium、Low入口查看问题，确保大家讨论的是同一套Friority分层；需要排序时，在列表列头选择按Priority相关列排序，避免每个人用不同列排序造成讨论口径漂移。

　　2、在SSC创建业务风险等级自定义标签

　　进入【Administration】视图，在左侧选择【Templates】下的【Custom Tags】，点击页面上的【NEW】，创建一个名为业务风险等级的标签，并预置P0、P1、P2、P3或Critical、High、Medium、Low等值，描述里写清使用规则，例如P0代表必须阻断发布。

　　3、把自定义标签绑定到Issue Template并应用到应用版本

　　自定义标签的定义会存储在Issue Template中，并与应用版本关联；你需要在模板层面把业务风险等级设为默认可用的标签集合，再把该Issue Template应用到对应的application version，确保后续审计与筛选都能看到同一套标签。

　　4、在审计流程中明确谁来设定业务风险等级与准入条件

　　在SSC的审计页面，要求审计人员在确认问题有效后再填写业务风险等级，同时补一条自定义标签例如是否阻断发布或是否需要安全复核，用标签把流程节点固化下来；需要更强权限控制时，可将标签设为Restricted类型，仅允许安全负责人或管理员修改。

　　5、用过滤口径把技术优先级与业务优先级叠加展示

　　在日常视图中先按Fortify Priority Order过滤出Critical与High，再用业务风险等级二次筛选，例如仅看P0与P1；这样可以把技术高风险但业务可接受与业务必须先修两类问题分开，避免单一排序承担所有决策。

　　6、规则内容与扫描内容版本先统一，再评估是否需要自定义规则收敛

　　如果你们近期更新了技术栈或语言版本，建议同步更新Fortify Software Security Content与规则内容口径，先让检测语义贴近现状，再讨论风险分层是否仍需要额外收敛；规则内容更新本身就会影响误报率与分类一致性。

　　三、fortify优先级口径怎样长期保持一致

　　风险等级重设之后，最怕的是两周后又回到各看各的。要让排序稳定，必须把模板、标签、过滤与更新节奏四件事固定下来，并留出回滚与抽查机制，避免把真实高风险误压下去。

　　1、把Issue Template与自定义标签当作版本化资产管理

　　给模板命名包含日期与口径版本，例如RiskTemplate 2025Q4，并记录本次口径调整点；当需要改动业务风险等级定义时，新建模板版本而不是直接覆盖旧模板，便于追溯报表口径。

　　2、建立两套固定视图用于日常与抽查

　　日常视图用Fortify Priority Order加业务风险等级筛选提高效率，抽查视图保留只按Fortify Priority Order的全量视图，用于每个迭代抽检一批已降级或已豁免的问题，防止误判沉积。

　　3、把标签填写与审计证据写进流程要求

　　规定设置业务风险等级时必须填写备注字段或审计说明，至少说明数据流证据、触发条件与业务影响范围，这样优先级争议才能回到证据层讨论，而不是在列表排序上争论。

　　4、规则内容更新与基线发布绑定节奏

　　将规则内容更新与扫描基线发布绑定，例如每季度统一升级一次内容包并做一次差异复核，避免同一应用在不同流水线使用不同内容版本造成优先级漂移，最终又被认为排序不准。

　　总结

　　fortify优先级排序看似不准，常见原因是Severity与Fortify Priority Order口径混用，或SSC视图没有按Friority分层展示。风险等级重设更可行的做法，是保留Fortify Priority Order作为技术风险底座，同时通过Issue Template里的自定义标签建立业务风险等级，并把创建标签、绑定模板、审计填写与过滤视图固化成团队标准，这样排序既能解释也能长期稳定。