从1个投毒依赖到100个仓库：AI助手如何放大攻击

当包管理器开始引入沙箱，软件供应链是否就更安全了？本文深度解析 Homebrew 核心维护者的观点：真正危险的不只是在沙箱内执行的恶意代码，更在于沙箱产出的数据如何被外部高权限组件信任、验证与执行。

文章串联依赖投毒、AI 编程助手、CI 权限与声明式构建，揭示一次普通的安装脚本风险，如何在自动安装、自动修复、自动提交的 Agent 工作流中被放大为跨仓库的供应链攻击。欢迎结合本期解读阅读原文，理解“沙箱出口”为什么正在成为新的安全边界。

原文链接：

https://nesbitt.io/2026/09/24/package-manager-sandboxing.html

原文标题：Package Manager Sandboxing

主要内容：

• Homebrew 7.0 将联网下载与断网安装拆分，通过限制主目录、网络与缓存访问，减少安装脚本直接接触敏感资源的机会。

• 权限弹窗和 allowlist 并非充分防线：一旦用户批准生命周期脚本，它仍可能继承开发者、CI 或 AI Agent 所持有的 SSH 密钥、令牌和云凭证。

• AI 编程助手会让依赖风险规模化：更频繁的安装、更广的仓库访问和更高的自动化程度，使投毒依赖能够进入自动选择、安装、修复与提交的传播循环。

• 沙箱只能约束代码“当下能做什么”，却未必能阻止恶意构建通过 manifest、缓存、符号链接或步骤清单，诱导高权限程序在沙箱外完成危险操作。

• 更可靠的方向是减少安装期任意代码执行，以可验证、声明式的数据结构替代脚本；同时把所有沙箱输出视为不可信输入，采用严格的输出契约进行校验。

推荐理由：