GitHub的员工装了一个坏插件，结果公司内部三千八百个代码库被人偷走了。这事儿就发生在昨天，GitHub自己发推特说的。他们发现得还算快，赶紧把那员工的电脑隔离了，把坏插件删掉，然后整晚都在换各种密码和钥匙。最重要的结论是：你写代码用的那些小工具，可能是最危险的突破口，连GitHub这种全世界最大的代码托管平台都没扛住。
员工装了个什么插件
事情的起点特别普通。GitHub有一个员工，跟我们一样，平时用VS Code写代码。VS Code是微软出的一个免费编辑器，全世界几百万开发者在用。这个员工想给自己的编辑器加个功能，就去VS Code的官方扩展市场装了一个插件。扩展市场就像手机的应用商店，你点一下安装就能用。
问题就在于，这个插件被人动过手脚了。攻击者提前把一个恶意程序塞进了这个插件里，然后发布到了官方的扩展市场。GitHub的员工装上之后，恶意程序就开始在他电脑里偷偷干活。它能读取这个员工在VS Code里打开的所有代码，还能把这些代码悄悄传到攻击者的服务器上。
这就像你从官方应用商店下了一个手电筒App，结果这个手电筒不光能发光，还能偷偷看你手机里的照片并发走。VS Code的扩展市场虽然由微软管理，但里面混进了坏东西。很多开发者对扩展市场的信任度太高了，觉得官方市场里的东西应该都是安全的，但事实根本不是这样。
恶意插件能干什么
这个恶意插件一旦装上，权限大得吓人。VS Code的扩展程序能读取你电脑上打开的所有文件，能访问你的终端命令行，还能在你的电脑上执行各种命令。对于开发者来说，这就等于把整台电脑的钥匙都交给了这个插件。
具体到GitHub这个员工，他的VS Code里肯定打开了不少公司的内部代码库。恶意插件就蹲在后台，等员工打开一个项目，它就扫描一遍，把代码文件打包压缩，然后找个网络连接偷偷发出去。整个过程员工完全感觉不到，VS Code该高亮代码还是高亮，该自动补全还是补全，一切看起来都很正常。
攻击者最终声称偷走了大概三千八百个代码库。这数量听着挺大，但GitHub说这只是他们内部仓库的一部分，不是全部。对于攻击者来说，这已经是一笔巨大的收获了。这些内部代码包含了GitHub自己的系统是怎么搭建的，安全措施是怎么设计的，甚至可能包含一些还没公开的功能和密钥信息。
GitHub怎么发现的
GitHub没说具体的检测细节，但通常这种恶意行为会露出马脚。比如员工的电脑突然往外发了大量数据，网络流量异常；或者安全软件扫描到了可疑的进程行为；也有可能是其他同事发现了奇怪的事情然后报告了。
不管怎么样，GitHub在当天就检测到了这个入侵事件。他们的反应速度确实很快：第一时间把那台员工的电脑隔离起来，不让它再连接公司内部网络；然后把那个恶意的VS Code扩展从员工的电脑上移除；紧接着启动了正式的安全事件响应流程。
一个关键动作是连夜轮换了大量的密钥。密钥就像各种系统的密码，如果攻击者已经偷走了部分密钥，那GitHub必须马上把这些密钥作废，换成新的。他们优先换掉了那些影响最大的凭证，也就是如果被攻击者拿到会造成最严重后果的那些。这就像你发现家里可能进了小偷，第一时间先把保险柜的密码改了。
为什么这事儿很严重
这次事件最吓人的地方不在于GitHub被偷了多少代码，而在于攻击的方式。攻击者没有直接去黑GitHub的服务器，没有用暴力破解密码，也没有找系统漏洞。他们只是在一个员工常用的工具里下了毒，然后等着员工自己把毒装进电脑。
这叫做供应链攻击。你不是去攻破目标本身，而是去攻破目标信任的东西。开发者信任VS Code的扩展市场，就像普通人信任手机应用商店。一旦这个信任被利用，整个防线就形同虚设。
而且开发者的电脑本身就握着大量敏感信息。一个后端工程师的VS Code里可能打开着数据库密码、云服务的API密钥、内部系统的地址和认证方式。如果恶意插件把这些都偷走了，攻击者就等于拿到了进入公司内部的通行证。
更麻烦的是，这种攻击很难防范。你不可能让所有员工都不装任何扩展，那工作效率就没法保证了。但你又没法保证扩展市场里的每个插件都是干净的。微软虽然会做一定的审核，但审核不可能百分之百覆盖所有情况。特别是那些功能复杂、更新频繁的插件，审核难度更大。
大家最关心的问题
事件公开之后，开发者社区炸了锅。所有人第一个问的都是同一个问题：到底是哪个扩展？你能不能告诉我名字，我好去查查自己有没有装？
GitHub到现在还没公布具体的扩展名称。这可能有几个原因。调查还在进行中，他们需要先搞清楚这个恶意扩展到底是怎么运作的，背后是谁在操作。直接公开名称可能会打草惊蛇，让攻击者销毁证据或者改变策略。另外，如果这个扩展已经被很多人装了，公开名称可能会引发恐慌，但GitHub应该会先通知那些受影响的用户。
还有一个关键问题：客户的代码有没有被泄露？GitHub目前的说法是，这次只涉及内部代码库，没有证据显示客户的代码或者客户的敏感数据被偷了。这是个好消息，但大家还是会担心。因为就算客户的代码没丢，GitHub内部系统的代码丢了也是很严重的事情。内部代码里可能包含安全漏洞的细节、访问控制的逻辑、甚至一些还没修复的问题。
对其他开发者的警示
这次事件给所有开发者敲了个警钟。你可能觉得自己又不是GitHub，不会有人专门来黑你。但攻击者不在乎你是大公司还是小团队，他们在乎的是能不能通过你跳板到更有价值的目标。
如果你是一个自由开发者，电脑里可能存着好几个客户的项目的密钥。如果你在一家公司上班，电脑里可能存着公司的各种内部系统信息。一旦你的开发环境被攻破，攻击者就能顺藤摸瓜拿到更多东西。
一个很实际的建议是：别装你用不到的扩展。很多人装了十几个甚至几十个VS Code扩展，但一半以上平时根本不用。每多装一个扩展，就多一个被攻击的可能。装之前看看这个扩展有多少下载量，看评论有没有人提到安全问题，看看开发者是不是可信的机构。
另外，敏感信息千万别硬编码在代码里。数据库密码、API密钥这些东西应该用环境变量或者专门的密钥管理服务来存。就算你的代码被偷走了，这些密钥也不会跟着一起被偷。而且密钥要定期换，GitHub这次连夜换密钥就是标准的做法。
VS Code扩展市场的问题
VS Code扩展市场的安全问题其实早就被人吐槽过无数次了。在推特上有人翻出去年的一条帖子，说"你们能不能修一下VS Code扩展市场里恶意软件传播的问题，我每周都得给你们发邮件，烦死了"。
这个市场最大的问题是审核机制太弱。虽然微软会扫描一下扩展有没有明显的病毒特征，但稍微用心一点的攻击者完全可以绕过这种基础扫描。而且扩展更新的时候，审核可能更宽松。攻击者可以先发布一个干净的版本，等积累了一定用户之后，再通过更新推送恶意代码。
还有一个问题是权限控制太粗。一个扩展申请了读取文件的权限，它就能读所有文件，没有更细粒度的限制。理想的情况下，应该让用户选择这个扩展只能访问哪些文件夹，或者只能访问哪些类型的文件。但这种机制目前基本没有。
有些安全公司已经开始做针对性的防护工具了。比如有些工具可以监控VS Code扩展的网络请求，发现有异常的往外发数据就报警。还有些工具会分析扩展的代码，看它有没有可疑的行为模式。但这些都属于事后的补救措施，最好的办法还是在源头把恶意扩展挡在门外。
微软和GitHub的责任
微软这次的角色很尴尬。VS Code是微软的产品，扩展市场是微软在运营，GitHub现在也是微软旗下的公司。等于说微软自己的开发工具被攻破了，然后这个漏洞被用来攻击了微软自己收购的公司。
有人调侃说这是"双倍黑客"，先黑VS Code的开发者账号或者扩展，再用这个去黑GitHub。还有人讽刺说"微软在多个层面上造成了这种情况"。确实，如果VS Code扩展市场的安全措施更强一些，或者GitHub内部的开发环境对扩展的管控更严格一些，这次事件可能就不会发生。
不过GitHub的响应速度还是值得肯定的。从发现问题到公开声明，再到轮换密钥，整个流程在24小时内完成。很多公司碰到这种事会先藏着掖着，等调查完了再说，但GitHub选择了快速公开。虽然公开的信息还不够详细，但至少让外界知道了发生了什么，而不是让谣言满天飞。
接下来会发生什么
GitHub说调查结束后会发布更详细的报告。到时候我们应该能知道更多细节：到底是哪个扩展，攻击者是怎么把它发布到市场上的，攻击持续了多久，有没有其他员工也被影响了。
对于开发者来说，现在能做的几件事很简单。检查一下自己VS Code里装的所有扩展，把那些不用的或者不记得为什么装的统统删掉。看看有没有下载量很少、最近刚发布、或者突然更新的扩展，这些可疑度比较高。如果你公司的安全团队有要求，配合他们做一次安全检查。
长期来看，整个行业可能需要重新思考开发工具的安全模型。VS Code扩展的权限可能需要重新设计，扩展市场的审核机制需要加强，公司的开发环境需要对员工装的扩展做更严格的控制。甚至可能需要一些自动化的工具来实时监控扩展的行为。
这次事件再次证明了一个老道理：安全链条的强度取决于最弱的一环。而那个最弱的一环，往往不是服务器上的防火墙，不是复杂的加密算法，而是坐在电脑前敲键盘的那个人，和他随手装的那个小插件。连GitHub都翻车了，你觉得你的代码能有多安全？