GitHub 内部代码库泄露与 Nx Console 供应链攻击

GitHub 报告称，一名员工的设备通过恶意 VS Code 扩展遭到入侵，攻击者随后未经授权访问了内部代码库。当时 GitHub 表示，没有证据显示内部代码库之外的客户信息受到影响，但内部代码库可能包含客户支持记录摘录等信息。调查仍在进行。

我想结合其他软件供应链事件，讨论这次扩展攻击及其对用户的风险。这些问题有关联，但并非同一起事件。我对 Microsoft 和 GitHub 的批评反映的是我对生态的看法；我不是安全研究员。

另一起 npm 事件说明，不能把单一控制措施当成完整解决方案。npm 使部分绕过双因素认证的可写细粒度 token 失效，并建议使用 trusted publishing。它可以减少对长期 token 的依赖，但遭入侵的构建流程仍可能滥用获得的身份。

这里讨论的 TanStack 攻击中，不安全的 pull_request_target 工作流与缓存投毒构成了发布恶意包的攻击链。教训是要同时保护工作流触发方式、不可信代码执行、缓存和发布权限；单纯更改触发器名称并非通用修复方案。

GitHub 内部代码库事件与这些软件包入侵有所区别。GitHub 表示，员工终端因一个被投毒的第三方扩展遭到入侵，初步评估涉及内部代码库外泄。攻击者声称约涉及 3,800 个代码库，GitHub 说这一数量与调查结果大致一致，而非经过审计的最终数字。

GitHub 表示已移除恶意扩展版本、隔离设备并轮换关键秘密，优先处理影响最大的凭据。公司继续检查日志并监测后续活动。最初公告是早期评估，不能证明所有后续风险都已解决。

我过去就批评过 VS Code 扩展市场中的恶意扩展和冒名扩展，也有人更早提出过这些担忧。扩展会在开发者的机器上执行代码，因此对发布者和更新流程的信任，与最初是否安装同样重要。

Socket 和 Aikido 等安全公司会调查恶意软件包及发布事件。我希望平台与研究人员更紧密合作，并为维护者提供有效渠道，报告和遏制遭入侵的版本。我对各家公司内部做法的评论是个人意见，并非对其运营的审计。

另一起 Nx Console 入侵事件展示了被盗凭据如何让早期供应链攻击继续扩散。攻击者向 Visual Studio Marketplace 和 Open VSX 上传了恶意扩展版本。视频后半段，Theo 读到 Nx 首席执行官的声明，确认该扩展与 GitHub 事件有关。

根据 Nx 事后报告，受影响的是 Nx Console 18.95.0。七天前，一个恶意 TanStack 软件包在贡献者的机器上运行，窃取了其 GitHub CLI token；攻击者随后在发布链中使用该 token。Nx 表示，这次扩展入侵未影响 Nx CLI、官方插件或 Nx Cloud。

恶意上传于 2026 年 5 月 18 日 12:30 UTC 登记，Visual Studio Marketplace 于 12:48 登记移除；Open VSX 于 13:09 移除。Nx 区分了从上传到移除的时间和软件包实际上架的较短时间。其事后报告详细解释了遥测数据的不确定性及应对过程。

Nx 建议，在暴露时段启用了 Nx Console 自动更新的人，将机器视为可能已遭入侵，并轮换暴露的凭据。仅移除或更新扩展不能证明机器已经安全，因为恶意代码可能已经运行或建立持久化。

如果被盗凭据没有撤销，即使最初的恶意包已经移除，它仍可能造成危险。我怀疑攻击者可能使用自动化处理被盗数据、寻找后续机会，但我没有证据证明这次具体攻击使用了智能体。实际要务是识别并撤销暴露的凭据。

自动更新带来艰难的取舍：它让用户无需等待手动操作就能获得安全修复，但发布者遭入侵时，也可能迅速分发恶意更新。我维护过一个流行浏览器扩展，这段经历让我意识到攻击者很看重现成的分发渠道。

我讨论的调查描述了 VS Code 的多种更新检查，包括启动后和与扩展市场交互时的检查，而不只是定时器。因此，即使恶意版本上架时间很短，也可能触及正在运行的编辑器；受影响人数仍需可靠遥测数据确认。

早前的 AsyncAPI 入侵也是被盗发布凭据被用来推送恶意包和编辑器扩展的例子。从注册表删除恶意版本，不一定能清除用户机器上已经安装的代码，因此遏制和用户通知不能只停留在市场下架。

我要明确，下面是建议，并非已经证明有效的完整解决方案。首先，平台可以自动检查广泛使用的软件包和扩展更新，优先处理潜在影响范围最大的版本。自动化或 AI 辅助分析仍需要人工审查，也可能漏掉恶意行为。

其次，可以考虑在新版本自动分发前设置暂存期。维护者或用户可以明确选择提前安装，而默认更新等待检查和审查窗口。这会用较慢的修复速度换取发现恶意版本的时间，因此政策需要谨慎设计。

第三，改进下架、回滚和通知流程。维护者应有明确渠道快速报告遭入侵的版本，受影响用户也需要可操作的警报。我设想了自愿启用的安装记录和受影响版本登记表，但这种系统需要权衡隐私、准确性和运营成本。

更快的发布通知、入侵报告按钮、暂存窗口，以及撤回恶意更新的方法，都可能减少损害。我强烈支持这些变化，但没有任何一项能保证防止攻击：检测可能失败，攻击者可能等待，系统也可能早已遭入侵。

视频接近尾声时，Nx 首席执行官承认 Nx Console 在事件中的作用，并表示团队正在改变发布、自动化和扩展安全措施。Nx 的事后报告还介绍了要求另一人批准发布和监控审计日志等措施。应对需要维护者与平台运营方共同改进控制。

我认为 Microsoft、GitHub 和 npm 应当对其分发系统的安全承担更多责任，而不是让开源维护者独自解决所有问题。我支持结合更严格的发布控制、审查、分阶段推出和响应机制，同时承认任何单一措施都无法消除供应链风险。

维护者的时间和资源本就有限，而遭入侵的账户或开发机器可能影响大量下游用户。生态需要切实可用的保护措施和协调一致的事件响应，让分发有用的开源软件不必依赖每个人单独防御。