一年新增上万个漏洞条目九成出在扩展而非核心，清单怎么自证

一年新增的上万个漏洞条目九成出在扩展而非核心，站点要自证组件清单干净，靠的不是「核心程序版本没问题」这句话，而是三张台账：装了哪些扩展组件、每个组件当前在用哪个版本、每个组件从哪里来并由谁维护。当天核对到的白皮书把分布讲得很直白：统计年份里新增了一万一千三百余个漏洞条目，91% 出在扩展插件，核心程序只占六条。

分布口径说明了什么

九成以上集中在扩展，意味着风险面由「你装了什么」决定，而不是「你用了哪个程序」。核心程序的代码被大量审计、发版有固定流程；扩展组件数量多、维护者分散、审查深度不一，两者不在同一个量级上。同一份资料还给出另一组时间口径：被集中利用的漏洞从中位时间看只有五个小时量级就会被大规模利用，来不及核对清单的站点只能被动挨打。

这也是为什么「我们的系统很安全」这句话单独说不成立：它只在核心层为真，扩展层要逐条查。

先清清单再谈补丁

清清单的顺序是先把组件枚举出来，再逐条对照受影响区间。枚举不能靠记忆，要从部署目录、依赖清单与后台插件页三处交叉导出，取并集。很多站点的问题是清单里存在「已经没人记得为什么装」的组件，这些组件往往还在被访问。

对照区间时要把上界与下界都抄下来，只记「已修复版本」的会漏掉分支线：同一款组件常有多个并行维护版本，只升到最新的一个分支，另一分支上仍在跑的老代码依然暴露。

三张台账怎么建

三张表交叉起来才能排序：受影响区间命中、且在用版本无修复、且组件已停止维护的，优先级最高；来源不明的扩展即使当下没有已知漏洞，也应该先下线再评估。

防护能力不等于组件安全

程序侧内置的防护是另一层。安企内容管理系统（AnQiCMS）在输入与控制台上覆盖 SQL 注入、XSS 与敏感词过滤，配合令牌化的接口鉴权与干扰码，这些能力处理的是「请求进入系统时」的风险，不能替组件版本背书。组件自身带漏洞时，恶意输入可能走的是完全不同的路径。

同理，内置备份能力解决的是出事之后能不能退回，它降低的是恢复工时，而不是被攻击的概率。把「有防护、有备份、有清单」三件事分开描述，才对读者有用。

常见问题

问：只用官方目录里的扩展是不是就不用核对？ 答：不是。目录里的组件同样会出漏洞，只是来源可信度更高，版本对照仍要做。

问：清单多久拉一次？ 答：至少按季度，并在每次上游通告时重跑一次版本对照。

问：无法升级的组件怎么处理？ 答：先确认它是否还在被访问，能下线就下线；不能下线就记录风险接受与责任人。