3800 个仓库。通过一个 VSCode 扩展。
这不是理论上的风险，这是已经发生的事。GitHub 官方确认了这次入侵。
我们花了很多时间讨论 AI 模型的安全性——prompt injection、数据泄漏、训练数据污染。但这次攻击走了一个完全不同的路径：你的 IDE 本身就是入口。
开发者信任链条的脆弱性
VSCode 是地球上最流行的代码编辑器。它的扩展生态是开放市场——任何人都可以发布扩展，任何人都可以安装。
这意味着什么？
- 一个恶意扩展可以读取你的源代码、环境变量、SSH 密钥、API token
- 可以修改你提交的代码——在你不知道的情况下植入后门
- 可以在你的 PR 中注入微妙的逻辑错误，review 时很难发现
对于使用 AI 编码工具的开发者来说，这个风险被放大了。因为 AI 工具本身就需要广泛的代码访问权限——它要读你的 codebase、理解你的项目结构、修改你的文件。如果一个恶意扩展劫持了 AI 工具的输入或输出，你甚至不会注意到代码被篡改了。
我们过度关注了错误的攻击面
过去两年，整个行业在 AI 安全上的注意力集中在：
- 模型层面的 prompt injection
- 训练数据的版权和隐私
- API 调用的鉴权和配额
这些当然重要。但这次 GitHub 事件提醒我们：开发工具链本身的完整性才是更底层的信任基础。
如果你的 VSCode 扩展可以被植入恶意代码，那你在上面运行的任何 AI 编码工具——Claude Code、Cursor、GitHub Copilot——输出的可信度都要打个问号。因为 AI 工具读到的代码可能已经被修改了，AI 工具写的代码可能已经被替换了。
这不是反 AI 扩展的论调
我每天都在用 AI 编码工具。它们极大提高了我的效率。
但安全不是一个"要不要用"的二选一问题。而是一个"怎么用才安全"的工程问题。
几个具体的建议：
- 定期审计你安装的 VSCode 扩展——不只是刚安装的时候，而是每个月检查一次。看权限、看更新日志、看有没有异常行为。
- 敏感操作（密钥管理、生产部署）在独立环境中进行——不要在你日常 coding 的 IDE 里做这些事。
- 代码 review 不能因为是 AI 生成的就跳过——相反，AI 生成的代码更需要仔细 review，因为你不能假设它"一定是对的"。
- 关注扩展作者的信誉——star 数不是唯一指标。看更新频率、看 issue 回复、看有没有可疑的权限请求。
更大的问题
这次事件暴露了一个系统性的问题：我们在快速采用 AI 编码工具的同时，没有同步建立相应的安全实践。
这不是 GitHub 一家的问题。是整个开发者社区的问题。
当 AI 编码工具让 coding 的门槛越来越低，更多的非专业开发者会进入这个领域。他们不会知道要审计扩展、不会知道要检查权限、不会知道供应链攻击是什么。
这个行业需要一个新的安全基线——不是给安全专家的，是给每一个使用 AI 工具的普通开发者的。
否则，3800 个仓库只是开始。
主要来源：