今日的紧急消息，今天下午 GitHub 上出现了一个名为 openbilibili 的用户建立了一个名为 go-common 的仓库，并上传了量相当大的代码，据悉这个仓库的体积达到了 81MB，意味着这次泄露泄出的代码量是巨大的。
这次的代码泄露将严重危害到 B 站的安全，因为如果它确实是 golang 后端的所有代码，那么其中将含有大量内部的配置信息、用户信息，黑客也可以通过源码审计对 B 站进行渗透。
截止笔者写稿，B 站官方对此事做出了回应：
虽然 B 站官方的公告称泄露出的代码是「较老版本」，且为「部分工程代码」，但很显然这次泄露的代码是后端部分的一个大仓库，代码覆盖了 B 站的相当多业务，且这一仓库的代码实际上也并不老，因为代码中可以找到 2019 年拜年祭的相关内容，这意味着这一套代码的真实泄露日期距今不会超过 2 个月。
GitHub 目前是屏蔽了该搜索关键字并对涉事的仓库进行了处理，但由于 GitHub 本身是开放的，同时 Git 又提供了非常方便的 Clone、Fork 操作，以至于现在光是在 GitHub 上还能找到该仓库的各种副本，至于其他的私有仓库、私人服务器等就更别说了。
泄露源码的传播目前已经难以阻止，B 站现在要做的更多是查清泄露源头，并且防止黑客利用这套泄露的代码找到 B 站服务器的薄弱点并对服务器进行攻击。
这一次泄露的代码具体是 B 站基于自有 golang 微服务框架开发的一整套后端服务，目前没有人能确认这些代码在 B 站后端所有 golang 代码中到底占了多大的比重。
虽然这次泄露的是后端代码，但笔者看来这份泄露代码能够引起广泛黑客攻击的可能性不大，首先在 B 站这样的企业里，开发环境、测试环境、生产环境肯定都是有隔离的，内外网之间都做好了隔断。
笔者通过搜索引擎检索到了 B 站主站技术经理在一次沪江技术沙龙上对关于 B 高性能微服务架构做的一些说明，在这一套新的架构中内外网是完全隔离的，同时部署也是隔离的。
在这种情况下，即使我们拿到了 B 站后端的源码也很难对 B 站产生威胁，因为现实中在这一架构上根本不存在外网直通 B 站内网的通道，后端并不会直接将 API 等暴露给前端，二者中间还隔着非常多层的中间件、缓存。
根据这次技术沙龙中 B 站主站技术经理给出的描述，在这一套架构中理论上是不存在任何一个能够直接打到数据库的请求，对外的多层缓存一方面能够提升效率，另一方面它也能保护 B 站的核心服务。
至于有的网友表示基于这一套泄露代码，技术大牛或者其他公司能不能够重构一个 B 站出来。答案是不行，这一套代码仅仅只是 B 站总体偌大架构中的一小部分，即使你拿到了这一部分的后端程序，没有与之对接的前端、中间件，重构一个 B 站是完全不可能的，而且这个后端代码的部署对不少人来说都是难题。
这次的代码泄露更多的是会将 B 站在运营上的一些内部细节暴露到公众视野里，例如很多人关心的直播人气值是怎么计算的、UP 主的视频播放量硬币量等是不是存在水分这样的问题。
由于各方面的数值最终都是要存到数据库里的，存取都要和后端挂钩，所以很多 B 站在运营方面的不少细节或者说小秘密会通过这些代码暴露出来。据悉此前「吴织亚切大忽悠」这个主播的相关事件在代码中甚至都有体现。
这一次的代码泄露是 B 站在管理上存在重大疏忽引起的。起初有网友认为代码可能是 B 站员工(可能为实习生)因错误使用 Git 上传到 GitHub 的，但考虑到所有的泄露代码都来自于 openbilibili 这样一个小号，所以这一次的代码泄露更有可能是一次「故意泄露」。
有的截图指出这些泄露代码来源于 John-L-Smith 这样一个 GitHub 账号，但是实际上这是 GitHub 的一个小 Bug，这些代码实际上来源于root，而这个信息被 GitHub 错误地只想到了 John-L-Smith 这个账号。
root@vultr.guest 是一个匿名的帐号，看起来泄露源码的人应该是随手开了一台境外的服务器扒下了整个仓库的代码然后将其放到 GitHub 上的，这一套操作有刻意避免追查的痕迹，这使这一次的代码泄露看起来更像是有人故意为之。
不管怎么说，这一次 B 站都需要对这次事件做深刻的反省，毕竟 B 站现在已经是一家上市公司了，公司源代码被这么随意的大量公开意味着公司内部对员工、对网络的管理都存在很大的问题。
受此事影响，B 站股票盘前大跌，开盘后有所回升。
