源碼安全：懸在大廠頭上的達摩克利斯之劍

本文首發於 CODING 官方微信公衆號——
《源碼安全：懸在大廠頭上的達摩克利斯之劍》

「 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 刪除通知數量

很多企業都有本身的代碼防泄漏機制，好比核心代碼權限控制、內外網隔離、保密協議等等措施，但代碼泄漏的現象依然在發生。並且影響嚴重的代碼泄漏事件很多都是由第三方發現的，等企業着手處理時已形成很多損失。接下來咱們要探討的就是如何把代碼泄漏的危害降到最低，咱們列出常見的實踐，以及在主流代碼託管平臺上發現侵權的倉庫後能夠怎麼作，以供讀者參考。

注重編程規範

對於企業來講，除了保障業務快速交付外，信息安全也是重中之重。特別是在信息及其敏感的行業，例如金融、公安、通信、軍工等。很多公司都有很是嚴格的編程規範，例如：

1. 不容許將敏感信息硬編碼在代碼中，敏感信息一般包括用戶帳戶、密碼、電話號碼、數據庫密碼、服務器遠程登陸密碼等等。若是確實須要在代碼裏的配置文件當中存儲敏感信息，建議也不要明文存儲。
2. 當代碼涉及到加解密算法時，密鑰不容許所有硬編碼在代碼中。同時加解密算法要選擇強度足夠的、業界承認的算法，密鑰也要支持按期更換。

相似上述的編碼規範可經過源碼安全掃描工具對版本進行增量掃描，避免人工檢視的低效率。有一些團隊不肯意花時間在這些並不直接或者並不當即產生價值的事務上，但咱們建議在安全和進度之間，研發團隊須要找到一個平衡。

創建監控機制

越早發現泄漏代碼，越容易控制源代碼傳播範圍。經過定時掃描代碼託管網站上的新增公開項目，查看是否存在可能涉及本公司項目源碼的倉庫。如何經過自動化掃描監控公開項目有以下幾種方式：

• 現有的關鍵字掃描開源工具，市面上提供了很多工具幫助企業去實時監控公開網站上是否存在設定的關鍵字相關的，好比倉庫名稱、倉庫描述、倉庫文件名稱等等。
• 根據代碼託管網站的公開 API 來開發掃描工具。好比 GitHub 對公開倉庫提供的 Search 接口。

• 經過爬蟲拉取代碼託管網站上合法公開的信息。因爲一些現有工具存在限制或者不符合代碼監控的需求，開發者也可考慮自行編寫數據獲取程序來進行監控，按照必定的搜索排序算法獲取數據，天天定時識別可能涉及泄漏的關鍵記錄後發送郵件告警。

及時申訴

提早了解主流代碼託管平臺對於侵權代碼的處理策略可讓企業快速採起措施刪除侵權倉庫，把即將氾濫的 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 從服務中刪除涉及侵權的數據或內容。

嚴肅對待開源

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/ar...
https://www.atlassian.com/leg...
https://baijiahao.baidu.com/s...
http://cloud.idcquan.com/yzx/...
《開源軟件文集：開源革命之聲》做者: Chris DiBona / Sam Ockman / Mark Stone 

更多內容，歡迎關注——