Rust 生态 arrayref 供应链事件怎么排查：受影响依赖、锁文件核对与替换策略

Rust 官方披露的 arrayref 供应链事件，重点不在于“看到一个 crate 被撤下就立刻删库”，而在于确认项目是否真正拉取过受影响版本，再决定锁定、替换和清理范围。受影响清单包括 arrayref@0.3.10、internment@0.8.7、append-only-vec@0.1.9，以及被删除的 proc-macro1 等 crate；排查应同时覆盖 Cargo.lock、本地 Cargo 缓存和 CI 构建记录。

Rust 官方披露了哪些事实

2026 年 8 月 20 日，Rust 安全响应团队说明，proc-macro1 包含会下载恶意载荷的构建脚本；随后发现 arrayref 被重新发布并依赖该 crate。官方列出的受影响版本有明确时间窗口：arrayref@0.3.10 在线约 86 分钟，internment@0.8.7 约 90 分钟，append-only-vec@0.1.9 约 107 分钟。文章只据此判断核查范围，不把“曾经在线”推断成每个项目都已受影响。

官方同步说明，相关恶意版本已经从 crates.io 下架，同时提醒所有 Rust 项目开发者核查本地依赖。作为项目维护者，第一步先留存好当前的锁文件和 CI 运行日志，别着急清环境把最核心的排查证据一并删掉。

先从 Cargo.lock 找到真实依赖路径

在仓库根目录执行依赖树查询，分别看直接依赖和传递依赖。不要只搜索 Cargo.toml，因为风险包很可能来自另一个库的构建依赖。

cargo tree -i arrayref@0.3.10
cargo tree -i internment@0.8.7
cargo tree -i append-only-vec@0.1.9
rg -n 'name = "(arrayref|internment|append-only-vec|proc-macro1)"|version =' Cargo.lock

如果 cargo tree 返回没有匹配项，但 Cargo.lock 里仍出现过旧版本，先确认当前分支和 lockfile 是否一致。发布分支、构建分支、打包分支可能各自带着不同的锁文件，不能拿开发机结果替代 CI 结果。

再检查 Cargo 缓存与构建证据

Rust 官方给出的缓存排查思路很直接：检查 ~/.cargo/registry/cache 是否存在精确文件。企业环境里建议把输出保存到受控的事件目录，并把工作区、镜像构建机和 CI runner 分开记录。

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

缓存命中不代表恶意构建脚本一定被执行过，但只要命中就必须先做隔离：临时停用对应构建节点，留存好相关文件哈希、构建时间、作业编号，再交给安全团队评估要不要扩大取证范围。如果 CI 日志里出现异常外网请求、构建脚本擅自下载资源，或者出现不属于项目的陌生产物，不要在没有实据的情况下直接认定是项目内部开发者操作导致。

替换与复查要分成两个提交

先让依赖解析离开受影响版本

确认命中后，先在干净工作区更新或替换上游依赖，再检查 Cargo.lock 的 diff。不要手工删掉 lockfile 中的一段文本；依赖图需要由 Cargo 重新解析，并通过测试确认没有引入另一条同名或相近版本路径。

cargo update
cargo tree -d
cargo test --locked

如果上游官方还没放出修复后的可用版本，临时处置方案优先选经过团队审计的 fork 分支或者内部私有镜像，同时把替换包的来源、提交哈希、后续回滚的触发条件都明确写在变更记录里。只改依赖声明里的版本号、不校验对应构建脚本的行为，不算是完成了漏洞替换。

再在清理提交中处理缓存和产物

依赖替换的全流程校验通过之后，再清理构建节点缓存、本地构建文件夹和内部制品库里的对应恶意包。把「项目已经完全移除风险依赖」和「风险相关旧证据已完整留存」两个动作分开做，后续做安全审计的时候也更容易溯源复盘。

常见问题

只搜 Cargo.toml 没搜到 arrayref，还需要继续查吗？

需要。它可能是传递依赖或构建依赖，应以 Cargo.lock、cargo tree 和 CI 实际使用的锁文件为准。

本地缓存里有 crate 文件，是否说明机器已经中招？

不要直接下定论。缓存记录只能证明对应包曾经被下载或留存过，恶意构建脚本有没有实际运行，还要结合构建日志、网络访问记录和产物生成时间线交叉核对才能确认。

更新 Cargo.lock 后为什么还要跑干净 CI？

因为旧的构建节点很可能复用了之前的风险缓存内容。用完全清空过旧缓存的全新构建节点重新跑一遍全量构建，才能确认新锁文件和替换后的依赖源确实已经正常生效。

把一次事件变成依赖验收规则

这次供应链事件的处置流程可以沉淀成通用的 Rust 包安全检查规范：把锁文件纳入代码评审范围，构建阶段用到的依赖单独列明，CI 侧针对缓存和网络访问保留最基础的审计记录，后续再遇到恶意包通报的时候，按照「核对精确版本→梳理全量依赖路径→留存构建相关证据→替换后多轮复查」的顺序处理，既不会看到安全通报就盲目全量重装所有开发环境，也不会漏掉传递依赖悄悄引入的实际风险。