微软的开源工具遭入侵，窃取 AI 开发者密码

原文 ↗ Hacker News 讨论 ↗

事件范围

  • 73 个与微软相关的 GitHub 仓库在被感染后被禁用（主要是 Azure Functions 和 Durable Task 工具；也包括示例、文档和一个 Homebrew tap）。
  • 这次攻击与针对软件供应链和开发者环境的 “Miasma” / “Shai-Hulud” 蠕虫家族有关。
  • 恶意软件通过 AI 编码工具和 VS Code 的配置文件传播：.claude/settings.json、.gemini/settings.json、.cursor/rules/setup.mdc、.vscode/tasks.json。
  • 多篇帖子提到 GitHub 提交的作者显示为 github-actions，这表明 CI 令牌和自动化可能已经被攻破。

蠕虫行为与影响

  • 一位研究者声称，这种蠕虫会在开发机、CI/CD 运行器和服务器之间传播，感染任何可访问的仓库；另一位则反驳说“只有你运行代码时才会传播”，随后又被更正为“只要你打开一个文件夹它就会传播”。
  • 据称的 kill switch：设置 LANG=ru_RU.KOI8-R。
  • 社区分享了一个缓解工具和技术分析；随着更多包生态系统（npm、Composer、Go、Pip、Ruby）受到影响，这些内容还在更新。
  • 有人担心这是真正跨平台、覆盖整个生态的蠕虫，并且没有现实可行的“全局关闭”选项。

微软、GitHub 与安全文化

  • 若干评论认为微软的安全文化已经出了问题，并援引最近一份美国政府的重大审查以及过往泄露事件。
  • 也有人说，就这次事件而言，微软在第一时间做对了事（禁用仓库），但批评其公开回应含糊、“水分很大”，且缺乏详细的事后复盘。
  • 还有强烈批评指向 GitHub（同属微软）：未能检测被攻破的账户/令牌、允许 CI 绕过、平台上的恶意软件管控薄弱。
  • 关于 Secure Boot 信任的争论：一些人反对被迫信任微软/OEM 密钥；另一些人指出，原则上你可以替换它们。

AI、“Agentic Development” 与供应链风险

  • 许多人认为 AI 编码代理已经成为新的高价值感染入口：它们会接触大量仓库、运行脚本，并可能被诱导批准不透明的更改。
  • 也有人认为根本问题早在 AI 之前就存在（依赖安装型恶意软件）；AI 只是放大了速度和规模。
  • 还有担忧称，如今开发者要同时处理更多项目，并以“vibe-code”方式缺乏审查地编码，这破坏了传统的 RBAC 和治理模型。

生态、工具与缓解措施

  • 很多人强烈认为“软件太多了”：微型库、深层传递依赖，以及自动运行的安装脚本（npm、pip）制造了巨大的攻击面。
  • 建议包括：
    • 严格的 SBOM 和“最小发布年龄”政策。
    • 对 npm install / pip install 进行重度沙箱隔离（Docker、无 root 容器、操作系统沙箱），甚至为每个项目单独使用用户/虚拟机。
    • 将 Web IDE / codespaces 作为隔离环境使用，但也有人反对，认为它们会引入自己的攻击面和体验痛点。
    • 为每个代理/每个仓库使用更细粒度的令牌，而不是宽泛的个人访问令牌（但也有人抱怨权限系统过于复杂，难以正确使用）。
    • 在可行时，手动编写小工具而不是增加依赖。

更广泛的情绪

  • 普遍的悲观与倦怠：有人谈到“反奇点”、“大过滤器”，以及退回到 OpenBSD / 物理隔离（airgapped）环境。
  • 许多人认为当前的安全模型（持续更新 + 巨大的依赖树）正在被自身复杂性压垮。