同一款程序的公告既有内部编号又有 CVE 编号，跟进以哪个为准

同一款程序的安全公告既有内部编号又有 CVE 编号，跟进时以哪个为准？按用途分：要把漏洞跨产品检索、丢进资产库比对，用 CVE 编号；要决定「我的站点是否受影响、升到哪个版本」，只能看厂商公告里那一行受影响版本与修复说明。两者不是竞争关系，缺一条都会走偏。

两套编号分别给谁用

CVE 编号的价值在于横向对齐。同一类缺陷可能同时出现在多个程序、多个分支里，安全设备、依赖扫描、资产台账大多按 CVE 建索引，用它做键能把外部数据接进来。它的局限也很清楚：一条 CVE 只描述缺陷本身，不告诉你这家厂商打算在哪个版本修、修没修完。

厂商内部编号是纵向口径。它对应的是「这个产品的一次发布解决了什么」，通常和修复版本、支持分支、下载页面绑在一起。跟进动作里真正能执行的步骤——升到哪个版本、有没有可升级的受支持分支——都写在这一条上。

一条公告里为什么会同时出现两个编号

Joomla 的安全中心清单里能看到这种并存：条目本身按内部编号（同批从 1092 排到 1096）与日期前缀发布，每条同时列出对应的 CVE 编号，例如 CVE-2026-92232 对应其中一条输入过滤相关的跨站脚本问题；再往下列出受影响版本区间与支持分支的修复日期。这类页面通常在标题里写 resolved security issues，也就是「已解决」清单——它描述的是修复动作已经完成，而不是漏洞刚刚公开。

读这三行时建议按固定顺序落表：

跟进时该以哪一行为准

判断「要不要动」以受影响版本区间为准。区间是硬条件：当前版本不在区间内，严重级别再高也不必临时变更；落在区间内，级别再低也要排进窗口。评级用来排队列顺序，不能用来做是否受影响的判断，这是最常见的误用。

判断「怎么动」以厂商的修复说明为准。有些公告只有降级配置或关闭某个功能作为临时缓解，因为对应分支没有可升级版本；这种情况内部编号那一行会写清楚，CVE 那一行不会。

判断「记录在哪」建议两边都留。台账里存 CVE 便于外部沟通，存厂商编号与修复版本便于自己回溯；只有 CVE 的记录，半年后往往查不到当时到底升到了哪一版。

清单措辞带来的两个读法陷阱

第一个陷阱是把 feed 当成披露起点。自述为「已解决的公告清单」的页面，发布时间通常晚于漏洞发现，跟进窗口要以修复版本可得的时间算，而不是以公告出现在清单顶部的时间算。

第二个陷阱是把同批编号当成同一风险。同一天连续发布的条目里，既有只影响旧分支的历史修复，也有匿名可利用的登录相关问题；同批编号只说明它们在同一次发布里被解决，不代表处置顺序相同。

自有系统该怎样留出处

自研或独立发行的系统同样要有可回溯的出处。以本项目为例，版本记录按版本号写修复条目：v3.6.6 记录了两项高危问题的修复，一项是列表的排序参数拼接进查询语句的注入，另一项是站点切换用的登录凭证可被伪造，并给出生成一次性票据的方式与升级后轮换签名密钥、修改管理员密码的建议；更早的 v3.6.5 则把工具层重建、邮件订阅、留言列表与附件 base64 上传按条目列在同一个版本号下。

这样做的好处是：对外沟通时可以按版本号回答「你用的是哪一版、那一版修了什么」，内部复盘时不必去猜某条改动属于哪次发布。如果自家系统还没有版本记录，最低成本的做法是每次发布留一份「编号—改动—影响范围」三列的清单，比只在提交信息里留痕更容易被复查。

常见问题

问：只登记 CVE 编号行不行？ 答：能对齐外部数据，但会丢掉升级路径。跟进动作依赖厂商那一行的受影响版本与修复版本，两边都留最稳。

问：同一批公告里有几条只是旧分支的历史问题，要不要一起处理？ 答：先核自家版本是否落在受影响区间。落在区间外的条目记录出处后可以排在常规窗口，不必挤占紧急处置的时间。

问：评级只写了中等，可以延后吗？ 答：延后不等于忽略。中等评级如果伴随匿名可利用、或落在权限最高的后台页面上，处置顺序应当提前，评级本身不足以决定顺序。

问：公告没有 CVE 编号怎么办？ 答：仍能跟进。厂商内部编号加修复版本已足够确定处置动作，只是后续与外部系统对齐时要自己补一层映射。