停止维护的开源组件：企业里最沉默的供应链风险

爆出高危漏洞的组件会上新闻，停止维护的组件不会——它只是安静地留在你的依赖树里，不再有人修漏洞、不再有人看 issue、不再发布新版本。行业年度报告反复给出同一个量级的结论：绝大多数被审计的代码库都含有超过四年未更新的开源组件。这是企业软件资产里最沉默、也最普遍的供应链风险。

停更为什么危险

漏洞永不修复。Log4j 1.x 早在 2015 年就宣布停止维护，但 2021 年 Log4Shell 应急时，无数企业在排查中发现自己还在大规模使用 1.x——而 1.x 自己的反序列化漏洞（如 CVE-2021-4104）已经注定不会有官方补丁。Python 2 在 2020 年初停止支持、AngularJS 在 2022 年初终止维护，至今仍活跃在大量生产系统里。停更组件的每一个新漏洞都是永久性敞口。

依赖链的连坐。你的直接依赖也许还在维护，但它依赖的底层库停更了——传递依赖的 EOL 会沿着依赖树向上传导，而多数团队从不检查第三层以下的依赖状态。

单点维护者风险。停更往往不是公告出来的，而是"维护者消失"式的：xz 事件的起点正是原维护者精力枯竭，攻击者以"接盘侠"身份潜入。周下载量百万级的包由一个人业余维护，在开源世界不是例外而是常态。

识别：EOL 是数据问题,不是判断问题

组件是否停更，需要的是数据而非感觉：官方 EOL 公告、最后发布日期、issue 响应情况、维护者活跃度。工程上把这件事交给 SCA 平台在台账层持续标注——每个在用组件的最后更新时间、EOL 状态、社区活跃度评分自动可见，而不是等某次安全事件才被动发现。这也是准入评估必须包含"可持续性"维度的原因：与其五年后处置停更组件，不如引入那天就看一眼社区健康度——发布节奏、贡献者数量与集中度、issue 响应时长。

评级：不是所有停更都要立刻处理

存量停更组件通常数量可观，全部立即升级既不现实也无必要。按两个维度评级：暴露面（组件是否处理外部输入？在攻击路径上吗？纯内部工具里的停更组件和公网服务里的完全是两个风险等级）与已知漏洞状态（有未修复 CVE 的停更组件进最高优先级；暂无已知漏洞的进观察队列——注意是观察而非豁免，因为新漏洞随时可能披露且永远不会有补丁）。

四种处置策略

升级：组件有活跃的后继大版本（Log4j 1.x → 2.x/Logback），成本主要在 API 变更适配，优先走这条路。替换：项目彻底死亡时迁移到活跃替代品（AngularJS → 现代框架），成本高，纳入技术债路线图分期执行。隔离加固：短期无法升级替换的（常见于嵌入式与遗留核心系统），用网络隔离、WAF 虚拟补丁、权限收敛压缩暴露面，为迁移争取时间——注意这是止痛不是治疗。商业接续：部分 EOL 软件有厂商提供付费的延长支持，适合迁移周期特别长的合规敏感场景。

把它变成例行公事

停更治理最忌运动式。可持续的做法是三个自动化节拍：台账里 EOL 与活跃度持续标注（日常可见）、新组件引入时社区健康度门禁检查（增量不再恶化）、每季度一次存量停更组件的评级复审（高优先级项进当季迭代）。做到这三拍，这个"最沉默的风险"就从定时炸弹变成了普通的、可排期的工程事项。