GitHub 这次不是被一个“神秘黑客”从正门打穿。

更麻烦的地方在入口：一名开发者安装了被投毒的 VSCode 扩展，攻击者借此进入 GitHub 内部环境。GitHub 确认，约 3800 个受影响仓库目前均为 GitHub 自有代码，尚未确认客户代码泄露。

这个边界很重要。

不能把它说成“GitHub 客户仓库大规模泄露”。也不能轻飘飘归到“又一次安全事故”。真正刺眼的是：开发工具、扩展、访问令牌、自动发布，这条链子被攻击者顺着摸了一遍。

过去谈 GitHub 的信任账，焦点多在三件事：Copilot 训练争议、微软把 GitHub 收进 CoreAI、平台宕机和安全漏洞。现在补上了更硬的一块：当 GitHub 既是代码托管平台，又是 AI 训练与开发基础设施的一部分，它自己也逃不开供应链风险。

发生了什么：3800 个自有仓库，入口是投毒扩展

目前可以确认的信息并不复杂：

  • GitHub 表示，约 3800 个自有仓库受影响。
  • 入口是一名开发者安装了被投毒的 VSCode 扩展。
  • GitHub 称，目前发现范围限于自有代码，未确认客户代码泄露。
  • TeamPCP 在黑客论坛声称可访问约 4000 个 GitHub 仓库，并试图出售数据；这个数字是攻击者说法，不等于审计结论。

这几个句子已经足够说明问题。

VSCode 本身不能因此被判死刑。GitHub 客户代码也不能被直接写成已经泄露。事实要卡住边界，否则安全新闻很容易变成恐慌生意。

但边界清楚，不代表问题小。

安全公司 Socket 称，TeamPCP 在数月内发动约 20 波供应链攻击，污染超过 500 个软件项目；如果把不同版本算进去，受影响代码版本超过千个。受波及对象包括 GitHub、OpenAI、Mercor，以及欧洲委员会公共网站等。

这不是单点爆破，而是批量化投毒。

攻击路径大致是这样：污染开发工具或依赖组件，偷走 GitHub、GitLab、云厂商、包管理平台的访问令牌，再用这些令牌发布新的恶意版本，继续污染下游项目。

攻击者不一定要攻破你的公司。他只要攻破你信任的人、你信任的扩展、你信任的自动更新。

为什么重要：GitHub 的问题变成了“信任集中”的问题

如果只看一次事故，GitHub 仍然可以说：客户代码未确认受影响，自有仓库已处置，风险可控。

这话不算错。

但把它放进过去两年的 GitHub 变化里看，味道就变了。

GitHub 原来最值钱的资产，是开发者对它的默认信任。代码放上去，协作在上面做，开源项目在上面长，企业流水线也逐渐接进来。

后来 Copilot 把这份信任拿去训练 AI，争议开始出现：开源代码到底是公共知识，还是被平台重新打包成商业能力的原料？

再后来，微软把 GitHub 并入 CoreAI 相关架构，外界看到的是另一层变化：GitHub 不再只是一个相对独立的开发者社区，它正在更深地嵌入微软的 AI 产品机器。

宕机、安全漏洞、供应链攻击，本来都是技术平台难免遇到的事。问题在于，GitHub 现在承载的东西太多了。

它是代码仓库，是 CI/CD 入口，是包发布通道，是身份凭证节点，也是 AI 编程产品的训练土壤和分发渠道。

权力越集中，信任越贵。

《史记》里那句“天下熙熙，皆为利来”，放在这里不玄。平台要增长，企业要效率，开发者要省事，攻击者也要最高杠杆。最后大家都挤到同一条开发链上，谁拿到中间环节，谁就能放大收益。

SolarWinds 当年让很多人第一次看清供应链攻击的杠杆：攻击者不必逐个敲门，只要控制大家共同信任的软件更新环节。

今天的开源生态不完全一样。它更碎、更快、更自动化。一个恶意版本、一枚长期有效令牌、一个自动更新策略，可能几分钟内就被带进大量环境。

这才是 GitHub 事件的真正压力点。

谁受影响：不是普通用户，而是 DevOps 和安全负责人

普通用户不用因为这件事立刻删除 GitHub 账号。

受影响最大的，是企业 DevOps、安全负责人、开源维护者，以及所有把 GitHub 深度接进发布流程的团队。

他们要面对的不是一句“开源不可信”，而是几项很具体的成本：

  • 访问令牌要轮换，尤其是长期有效令牌。
  • 个人访问令牌要最小权限，不能一枚凭证横跨代码、CI/CD、云资源和发布权限。
  • VSCode 扩展、依赖包、构建脚本要进扫描和审批。
  • 非安全紧急更新要有冷却期，不能把“最新版”默认当成“最安全版”。
  • 谁能安装扩展、谁能发布包、谁能改流水线，要从口头信任变成制度权限。

最难的不是工具，而是习惯。

过去工程团队喜欢自动化，喜欢最新版，喜欢少审批。效率是真的。可攻击者最喜欢的，也是这套顺滑流程。

安全从来不是免费加层壳。它会让流程变慢，让发布多一道闸，让开发者少一点自由。很多公司嘴上喊安全，真到上线前卡住一个版本，马上嫌它碍事。

这次少见地把账摆到了台面上：裸奔不是敏捷，长期令牌不是效率，自动更新也不天然等于进步。

离开 GitHub 的理由变硬了，但答案不是搬家冲动

我不认为这件事能推出一个简单结论：赶紧逃离 GitHub。

更准确的判断是：把 GitHub 当成唯一可信中心的时代，该结束了。

过去有人离开 GitHub，是因为不接受 Copilot 对开源代码的训练方式；有人担心微软接管后，GitHub 的社区属性被产品目标慢慢吃掉；也有人只是受不了宕机和平台锁定。

这些理由有价值，但多少带点立场选择。

TeamPCP 这类供应链攻击把理由变硬了：风险不再停留在价值观层面，而是落到凭证、权限、扩展、流水线、发布闸门这些细节里。

问题不在 GitHub 一个产品好不好用。问题在你有没有把整个研发命脉绑在一个平台、一个账号体系、一组长期令牌上。

真正成熟的团队不会靠情绪迁移平台，也不会靠品牌信仰继续裸奔。

它会做几件笨事：关键仓库备份，多平台镜像，发布权限分层，令牌短期化，依赖更新延迟验证，扩展安装白名单，构建环境隔离。

这些事不酷，也不适合写成增长故事。

但安全就是这样。好看的架构图通常救不了命，难看的流程表反而能挡住下一次事故半径。

GitHub 仍然强。生态、工具、协作网络都在那里。离开它有成本，留下也有成本。

真正的分水岭不是“用不用 GitHub”，而是你还敢不敢把信任交给默认设置。

模型看着更强，产品看着更顺，开发链条反而更脆。AI 时代的软件工业，最怕的不是代码写得慢，而是信任给得太快。