EOL 组件治理实战：过期依赖清退配置

作者

EOL 组件治理要解决的是一个很具体的困境：业务还在跑，但底层组件已经没有人修漏洞了。很多团队把安全投入压在漏洞扫描上，报告年年清零，却始终说不清自己有多少个版本早已停止维护。本文给出一条可执行的链路：从真实产物抽取组件清单，用数据源批量判定版本生命周期，再把判定结果变成可跟踪的升级与清退计划。

适用场景

适用于已经把资产盘点做了一半、但版本台账仍靠人工表格维护的团队。典型触发点有三个：等保或客户审计要求证明组件处于支持周期内；某个常用组件官方宣布分支停止维护，需要评估影响面；年度依赖清理时发现同一组件在不同主机上有多个版本共存。

  • 服务器与容器镜像的组件版本无人跟踪，只在出事时翻记录
  • 框架已停止维护，业务以「能跑就行」为由长期搁置升级
  • 同一组件在几十台主机上有七个不同版本，没有统一基线
  • 审计时被问到「哪些组件已 EOL」，回答只能依赖个人记忆

判断是否需要这套流程的标准很简单：如果回答最后一个问题需要超过一天，就值得把它固化成脚本。治理的成本主要不在工具，而在于把判定口径和数据来源定下来。

前置条件

  • Linux 主机，具备运行二进制工具与 Docker 的环境
  • 可访问外网用于拉取扫描工具与生命周期数据；纯内网环境需先准备离线镜像与数据副本
  • 有一份可用的服务清单，明确哪些目录、哪些镜像构成在线业务
  • 具备 sudo 权限，可写入 /opt/sbom 与系统日志

原理说明：EOL 为什么比单个 CVE 更棘手

CVE 描述的是一个具体缺陷，EOL 描述的是整个版本分支不再有人生产补丁。前者有明确的修复路径，后者连修复的提供者都不存在。组件进入 EOL 之后，新披露的漏洞不会再有官方修复，WAF 规则与运行时防护只能缓解利用，无法从根上消除缺陷。

治理的核心不是扫描动作本身，而是把组件版本与支持周期建成可计算的映射关系。落地分三步：先从真实运行产物中抽出组件与版本，生成软件物料清单；再向生命周期数据源查询该版本的支持状态；最后把判定结果落到升级计划与工单。任何一步缺失，台账都会在三个月内退化成手工表格。

另一个容易忽略的点是命名差异。软件包名、镜像标签、语言依赖名往往不是同一套写法，同一个组件可能以 openssl、libssl3、cryptography 三种形态出现在清单里。因此判定层必须允许「未匹配」，并把未匹配项收集起来人工确认，而不是强行给出结论。把未匹配当成已适配，是这类巡检最常见的失真来源。

操作步骤一：生成可信的组件清单

清单必须来自运行时产物。开发人员口述的依赖文件通常只覆盖应用层，漏掉基础镜像里的系统库，而系统库恰恰是最容易长期不动的部分。目录与镜像两条路径都要覆盖。

mkdir -p /opt/sbom

# 1) 扫描主机上的应用目录，输出 SPDX 格式清单
syft dir:/srv/app -o spdx-json=/opt/sbom/app-spdx.json

# 2) 扫描镜像仓库中的实际镜像，输出 CycloneDX 格式清单
syft registry:registry.example.com/portal:1.8.2 -o cyclonedx-json=/opt/sbom/portal-cdx.json

# 3) 同一批产物用 trivy 再跑一次，附带已知漏洞信息
trivy fs --format json --output /opt/sbom/trivy-app.json /srv/app

清单生成后先看组件总量。数量异常偏少通常不是组件真的变少，而是扫描路径写错了，例如只扫了 jar 包目录而漏掉 /usr/lib。建议先用一台已知环境的测试机跑一次，把结果作为基线记住，后续每次巡检都与基线比对，偏差超过一倍立即回头查路径。

操作步骤二：批量判定版本生命周期

生命周期数据源提供各产品分支的 eol 与 latest 字段，适合做机器判定。下面的脚本读取 SPDX 清单，逐个查询并输出四列：组件名、版本、状态、该分支最新版本。

#!/usr/bin/env python3
# /opt/sbom/eol_check.py
import json
import urllib.request

EOL_API = "https://endoflife.date/api/{product}.json"


def load_components(path):
    with open(path, encoding="utf-8") as f:
        data = json.load(f)
    return [{"name": p["name"].lower(), "version": p.get("versionInfo", "")}
            for p in data.get("artifacts", [])]


def eol_status(product, version):
    try:
        with urllib.request.urlopen(EOL_API.format(product=product), timeout=10) as r:
            cycles = json.load(r)
    except Exception as exc:
        return "UNKNOWN", str(exc)[:40]
    major = ".".join(str(version).split(".")[:2])
    for c in cycles:
        if str(c["cycle"]) == major:
            return ("EOL" if c["eol"] is True else c["eol"]), c.get("latest", "-")
    return "NOT_MATCHED", "-"


for comp in load_components("/opt/sbom/app-spdx.json"):
    state, latest = eol_status(comp["name"], comp["version"])
    print(comp["name"], comp["version"], state, latest, sep="\t")

输出中三类状态必须分开处理：EOL 表示该分支已停止维护，直接进入升级计划；NOT_MATCHED 表示数据源未收录该版本，多见于自研组件或小众库，需人工确认；UNKNOWN 表示查询失败，属于链路问题，先补网络或缓存，不能当作安全结论。把三类混在一起统计，得出的数字既不能用于汇报，也不能用于排期。

操作步骤三：清退与升级策略落地

判定结果出来后不要一次性全量升级。按影响面分三档：可直接升级的（无外部依赖）、需要灰度的（有状态或存在兼容风险）、只能隔离的（厂商已停止支持且短期无法替换）。同时把不可随意变动的底层库锁死，避免自动更新在业务高峰打断服务。

# 锁定底层关键库，防止被无计划升级
apt-mark hold libssl3 libc6
apt-mark showhold

# 仅允许安全源自动更新，并把有兼容风险的组件加入黑名单
cat >/etc/apt/apt.conf.d/51security-only <<'EOF'
APT::Install-Recommends "false";
Unattended-Upgrade::Allowed-Origins {
    "Debian:stable-security";
};
Unattended-Upgrade::Package-Blacklist {
    "nginx";
};
EOF

对短期无法升级的 EOL 组件，补偿手段是收敛暴露面：只允许内网访问、在反向代理层拦截已知利用特征、把该服务纳入重点监控。补偿不是治理终点，但能让升级排期不必带着风险干等。需要注意的是补偿措施必须写进台账并设置复查日期，否则一年后没人记得这个组件还是过期状态。

配置验证

验证要证明三件事：清单覆盖真实服务、判定结果可复现、告警真的能到人。前两项用命令核对，第三项必须真发一次通知。

# 巡检挂到定时任务，命中 EOL 直接写系统日志，便于统一收集
0 3 * * * /usr/bin/python3 /opt/sbom/eol_check.py | \
  awk -F'\t' '$3=="EOL"{print "EOL_COMPONENT "$0}' | logger -t eol-audit

# 核对清单覆盖度：与系统实际安装包数量同量级即为合理
grep -c '"name"' /opt/sbom/app-spdx.json
dpkg -l | grep -c '^ii'
  • 清单覆盖：抽查三台主机，清单组件数量应与实际安装包数量同量级，偏差超过一倍需检查扫描路径
  • 判定可复现：同一份清单连跑两次，EOL 条数应完全一致；不一致说明接口有随机失败，需加本地缓存
  • 告警可达：手工把一个测试组件的版本改成已 EOL 版本，确认 24 小时内收到通知

三项全部通过，才算这条链路可用。只有清单没有告警，等于又做了一份没人看的报告，下次审计还得重新人工统计一遍。

常见问题

Q1：清单里的组件名与生命周期数据源的产品名对不上怎么办？

这是最高频的问题。解决办法是维护一张映射表，把组件名前缀映射到产品名，例如把 libssl、openssl-dev 统一映射到 openssl。脚本查表失败时退化为人工确认，并把未命中的名字记入待补列表。映射表初期会有几十条，跑两个月后基本稳定，此后只有新引入的组件才需要新增条目。

Q2：纯内网环境无法访问外部接口，怎么判定 EOL？

把数据源的全量 JSON 拉到本地，部署成内网静态文件服务，脚本里把接口地址换成内网地址即可。EOL 状态不是秒级变化的信息，每周同步一次完全够用。同步脚本要记录版本号或时间戳，避免某次同步失败后用旧数据得出错误结论，那比没有数据更危险。

Q3：升级窗口与业务迭代冲突，优先级怎么排？

按「暴露面 × 利用成熟度」排序，而不是单纯看分数。公网可达且已有公开利用代码的 EOL 组件第一优先；内网可达但需要认证的第二优先；离线工具链、构建环境里的 EOL 组件第三优先。这个排序更贴近真实风险，也更容易向业务方解释为何某个升级不能排到下季度。

总结

EOL 组件治理的产出不是一份报告，而是一条能自动跑的链路：清单自动生成、状态自动判定、结果自动告警、清退自动跟进。链路跑通后，回答「还有几个过期组件」从两天缩短到一条命令，风险也从不可见变成可排期。真正决定成败的不是工具选型，而是把未匹配与查询失败这两类结果当回事，它们才是台账失真的源头。