GitHub 密钥被扫走6万个仓库，接单团队踩坑在CI配置

十一月十号中午十二点四十五分之后，GitHub 上出现了一批奇怪的拉取请求，标题都叫依赖审计笔记。点进去只有一个分支和一两个提交，看起来像例行维护。真正的动作在提交里，一段大约 1500 行的脚本被塞进工作流，跑完就把仓库能碰到的密钥、云凭证、模型服务令牌打包发走，然后把运行记录删掉，仓库里只留一个缺失的编号，脚本在仓库里只停留一分钟，回滚得很快，快到没人看见。

安全公司 Aikido 的统计把规模摆出来。4837 个被盗账号向 61764 个仓库开了探测请求，其中 10431 个请求进的是账号自己并不拥有的仓库，靠的是协作者或组织权限。至少 1835 个仓库真的跑了那段脚本，凭证被带出去。92% 的探测请求还开着，说明大多数仓库主人根本没注意到，而攻击者的痕迹早被自己擦干净了，多数人是在事后才发现异常，报告给出的建议是先自查再轮换，别等对方开口，通知客户比瞒着强。

脚本的写法不复杂，也不加密，注释写得清清楚楚，四个阶段，收集、提权、驻留、外传。它翻环境变量、翻常见的凭证路径、翻密钥文件和集群配置，连 Cursor、Copilot、Claude 这些工具的令牌都在清单里。拿到云凭证之后再换角色，AWS 里直接建长期访问密钥，Azure 里加联合身份，代码托管平台的分支保护用伪造的状态检查绕过去，合并的门就这样被推开，权限一旦漏出去，补起来很慢，尤其在多人协作的项目里。

更麻烦的是痕迹。脚本跑完会回滚，把工作流运行记录删掉，仓库里只留下一个缺失的运行编号。也就是说，没看到可疑产物，不等于数据没被拿走。这条链路还通过自动发布触发进了包仓库，Packagist 上的 neuronai-studio 3.14.3 和两个 Go 模块版本都被点名，装过这些包的人要按已被入侵处理，不能只看日志，工作流里跑过什么，要靠运行编号和提交时间倒推，这一步不难，但要有人盯，晚一步就多一个受害者。

接单团队最容易中招的地方在于权限给得太松。外包开发、临时协作者、自动化发布，账号一旦被拿走，写权限就是通行证。平时图省事，令牌放在工作流里，云角色信任范围写得宽，出事时一个仓库能牵出整个账号下的所有密钥。这种事故的修复成本，比多做一次权限梳理高得多，客户的数据也跟着暴露，一个项目的疏漏会顺着协作关系传到下一个，合同里该写的责任也要写清。

能做的动作并不玄。先把十一号之后的所有拉取请求过一遍，看到依赖审计笔记这种标题就查分支和提交；再把工作流里的密钥换成短期凭证，云角色加上来源限制；然后把自动发布的口子收紧，别让一个包的发布权限连着主账号。安全厂商的免费套餐能扫出恶意包，开源工具能在安装前拦一道，成本都不高。确认被拿过的仓库，密钥要全部轮换，只删脚本没有用，这一步不做等于没修。

创业找资源，上乌鸦部落。