组件发运前EOL扫描器

要解决的问题

镜像里的依赖并不总会以经典的 CVE 告警形式暴露风险。很多包只是「停止维护」，上游不再发布补丁，但仍然在基础镜像、发行版仓库和 SBOM 里正常存在，直到某天被安全公告点名。等 CVE 出来再补，往往意味着漏洞窗口已经真实存在了一段时间。

Xeol 面向的正是这类生命周期结束（End-of-Life）的软件包：还在被打包、还在被发运，但上游早已不再支持。

这个技能做什么

它在组件通过 Xeol 发运之前，对输入的镜像文件系统路径或 SBOM 文件做一次 EOL 状态检查，帮助团队在 CI 阶段就拦下不受支持的依赖。

核心工作流可以拆成三步：

• 确定输入：一个容器镜像的文件系统路径，或一份 SBOM 文档；两者择一即可，不要求两者同时具备。
• 调用 Xeol CLI：在本地或容器环境里运行扫描，Xeol 会解析包的包名与版本，再对照上游生命周期数据判断其支持状态。
• 读取结果并决定：发现已停止支持的包时，团队可以把它接进 CI 的发布门禁，让不满足要求的镜像无法发运。

需要说明的是，Xeol 判定的是「软件包本身是否还在支持周期内」，这与「包里是否存在某个已知 CVE」是两件事。一个还在支持期内的包也可能有未修复的漏洞，而一个已 EOL 的包未必立刻带来可利用的攻击路径。

适用边界

• 扫描输入是文件系统路径或 SBOM，不是直接对运行中的进程做运行时插桩。
• 要扫描运行中的容器，需要挂载 Docker socket，这种方式会引入额外的权限面，生产环境里要评估清楚再使用。
• Xeol 的能力不止覆盖 Docker，具体能识别哪些包管理器和发行版，取决于它当前支持的上游数据源范围。
• CI 集成是可选的。如果只是做本地一次性排查，不配置门禁也能拿到结果；如果要在流水线里常态化拦截，建议把它做成发布前的强制检查环节。
• 该技能依赖 Xeol CLI 及其上游文档，升级 CLI 版本时结论可能会有变化，不要把一次扫描结果当作长期不变的事实缓存下来。