【论文解读】An LLM-based Quantitative Framework for Evaluating High-Stealthy Backdoor Risks in OSS Supply Chains

xz-utils 那次投毒是这篇论文的主要背景，因此有必要说清楚。

xz-utils 是 Linux 上常见的压缩工具，核心库叫 liblzma。2024 年 3 月 29 日，PostgreSQL 开发者 Andres Freund 在 Debian sid 上排查 SSH 登录 CPU 占用异常和 Valgrind 报错，最后发现问题不在 Debian，而在 xz 上游发布的 5.6.0 和 5.6.1 两个 tarball。事件后来编号为 CVE-2024-3094，最初的技术细节由 Freund 发在 oss-security 邮件列表。

这不是往 Git 仓库里塞一段显眼的恶意源码。触发构建的 M4 宏只出现在发布 tarball 里，真正的对象文件则伪装成测试数据留在仓库中；满足特定构建条件时，脚本才把它解出来并链接进 liblzma。OpenSSH 本身不直接链接 liblzma，但在受影响的 Linux 组合里，sshd 会经由 systemd 把它带进进程，恶意代码随后干预认证前的 RSA 校验路径，带来未授权访问或远程代码执行风险。

好在它被发现时，5.6.0 和 5.6.1 主要还在 Debian sid、Fedora Rawhide 这类开发分支里，没有大面积进入稳定发行版。可怕的地方不只是一段后门，而是攻击者把恶意对象、测试文件、发布 tarball 和下游构建条件串成了一条链；只盯着 Git diff，很容易漏掉其中一半。

事情被揭出来后，圈子里一个很常见的说法是：这种长期潜伏可遇不可求。

我一开始也觉得有道理。可红队真接受这个前提，选目标就只剩下碰运气。

这篇 AAAI 2026 论文换了个问法：先不猜谁会成为下一个受害的 xz 库，而是站到攻击者那边看，哪些上游项目更值得长期投入？范围也收得很窄，不扫 npm、PyPI，只看 Linux 发行版会真正收进去的 APT 上游。

然后看四件事：影响能传多远，payload 能不能藏，社区能不能混进去，构建时有没有机会触发。

开源实现叫 HSBRiskEvaluator。我把论文和仓库里的代码对着看了一遍，下面按攻击过程拆。

只打会进发行版的上游

第一刀不是按 GitHub star 排，也不是从 trending 里捞项目。

Debian 里标成 required / important / standard 的包一共 319 个，其中 66 个有公开 GitHub 仓库。评估只跑这 66 个。论文写得很直白：没公开协作面的包装不上社区这一维。

仓库里的批处理脚本，做的也是这件事：

1. get_priority_packages.py 从 APT 抽出高优先级包
2. 展开依赖，写成 yaml
3. LLM 把 salsa.debian.org 上的下游镜像，对回 GitHub / GitLab 上游
4. 拉 PR、commit、workflow、二进制路径
5. 四维评估，再合成 HSBR

这也解释了为什么原生安装只支持 Debian 系。Dependency Impact 要直接问本机 APT：这个包是不是 essential，又有多少高优先级包依赖它。换成 Fedora 或 npm，不能只改个包名接着跑，这一维的尺子要重做。

xz 的杀伤力也不是 star 堆出来的。liblzma 会进发行版，后来又撞上 OpenSSH，这才是事情麻烦的地方。APT 的 priority / essential 标签，量的就是这层爆炸半径。

OpenSSF Scorecard 一类工具更像在检查仓库卫生：依赖新不新，CI 配得好不好，artifact 干不干净。这篇多算了两件很像攻击者会关心的事：交多少个 PR 才能成为 maintainer，以及 test 目录里本来就有没有二进制文件。

四个分数是怎么来的

论文把一次投毒拆成四步，每一步对应一个分数：

论文里的合成公式是：

R_total = 0.3·DI + 0.2·PC + 0.3·CQ + 0.2·CI

DI 和 CQ 的权重更高。放回 xz 里不难理解：东西得传得远，人也得混得进去。

不过代码和论文这里没完全对上。仓库的 calculator.py 把 CI 和 CQ 的 0.3 / 0.2 对调了。下面我按论文正文的权重讲。

标题里写着 LLM-based，很容易让人以为模型会读完整仓库、找后门。实际没这么玄。大部分指标都是静态统计：APT 标签、直接 push 的比例、成为 maintainer 前交过多少 PR、workflow 里的 Action 有没有 pin 到 40 位 SHA。

LLM 只补静态分析不太好做的四个缺口：

• 找上游：Debian 包名对回 GitHub / GitLab，模型是 gpt-4.1:online
• 给二进制路径分类：只看路径字符串，不读文件内容。tests/ 还是 docs/ 还是 src/
• PR 对得上吗：title、body 对 changed_files，最多 300 个、30 个一批，不看 diff
• CI YAML 会不会被注入：pull_request_target、把 PR body 拼进 run: 这种

这里还有一个实现差异：论文实验写的是 GPT-4o，仓库默认通过 OpenRouter 调 openai/gpt-4.1-mini。复现实验时，这两个不能混成一句「用了 GPT」。

跑完 66 个包，再拿 xz 对答案

跑完 66 个高优先级 GitHub 仓库，结果不是四个维度一起飘红。每一维的问题长得不太一样：

• CQ 的问题最普遍：高危只有 1.5%，但超过 80% 落在中危。门没有大开，可多数项目也谈不上很难混。
• CI 的高危最集中：39.4% 被打成高危。Dependabot 未开占 62.12%，不可信 Action 占 39.39%，未 pin 到 commit 占 31.82%。
• PC 不是小概率现象：13.6% 是高危；34.85% 的项目在测试目录里放了二进制。
• DI 反而看着温和：超过 78% 是低危。别急着读成「依赖不重要」——样本本来就是高优先级包，再在这批项目里比较下游杀伤，差异会被压扁。

单指标高危率，前几名是这些：

Community Review 这项我没完全看明白：高危率是 0.00%，论文却把它和「CQ 是最宽的攻击面」放在同一节。可能问题出在分档阈值，但正文没有展开，先别替作者补答案。

接着是 xz 回放。作者没有再讲一遍事故经过，只把已经发生的事塞回四个维度，看这些指标能不能对上：

我又对了 README 里的 tukaani-project/xz 原始输出：test 二进制为真，二进制一共 95 个，Dependabot 关闭，不可信 Action 比例 0.78；maintainer 分布里，甚至有人 0 个 PR 就进去了。和论文表里的信号能对上。