源码安全：悬在大厂头上的达摩克利斯之剑

“ Please help us！！！”

从 B 站源码泄露开始到 GitHub 最终删除代码的两小时，大概是今年 B 站最煎熬的时刻，以至于他在向 Github 求助删除的 DMCA 邮件中，在 Please help us 后写下了三个醒目的感叹号。

注：DMCA 即数字千年版权法（Digital Millennium Copyright Act），是美国制定的一项旨在保护版权的法律。它包括禁止分发受版权保护的材料和规避版权保护监管的规定。

B 站代码泄漏虽然不是国内第一次代码泄漏事件，却是第一次因代码泄漏上热搜的话题。

去年在阿里云的代码托管平台上，也发生了企业代码泄漏事件。由于界面上的功能歧义，上百家企业在创建项目的时候误选择 “internal” ，将企业项目代码进行了“平台公开”。同年八月份华住集团旗下酒店 5 亿条公民个人信息被曝泄露。针对此次泄漏的原因，相关科技组织分析是由于一位程序员（疑似华住程序员）曾在 GitHub 上传了一个名为CMS 项目，项目的配置文件代码里包含了华住敏感的服务器及数据库信息，被黑客利用攻击导致泄露。

除了上述情况之外，一些新入门的同学还没有意识到源代码属于商业机密，将公司代码拷贝到个人电脑后，出于共享学习的心态传到了公共平台；或者是离职的同学在离开公司时没有带走一片云彩，却带走了源代码。总之，企业核心源代码被“开源”的现象屡见不鲜。

GitHub 2017~2018 年的 DMCA 删除通知数量

不少企业都有自己的代码防泄漏机制，比如核心代码权限控制、内外网隔离、保密协议等等措施，但代码泄漏的现象依然在发生。而且影响严重的代码泄漏事件不少都是由第三方发现的，等企业着手处理时已造成不少损失。接下来我们要探讨的就是如何把代码泄漏的危害降到最低，我们列出常见的实践，以及在主流代码托管平台上发现侵权的仓库后可以怎么做，以供读者参考。

01 注重编程规范 对于企业来说，除了保障业务快速交付外，信息安全也是重中之重。特别是在信息及其敏感的行业，例如金融、公安、通讯、军工等。不少公司都有非常严格的编程规范，例如：

1. 不允许将敏感信息硬编码在代码中，敏感信息通常包括用户账户、密码、电话号码、数据库密码、服务器远程登录密码等等。如果确实需要在代码里的配置文件当中存储敏感信息，建议也不要明文存储。
2. 当代码涉及到加解密算法时，密钥不允许全部硬编码在代码中。同时加解密算法要选择强度足够的、业界认可的算法，密钥也要支持定期更换。

类似上述的编码规范可通过源码安全扫描工具对版本进行增量扫描，避免人工检视的低效率。有一些团队不愿意花时间在这些并不直接或者并不立即产生价值的事务上，但我们建议在安全和进度之间，研发团队需要找到一个平衡。

02

建立监控机制

越早发现泄漏代码，越容易控制源代码传播范围。通过定时扫描代码托管网站上的新增公开项目，查看是否存在可能涉及本公司项目源码的仓库。如何通过自动化扫描监控公开项目有如下几种方式：

• 现有的关键字扫描开源工具，市面上提供了不少工具帮助企业去实时监控公开网站上是否存在设定的关键字相关的，比如仓库名称、仓库描述、仓库文件名称等等。
• 根据代码托管网站的公开 API 来开发扫描工具。比如 GitHub 对公开仓库提供的 Search 接口。

• 通过爬虫拉取代码托管网站上合法公开的信息。由于一些现有工具存在限制或者不符合代码监控的需求，开发者也可考虑自行编写数据获取程序来进行监控，按照一定的搜索排序算法获取数据，每天定时识别可能涉及泄漏的关键记录后发送邮件告警。

03 及时申诉 提前了解主流代码托管平台对于侵权代码的处理策略可以让企业快速采取措施删除侵权仓库，把即将泛滥的 Fork 扼杀在摇篮里。

• GitHub 的 DMCA 策略

GitHub 有两种方式：版权所有者要求删除内容的删除通知程序；用户在内容被错误取下时重新启用内容的反通知程序。对于要求删除仓库的通知，GitHub 的处理流程：

1. 如果通知声明代码仓库中部分内容涉嫌侵权，GitHub 会联系创建存储库的用户，并给他们 24 小时来删除或修改通知中指定的内容。如果仓库拥有者由于节假日、垃圾邮箱的原因错过通知邮件，那么还有唯一一次额外的 24 小时来修改。
2. 如果 DMCA 通知声称存储库的全部内容都存在侵权。那么 GitHub 会迅速禁用整个存储库。就像 B 站这次的泄漏，就几乎没有整改时间窗直接被禁用。

• CODING 996 贴心守护

CODING 不提供公开代码的功能，旧版个人版中可以通过分享链接的方式邀请外部人员查看代码仓库，同时该外链不支持检索。点击阅读原文即可体验 CODING 代码安全保护。 若您在分享链接当中发现到侵权的内容时，可通过热线联系我们 24 小时的运营人员（support@coding.net），告知侵权情况，我们会通知仓库拥有者进行确认及整改。我们也建议个人开发者在分享代码仓库前要慎重，保管好分享外链。

• 在 Bitbucket 上报告版权违规行为

Atlassian 对云产品或网站（包括 Bitbucket）上进行侵犯版权的活动也提供了对应政策。如果用户通知网站上的数据或内容侵犯了自己的版权，按照政策当中要求的列表将侵权信息通知给 Atlassian 版权代理人，Atlassian 会按照 DMCA 从服务中删除涉及侵权的数据或内容。

04

严肃对待开源

1997 年的春天，包含 Eric Raymond，Tim O'Reilly 在内的自由软件社团第一次提出了“Open Source（开源软件）”这个术语。从那时起支持“开源软件”与支持“专有商用软件”已成为了软件行业的两大阵营。支持“开源软件”的阵营以一个科研的角度对待源代码，他们坚信为了促进计算机科学的进一步发展，源代码是必须被共享和发布的科学知识。另一方则站在工业界的角度，认为企业必须对商业秘密守口如瓶。无论开源运动最终走向何方，从目前来看就算使用开源软件也不意味着源代码就可以随意共享，开发者必须严格按照开源软件协议使用。

重视自己的代码版权，同时也尊重他人的代码版权。我们希望企业被“开源”的现象会越来越少，同时也希望意外的源码泄漏不会成为企业的致命一击。

注：

Eric Raymond，著名的程序员，开源软件运动的代表人物之一。主持开发了开源软件── Fetchmail。同时也是 NTERCAL 编程语言的主要创作者之一，曾经为 EMACS 编辑器作出贡献。

Tim O'Reilly ，O'Reilly Media 出版公司的创始人，也是非会议的鼻祖 Foo Camp 的发起人。他是自由软件和开源软件运动的强力支持者，“ web 2.0 ”一词为他所首创。

参考 https://help.github.com/en/articles/dmca-takedown-policy https://www.atlassian.com/legal/copyright-and-trademark-violations https://baijiahao.baidu.com/s?id=1610052563948067365&wfr=spider&for=pc http://cloud.idcquan.com/yzx/159047.shtml 《开源软件文集：开源革命之声》作者: Chris DiBona / Sam Ockman / Mark Stone