--- service: "Publicasta" schema_version: "1.0" article_id: 369 title: "Rust arrayref 事件提醒开源社区重新审视构建时信任" language: "zh" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=zh" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=zh" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=zh" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-21T06:48:09+00:00" updated_at: "2026-08-21T06:48:09+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=de" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=de" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=en" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=en" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=es" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=es" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/rust_arrayref_supply_chain_attack_cargo_build_scripts_2026.json?lang=zh" --- # Rust arrayref 事件提醒开源社区重新审视构建时信任 > 恶意 arrayref 版本上线不到两小时，却暴露了更深层的问题：包管理器常常在团队决定信任程度之前，就在构建阶段执行依赖代码。 Rust `arrayref` 供应链攻击持续时间很短、范围也有限，但仍然重要。根据 Rust Security Response Team，与 `arrayref`、`internment`、`append-only-vec` 相关的恶意版本在 crates.io 上分别存在约 86、90、107 分钟后被移除。Rust 官方博客还说明，目前不认为 `arrayref` 的合法 maintainer 有恶意；更可能是机器或 credentials 被攻破。快速响应本身是好消息。 ![开源依赖图和 CI 构建流水线中的可疑包节点](https://publicasta.com/storage/projects/10/pages/369/2026/08/8ceaa39d-9547-4785-b052-4a0bab519bd7.webp) 但这不是全部。这个事件值得 Open Source Radar 关注，因为它触到了现代 package managers 的核心问题：构建依赖时，哪些代码可以运行？在哪里运行？带着什么权限和凭据运行？Rust 不是 npm，crates.io 也不是混乱生态。但一个小而旧、平时没人注意的 dependency 仍然能成为 build-time execution path。 `arrayref` 不是热门框架。它的文档描述的是四个用于 array/slice 引用的 macros。正因为如此，案例才重要。供应链风险不一定来自醒目的新库，也可能来自多年安静存在于 transitive dependency graph 里的 tiny utility。 ## 发生了什么 Rust blog 称，2026 年 8 月 20 日，团队验证了关于恶意 `proc-macro1` 的报告。`arrayref@0.3.10` 在 07:15 UTC 发布，08:41:40 删除；`internment@0.8.7` 在线时间为 07:34:07 到 09:04:11；`append-only-vec@0.1.9` 为 07:37:49 到 09:25:24。 团队还删除了 attacker-owned crates：`proc-macro1`、`proc-macro-en`、`aovine`、`arone`、`aronenao`、`tinymember`。被恶意 yanked 的合法版本被恢复，受影响账号被锁定。GitHub Advisory Database 发布 GHSA-jwh4-228v-r358，确认 `arrayref = 0.3.10` 为 malicious code，且没有 patched version。 技术手法并不复杂。SafeDep 等分析称，`arrayref@0.3.10` 新增了 typosquatted `proc-macro1` 依赖，这个名字很容易与合法 `proc-macro2` 混淆。恶意 crate reportedly copied genuine `proc-macro2` source，让 build 看起来正常，同时 build script 被执行。 关键是 build script。Cargo build scripts 有正当用途：native libraries、code generation、platform detection、configuration。但这也意味着 dependency 可以在 build time 执行代码。如果它运行在带有 tokens、SSH keys、cloud credentials 或 package publishing rights 的开发机或 CI runner 上，即使暴露窗口很短也值得重视。 ## 为什么两小时以内仍然重要 现代 CI 很快、自动化程度高，而且经常有 secrets。一次 dependency update、scheduled build、`cargo update`、container image rebuild 或 bot-managed version bump，都可能在窗口期运行代码。 报告还指出，旧版 `arrayref` 被 yanked，这可能让 malicious version 看起来像自然更新路径。也就是说，package metadata 和 registry behavior 本身就是 attack surface 的一部分。 谨慎结论是：不是所有使用 `arrayref` 的项目都被 compromised。但任何在窗口期构建 affected versions 的系统，都应在检查 logs、artifacts 和 credentials 前视为 potentially exposed。 ## Rust 做对了什么 响应快速且公开：删除恶意 crates、恢复合法版本、公布 timeline 和 affected versions、给出本地 cargo cache 检查方式、协调 RustSec 与 GitHub advisories、锁定账号，并避免在证据不足时指责合法 maintainer。 这对 open source 很重要。incident 不可避免；response quality 决定信任能否修复。registry 需要 takedown、yanking、security response path、public advisories，以及区分 maintainer compromise 与 maintainer malice 的清晰措辞。 Rust community 的讨论也很有价值。Hacker News 很快转向系统设计：sandboxing build scripts、build-script allowlists、registry anomaly detection、lockfile discipline、dependency culture、containerized development，以及是否应避免不必要 microcrates。 ## Cargo 的难题 Build scripts 不是错误。npm 有 `postinstall`，Python 有 build backends，native packages 有 configure scripts，Rust 有 `build.rs`。开源生态长期选择 convenience、portability 和 automation。攻击者看到的是：build systems often run earlier and with more privilege than teams realize。 问题不是是否允许 build scripts，而是每个新建或变化的 build script 是否应默认拥有完整访问权。一个多年无需 build-time code 的小 dependency，可以突然加入 build dependency。一个 crate 可以拉入 typosquatted package。build script 可以访问网络、读取 environment、触碰文件，而开发者常常没有清晰的 trust prompt。 Cargo 的 “Build script allowlist mode” issue 和 sandboxed build scripts project goal 表明社区早已意识到问题。arrayref 事件让它更紧迫。未来可能需要 layered defense：registry signals、allowlists、sandboxed build execution、dependency diffs that highlight new build scripts、CI network-deny modes，以及对 yanking 和 ownership changes 的更强审查。 ## 现在应该检查什么 Rust teams 应检查 `Cargo.lock`、vendored dependencies、container build logs、artifact provenance 和 CI caches 中是否出现 `arrayref@0.3.10`、`internment@0.8.7`、`append-only-vec@0.1.9`，以及 advisory 中列出的 deleted attacker-owned crates。local cargo caches 也重要，因为 crate 可在 registry takedown 后继续存在。 然后检查 2026 年 8 月 20 日相关窗口内运行过的 CI jobs、self-hosted runners、developer workstations、release builders 和 image rebuilds。如果 affected build 接触过 secrets、package tokens、cloud credentials、signing keys 或 SSH material，应轮换可能暴露的凭据。 还要审查 build jobs 的 network egress。很多 build 在 dependencies fetched 后不需要广泛外网访问。ephemeral runners、egress policies、isolated containers 和 short-lived credentials 都能降低 build-time payload 的价值。 工具有用但有限。`cargo audit` 和 advisory databases 在恶意包被发现后有帮助；`cargo deny` 可执行 policy；`cargo vet` 可记录 human trust decisions；供应链 scanners 可更早发现可疑行为。但没有一个能替代 sandbox。 ## Maintainers 和 registries 的教训 Maintainers 应强化 publishing accounts：strong authentication、scoped tokens、least privilege、separate release machines，并监控 unexpected yanks、owner changes 和 releases。一个小 utility crate 如果被足够多项目 transitively 依赖，也可能是 critical infrastructure。 Registries 应把异常 lifecycle changes 当作 signals：多年安静的 crate 突然加入 build script、typosquatted dependency、suspicious yanking、network-reaching build behavior，都值得 friction。friction 不一定是阻止发布，也可以是 warnings、delayed propagation、maintainer confirmation、automated scanning 或更强 UI indicators。 Tool authors 也有机会：dependency diffs 不应只显示 source changes，还要显示 trust changes：new build scripts、proc macros、owners、native code、outbound network、yanked predecessors、模仿常见包名的新依赖。 ## 不只是 Rust 与 npm postinstall attacks、PyPI typosquatting 和其他 registry compromises 对比是合理的，只要不变成 language tribalism。Rust 有 strong type safety 和严肃安全文化，但这些并不能消除 registry compromise、maintainer credential theft、malicious build scripts 或 package-name social engineering。 更广泛的开源教训是：source code review 已经不够。关键是 code when executes。只出现在 lockfile 的 dependency 与在应用启动前运行 build script 的 dependency，不是同一风险。运行在持有 release tokens 的 CI runner 上，则更加敏感。 ## 值得尝试的做法 项目层面：认真 review `Cargo.lock`，使用 ephemeral runners，把 long-lived secrets 移出普通 build jobs，依赖下载后限制网络，记录哪些 crates 有 build scripts、哪些被批准运行。 关键软件可以尝试 `cargo vet`、`cargo deny`、RustSec/GitHub alerts，以及能观察 build-time behavior 的 scanners。Platform teams 应把 build isolation 放进路线图：containers 只是起点，microVMs、short-lived credentials、secretless build stages、isolated builds 后再 signing、egress monitoring 都能降低风险。 Open Source Radar 的信号很清楚：这不只是一个 crate 被攻破，而是对 registries、lockfiles、advisories、CI 和 package managers 的压力测试。Reuse 仍然是 open source 的强项，但它需要把 build-time code 当作真正代码的 trust model。