📰 来源: 博客园
（使用AI整理内容并编排格式）
近期 Axios、Apifox、LiteLLM 等事件集中爆发，暴露了一个深层问题：我们以为信任的是开源代码，实际上信任的是平台和开发者。TEE 技术或许能打破这个困局。
从“病毒式传播”看供应链投毒的本质
2026 年开春以来，供应链攻击几乎以“周更”的速度冲击开发者社区：
.pth 文件持久化。仔细看这些事件，它们不是孤立的。攻击具有明显的“病毒式传播”特征：
根本问题不是某个漏洞，而是整个信任模型的错位。
我们真正信任的是什么？
社区常说“开源代码经得起社区审查，所以值得信任”。但现实是：
这种信任在单点被突破后就会彻底崩塌。我们需要一种不依赖平台和开发者诚信的验证方式。
整体思路：TEE 作为“可信构建锚点”
可信执行环境（TEE），尤其是云端的 VM 级 TEE（Intel TDX / AMD SEV‑SNP），提供了一种硬件隔离的“安全黑盒”：
- 构建产物的哈希（如 tarball、二进制文件）
- 源代码仓库的 commit 哈希
- 构建环境指纹（OS、编译器、依赖版本等，如 docker 的 digest 信息）
✅ LiteLLM（CI 令牌泄露 → 发布后门）
TEE 能完全阻止：CI 构建运行在 TEE 内，发布令牌只对特定度量的 TEE 释放。攻击者即使控制宿主机，也无法窃取令牌或篡改构建产物。
✅ Axios（NPM 账户被盗 → 发布恶意包）
TEE 能阻止：NPM 要求附带 attestation。攻击者可以发布，但无法生成合法证明（因为源码仓库未被篡改）。客户端拒绝安装无证明的包。
⚠️ Apifox（闭源 Electron，CDN 篡改）
TEE 部分有效：如果官方使用 TEE 构建并签名，客户端可验证签名防止 CDN 篡改。但闭源意味着用户无法独立验证“源码是否恶意”，以及无法防御官方的密钥泄露，最终仍需信任官方。TEE 不能解决闭源软件的“作恶”问题。但是至少可以防止代码在构建、分发的流程中受到攻击。
❌ XZ Utils（社会工程学植入源码后门）
TEE 无能为力：后门在源代码中，TEE 会忠实地将其构建进产物并出具合法证明。要防御此类攻击，需要更强的代码审查流程。
供应链投毒的“病毒式传播”之所以可怕，是因为攻击者一旦突破一个信任点（密钥、CI、平台），就能快速扩散。TEE 将信任从“人+平台”迁移到“硬件+公开代码”，切断了这种传播链。
它不能替代代码审查，也不能解决社会工程学。但至少，当我们说“这个包来自开源代码”时，TEE 能让我们真正验证这一点，而不是仅仅相信某个平台上的某个开发者。
🔗 原文链接: 点击阅读原文
文章评论